From kathleen.moriarty@emc.com Fri Feb 1 08:28:28 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026C421F8D00 for ; Fri, 1 Feb 2013 08:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thUhhpeufuMV for ; Fri, 1 Feb 2013 08:28:26 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D721F8E96 for ; Fri, 1 Feb 2013 08:28:24 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r11GSIFu025900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2013 11:28:22 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Fri, 1 Feb 2013 11:28:01 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r11GRx1b030495 for ; Fri, 1 Feb 2013 11:27:59 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 1 Feb 2013 11:27:59 -0500 From: "Moriarty, Kathleen" To: MILE IETF Date: Fri, 1 Feb 2013 11:27:57 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac392LfqtE12Sv21RDmeR7wzUTqasgCvxeJg Message-ID: References: <71238F9C-AD03-44B9-A065-541351FB4087@bcs.org> <1359433497.20429.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <1359433497.20429.YahooMailClassic@web121604.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE9E2823MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:28:28 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE9E2823MX15Acorpemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsIOKAkw0KDQpJ4oCZZCBsaWtlIHlvdXIgaW5wdXQgYW5kIHdpbGwgcmVmb2N1cyB0aGUgdGhy ZWFkIHRvIGdldCBvcGluaW9ucyBmcm9tIHRoZSBsaXN0IG9uIG9wdGlvbnMgdG8gaGVscCBzb2x2 ZSB0aGUgcHJvYmxlbXMgcmFpc2VkIGluIG15IG1lc3NhZ2UgYW5kIGFkZGl0aW9uYWxseSBpbiBQ YXVs4oCZcyBtZXNzYWdlLg0KDQpJbnRlcmVzdGluZyBwb2ludCwgQy4gSGVucnkuICBPdXIgb2Jq ZWN0aXZlIGhlcmUgaXMgdG8gaGF2ZSBtYWNoaW5lIGF1dG9tYXRlZCBleGNoYW5nZXMsIHNvIHdl IHJlbHkgb24gZW5jcnlwdGlvbiByYXRoZXIgdGhhbiBvYmZ1c2NhdGlvbiB0byBhY2hpZXZlIHRo ZSBuZWNlc3NhcnkgbGV2ZWwgb2YgY29uZmlkZW50aWFsaXR5Lg0KDQpQYXVsIG1lbnRpb25lZCB0 aGUgbmVlZCB0byBkaXN0aW5ndWlzaCBpbmRpY2F0b3JzIG9mIGNvbXByb21pc2UgZnJvbSBjb250 ZXh0IGluZm9ybWF0aW9uIHRoYXQgbWF5IGFsc28gaW5jbHVkZSBJUCBhZGRyZXNzIG9yIG90aGVy IGRhdGEgdGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzLiAgVGhlIHF1ZXN0aW9uIEkgcmFpc2VkIHdh cyBvbiBob3cgdG8gY29ubmVjdCBzZXRzIG9mIGluZGljYXRvcnMgaW4gdGhlIHNhbWUgSU9ERUYg ZG9jdW1lbnQsIGFzc3VtaW5nIHRoZSBhYmlsaXR5IHRvIGhhdmUgd2F0Y2hsaXN0cyB0aGF0IGNv dWxkIGhhdmUgc2V2ZXJhbCBzZXRzIG9mIGluZGljYXRvcnMgaW5jbHVkZWQsIGFzIHdlbGwgYXMg dG8gY29ubmVjdCBpbmRpY2F0b3JzIHRoYXQgbWF5IGJlIGluY2x1ZGVkIGluIGVtYmVkZGVkIHNj aGVtYXMuDQoNCklmIHdlIGFkZCBhbiBhdHRyaWJ1dGUgb24gYWxsIG9mIHRoZSByZWxldmFudCBp bmRpY2F0b3JzLCBsZXTigJlzIHNheSDigJhpbmRpY2F0b3ItdWlk4oCZIGhvdyBkbyB3ZSBtYXJr IHRoZSBpbmRpY2F0b3JzPyAgRG8gd2UgdXNlIHRoaXMgdG8gbWFyayB3aG8gc2VudCB0aGUgaW5k aWNhdG9yIGFzIHdlbGwgc28gdGhhdCB3ZSBjYW4gcHJldmVudCBmb3J3YXJkIHNoYXJpbmcgd2hl biBpdCBpcyBub3QgcGVybWl0dGVkIG9yIGhhbmRsZSB0aGF0IHNlcGFyYXRlbHk/DQoNClRoZW4g Zm9yIGluZGljYXRvcnMgbm90IGluY2x1ZGVkIGluIHRoZSBiYXNlIHNjaGVtYSB0aGF0IG1heSBu b3QgZml0IGludG8gYSBjYXRlZ29yeSBpbiB0aGUgU0NJIGRyYWZ0LCBkbyB3ZSBjcmVhdGUgYSBw bGFjZSBmb3IgdGhlc2Ugb2ZmIG9mIFNDSSBvciByaWdodCBvZmYgb2YgdGhlIElPREUgc2NoZW1h IGluIEV2ZW50RGF0YT8gKG1vcmUgZGV0YWlscyBvbiB0aGlzIGluIG15IGZpcnN0IG1lc3NhZ2Up Lg0KDQpDb21tZW50cyBhbmQgcXVlc3Rpb25zIGVuY291cmFnZWQgdG8gZmlndXJlIG91dCB0aGUg cmlnaHQgdGVjaG5pY2FsIHNvbHV0aW9uIHRvIGhhdmUgdGhpcyBtYWNoaW5lIGF1dG9tYXRhYmxl Lg0KDQpUaGFuayB5b3UsDQpLYXRobGVlbg0KDQpGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDLiBIZW5yeSBBZGFt cyAmIEJJRQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzIDExOjI1IFBNDQpUbzogTUlM RSBJRVRGDQpTdWJqZWN0OiBSZTogW21pbGVdIElPQ3MNCg0KVGVtcG9yYWwgRGVwZW5kZW5jeSBz b3VuZHMgaW50ZXJlc3RpbmcuICBJIHJlbWVtYmVyIHdoZW4gSSBmaXJzdCByYW4gYWNyb3NzIHRo aXMgcGFydGljdWxhciBjcmFmdCwgYW4gZXhwZXJpZW5jZWQgY29sbGVhZ3VlIGFza2VkIG1lIGEg cGVjdWxpYXIgcXVlc3Rpb24uICBIZSBzYWlkLCAiIEhvdyBkbyB5b3Ugc3RvcCBzb21lb25lIGZy b20gdHJhY2tpbmcgdGhlIElQIEFkZHJlc3MgdG8geW91ciBjb21wdXRlcj8iDQoNCkkgcmVwbGll ZCwgIkkgZG9uJ3Qga25vdywgaG93PyINCg0KVGhlbiBoZSBzYWlkLCAiQ3V0IHRoZSBkb2ctZ29u ZSB0aGluZyBvZmYgIGFuZCB0aGUgbW9kZW0gdGhhdCBpdCBpcyBjb25uZWN0ZWQtIHdoaWNoIGlz IGNvbnN0YW50bHkgb24hIiAgIExPTA0KDQpIZXJlJ3MgbXkgcG9pbnQgKEh5cG90aGV0aWNhbCBT aXR1YXRpb24pIDogIFRoZXJlIGlzIGEgMXN0IFJlc3BvbmRlciBzZWFyY2hpbmcgYSBOZWlnaGJv cmhvb2QgZm9yIFN1cnZpdm9ycyB3aGljaCB3ZXJlIGhpdCBieSBhIERpc2FzdGVyIG9yIGxldCdz IGp1c3Qgc2F5ICJMaXZlIiBUZXJyb3Jpc3QgU2l0dWF0aW9uLiAgSGUgL29yIFNoZSBuZWVkcyB0 byBjb21tdW5pY2F0aW9uIGJhY2sgdG8gb3RoZXIgT2ZmaWNpYWxzIHRoYXQgaGUgL29yIHNvbWVo b3cgaXMgaW4gRGFuZ2VyLiAgVGhlIGRldmljZSB1c2VkIHRvIGNvbW11bmljYXRlIGhhcyBiZWVu IGNhcHR1cmVkIGJ5IHRoZSBncmVhdCBtaW5kcyBvZiB0aGUgZW5lbXkuICBJdCdzIG9ubHkgYSBt YXR0ZXIgb2YgdGltZSBiZWZvcmUgdGhleSB1dGlsaXplIHJldmVyc2UgZW5naW5lZXJpbmcgdG8g ZmlndXJlIG91dCBob3cgaXQgZnVuY3Rpb25zLiAgSG93ZXZlciwgdGhlaXIgcHJpZGUgY29tZXMg YmVmb3JlIGEgZmFsbCB3aGVuIHNlZWtpbmcgdGhlIGxvY2F0aW9uIG9mIG90aGVyIHNpbWlsYXIg ZGV2aWNlcyB0byBhdHRhY2suICBXaHk/IFBlcmhhcHMgdGhlIGxlc3MgdGhvdWdodCBvZiBjb25j ZXB0cyB0aGF0IG1ha2VzIHRoZSBkZXZpY2UgZnVuY3Rpb24gcHJvcGVybHksIHNhdmVzIHRoZSBk YXkgYnkgZGlzZ3Vpc2Ugb3IgY3V0dGluZyBpdCBvZmYgKGZpZ3VyYXRpdmVseSBzcGVha2luZyku DQoNCkp1c3QgYSB2aXNpb25hcnkgdGhvdWdodC4NCg0KQy4gSGVucnkgQWRhbXMNCmNoZW5yeWFk YW1zQGJpZW1lZGlhZ3JvdXAuY29tPG1haWx0bzpjaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNv bT4NCmh0dHA6Ly9iaWVtZWRpYWdyb3VwLmNvbQ0KDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgb3JpZ2luYWwgcmVjaXBp ZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgZGlzdHJpYnV0aW9u IHdpdGhpbiB0aGUgcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1 cnBvc2VzIG9ubHkuIEZ1cnRoZXIgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBwcml2YXRlIG9yIHB1 YmxpYyBpcyBwcm9oaWJpdGVkLg0KDQotLS0gT24gTW9uLCAxLzI4LzEzLCBEYXZlIE1pc2VsbCA8 ZGF2aWQubWlzZWxsQGJjcy5vcmc8bWFpbHRvOmRhdmlkLm1pc2VsbEBiY3Mub3JnPj4gd3JvdGU6 DQoNCkZyb206IERhdmUgTWlzZWxsIDxkYXZpZC5taXNlbGxAYmNzLm9yZzxtYWlsdG86ZGF2aWQu bWlzZWxsQGJjcy5vcmc+Pg0KU3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQpUbzogIkMuIEhlbnJ5 IEFkYW1zICYgQklFIiA8Y2hhdGxnYTIwMDBAeWFob28uY29tPG1haWx0bzpjaGF0bGdhMjAwMEB5 YWhvby5jb20+Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzLCA5OjI1IFBNDQpVSUQg Y291bGQgYmUgbWlycm9yZWQgd2l0aCBETlMgU0VDIGEgcGVtYW5lbnQgYW5kIHRlbXBvcmFsIGtl eSwgd2l0aCBhIHRlbXBvcmFsIElkPw0KDQpZb3VycyBGYWl0aGZ1bGx5LA0KDQpEYXZlIE1pc2Vs bCBNU2MgQ0lTU1ANClNpbGVudENpcmNsZSAgZHNtDQowNzcxMCAzODAwNDQNCmRhdmlkLm1pc2Vs bEBiY3Mub3JnPC9tYy9jb21wb3NlP3RvPWRhdmlkLm1pc2VsbEBiY3Mub3JnPg0KDQoNCk9uIDI5 IEphbiAyMDEzLCBhdCAwMDozOSwgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlh aG9vLmNvbTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+PiB3cm90ZToNCg0K PiBTZXJpYWxpemF0aW9uIG9mIGEgcGFydGljdWxhciBMaXN0cyBvZiBYTUwgQ2xhc3NlcyBpbiBh IHVuaXF1ZSB3YXkgd2FzIGNsb3NlbHkgcmVsYXRlZCB0byB3aGF0IEkgYXR0ZW1wdGVkIHRvIGV4 cHJlc3Mgd2hlbiBJIHN0YXRlZCwgImNvbnNpZGVyIHRvIGEgZGVncmVlIHdoYXQgYXBwZWFycyB0 byBiZSBpbGxvZ2ljYWwgaW4gYnJpbGxpYW50IG1pbmRzIGluIHNvbWUgaW5zdGFuY2VzLiINCj4N Cj4gSG93ZXZlciwgSSBzZWUgRHIuIFN0b2Vja2VyJ3MgcG9pbnQgYSBsaXR0bGUgY2xlYXJlci4g IEhvd2V2ZXIsIGl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIFVJRCB3YXMgaW4gc29tZSB3YXkgZGlz Z3Vpc2VkIGZyb20gdGhvc2Ugd2hvIHN0dWR5IHRoaXMgU2VjdXJpdHkgQXJ0IEZvcm0gaW4gYSBu ZWdhdGl2ZSB3YXkuDQo+DQo+IEMuIEhlbnJ5IEFkYW1zDQo+IGNoYXRsZ2EyMDAwQHlhaG9vLmNv bTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+IChEaXJlY3QgRW1haWwpDQo+ IGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPC9tYy9jb21wb3NlP3RvPWNoZW5yeWFkYW1z QGJpZW1lZGlhZ3JvdXAuY29tPg0KPg0KPg0KPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIG9yaWdpbmFsIHJlY2lwaWVudC4g VGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRo aW4gdGhlIHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZyBwdXJwb3Nl cyBvbmx5LiBGdXJ0aGVyIGRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMg aXMgcHJvaGliaXRlZC4NCj4NCj4gUmU6IFttaWxlXSBJT0NzDQo+DQo+IFN1bmRheSwgSmFudWFy eSAyNywgMjAxMyA4OjUyIFBNDQo+IEZyb206DQo+ICJTdG9lY2tlciwgUGF1bCIgPFBhdWwuU3Rv ZWNrZXJAcnNhLmNvbTwvbWMvY29tcG9zZT90bz1QYXVsLlN0b2Vja2VyQHJzYS5jb20+Pg0KPiBU bzoNCj4gIm1pbGVAaWV0Zi5vcmc8L21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4iIDxtaWxl QGlldGYub3JnPC9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+Pg0KPiBJIHdvdWxkIGxpa2Ug dG8gbG9vayBhdCB0aGlzIGZyb20gYSBzbGlnaHRseSBkaWZmZXJlbnQgcGVyc3BlY3RpdmXFoGxl dCdzDQo+IHNheSBJIGdldCBhbiBYTUwgZG9jdW1lbnQgdGhhdCB0ZWxscyBtZSBhYm91dCBhbiBp bmNpZGVudC4gIFRoaXMgZG9jdW1lbnQNCj4gaGFzIHNvdXJjZSBJUCBhbmQgZGVzdGluYXRpb24g SVAgdGhhdCBpcyBiZWluZyBzaGFyZWQuICBIb3dldmVyLCB3aGF0IEkNCj4gZG9uJ3Qga25vdyBp cyB3aGljaCBJUCBhZGRyZXNzIGlzIG15IGluZGljYXRvciBhbmQgd2hpY2ggaXMganVzdCBhDQo+ IGNvbnRleHR1YWwgcGllY2Ugb2YgaW5mb3JtYXRpb24uICBUaGlzIG1lYW5zIHRoYXQgbXkgZGV0 ZWN0aW9uIHByb2R1Y3QNCj4gaXNuJ3QgZ29pbmcgdG8ga25vdyB3aGljaCBvbmUgdG8gdXNlIGVp dGhlciwgYmVjYXVzZSB0aGVyZSBpcyBub3RoaW5nIHRvDQo+IHRlbGwgbWUgd2hpY2ggSVAgaXMg dGhlIG9uZSwgZXZlbiBpZiB0aGUgcm9sZXMgYXJlIHNldCBpdCBzdGlsbCBtaWdodCBub3QNCj4g YmUgZW5vdWdoIHRvIHRlbGwgbXkgc3lzdGVtIHdoaWNoIG9uZSBJIHNob3VsZCB1c2UgYXMgdGhl IGluZGljYXRvci4NCj4NCj4gSWYgd2UgaGFkIHNvbWV0aGluZyBsaWtlIGluZGljYXRvcl9pZCBh cyBhbiBhdHRyaWJ1dGUsIGl0IHdvdWxkIGFsbG93IHVzDQo+IHRvIGVhc2lseSBpZGVudGlmeSBp bmRpY2F0b3JzIGZyb20gY29udGV4dHVhbCBkYXRhLiAgSSBkbyBhZG1pdCB0byBiZWluZw0KPiBi aWFzZWQgYXMgSSBoYXZlIHNwZW50IG11Y2ggb2YgbXkgY2FyZWVyIHdvcmtpbmcgb24gdGhlIG1v bml0b3JpbmcgYW5kDQo+IGRldGVjdGlvbiBzaWRlIG9mIHRoZXNlIHRoaW5ncywgc28gSSBhbSBq dXN0IHRoaW5raW5nIG9mIHdheXMgdG8gbWFrZSBpdA0KPiB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGlu ZGljYXRvcnMgYXJlIGluIHRoZSBYTUwgZG9jdW1lbnQgYW5kIHRoZSBvdGhlciBkYXRhDQo+IHRo YXQgbWF5IGJlIGltcG9ydGFudCBhcyBJIGludmVzdGlnYXRlIGFjdGl2aXR5IHRoYXQgSSBoYXZl IGRldGVjdGVkIG9mZg0KPiBvZiB0aG9zZSBpbmRpY2F0b3JzLg0KPg0KPg0KPiBJIGRpZCBzdWdn ZXN0IHRoZSBkZXRlY3Rpb24gY2xhc3MsIGJ1dCBJIHRoaW5rIHdlIG1heSBnZXQgbW9yZSBmbGV4 aWJpbGl0eQ0KPiB3aXRoIHRoZSBpbmRpY2F0b3JfdWlkLiAgT25lIHRoaW5nIHRoYXQgSSBoYXZl bid0IGNvbnNpZGVyZWQgaXMgdGhlIFVJRA0KPiBwb3J0aW9uIG9mIHRoaXPFoGhvdyBkbyB3ZSB1 c2UgdGhhdCBVSUQ/ICBIb3cgaXMgdGhlIFVJRCBjcmVhdGVkPyAgQXJlDQo+IHRoZXJlIHN0YW5k YXJkcyBmb3IgVUlEcz8NCj4NCj4gUmVnYXJkcywNCj4NCj4gUGF1bA0KPg0KPg0KPg0KPiBQYXVs IFcuIFN0b2Vja2VyLCBQaC5ELg0KPiBTTUMgTGVhZCBDb250ZW50IEFyY2hpdGVjdA0KPiBSU0Es IFRoZSBTZWN1cml0eSBEaXZpc2lvbiBvZiBFTUMNCj4gY2VsbDogMzAyLjM3OS4zMzc1IHwgZTog cGF1bC5zdG9lY2tlckByc2EuY29tPC9tYy9jb21wb3NlP3RvPXBhdWwuc3RvZWNrZXJAcnNhLmNv bT4NCj4NCj4gLS0tIE9uIFNhdCwgMS8yNi8xMywgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRs Z2EyMDAwQHlhaG9vLmNvbTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+PiB3 cm90ZToNCj4NCj4gRnJvbTogQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlhaG9v LmNvbTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+Pg0KPiBTdWJqZWN0OiBS RTogW21pbGVdIElPQ3MNCj4gVG86ICJLYXRobGVlbk1vcmlhcnR5IiA8a2F0aGxlZW4ubW9yaWFy dHlAZW1jLmNvbTwvbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPj4NCj4g Q2M6IG1pbGVAaWV0Zi5vcmc8L21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4NCj4gRGF0ZTog U2F0dXJkYXksIEphbnVhcnkgMjYsIDIwMTMsIDY6MTcgUE0NCj4NCj4gR3JlZXRpbmdzIEthdGhs ZWVuLA0KPg0KPiBZb3VyIGxvZ2ljIHN0aW11bGF0ZXMgbXkgdmlzaW9uYXJ5IGJyYWluIGJlY2F1 c2UgSSdtIGFtYXplZCBhdCB0aGUgbWFueSBhdmVudWVzIHlvdSByZXZpZXcgd2l0aCB0aGlzIGFw cHJvYWNoIGF0IG9uY2UuICBIb3dldmVyLCAgY291bGQgeW91IHNoYXJlIGEgZmV3IGFkdmFudGFn ZXMgYW5kIGRpc2FkdmFudGFnZXMgdG8gdGhlIGxhdHRlcj8NCj4NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIndl IGNvdWxkIGNvbnRpbnVlIHRvIGdyb3VwIGl0ZW1zIGluIGxvZ2ljYWwgcGxhY2VzIGFzIGlzIGRv bmUgbm93IGluIElPREVGIGFuZCB0aGVuIGhhdmUgdGhlIGV4dGVuc2lvbiBwb2ludCBmb3IgY29t YmluZWQgaW5kaWNhdG9ycyB2aWEgU0NJLiINCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBZb3UgcG9pbnRl ZCBvdXQgd2hhdCB5b3UgY29uc2lkZXIgdG8gYmUgbG9naWNhbCBwbGFjZXMsIGJ1dCBpZiBJIHdh bnRlZCB0byBwcm90ZWN0IGluZm9ybWF0aW9uIGZyb20gcGFydGllcyBjYXBhYmxlIG9mIGFzY2Vy dGFpbmluZyBpdCBmcm9tIHlvdXIgbG9naWNhbCBwbGFjZXMsIHBlcmhhcHMgd2Ugc2hvdWxkIGFs c28gY29uc2lkZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBlYXJzIHRvIGJlIGlsbG9naWNhbCBpbiBi cmlsbGlhbnQgbWluZHMgaW4gc29tZSBpbnN0YW5jZXMuDQo+DQo+DQo+DQo+IEMuIEhlbnJ5IEFk YW1zDQo+IGNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5 YWhvby5jb20+IChEaXJlY3QgRW1haWwpDQo+IGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29t PC9tYy9jb21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPg0KPg0KPiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIG9yaWdpbmFsIHJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBs aW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW4gdGhlIHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2lu ZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyIGRpc3NlbWluYXRpb24sIHdo ZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC4NCj4NCj4gLS0tIE9uIFNhdCwg MS8yNi8xMywgTW9yaWFydHksIEthdGhsZWVuIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9t Yy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+PiB3cm90ZToNCj4NCj4gRnJv bTogTW9yaWFydHksIEthdGhsZWVuIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9tYy9jb21w b3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+Pg0KPiBTdWJqZWN0OiBSRTogW21pbGVd IElPQ3MNCj4gVG86ICJDLiBIZW5yeSBBZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAwQHlhaG9vLmNv bTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+PiwgIm1pbGVAaWV0Zi5vcmc8 L21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4iIDxtaWxlQGlldGYub3JnPC9tYy9jb21wb3Nl P3RvPW1pbGVAaWV0Zi5vcmc+Pg0KPiBEYXRlOiBTYXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMywg MTA6MTMgQU0NCj4NCj4gSGVsbG8gQy4gSGVucnkgJiBvdGhlcnMsDQo+DQo+IFRoYW5rcyBmb3Ig dGFraW5nIGEgbG9vayBhdCB0aGlzLiAgV2UgaGF2ZSBhIGZldyBjb25zaWRlcmF0aW9ucyBpbiB0 aGlzIGVtYWlsIHRocmVhZCBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aG91Z2h0cyBvbiAoYW5kIHRo ZXJlIG1heSBiZSBtb3JlIG9uY2UgUkZDNTA3MC1iaXMgaXMgYWN0aXZlbHkgZWRpdGVkKS4NCj4N Cj4gVGhlIEFkZGl0aW9uYWxEYXRhIGNsYXNzIGFuZCB0aGUgUmVjb3JkSXRlbSBjbGFzcyBib3Ro IGFsbG93IGZvciBub24tWE1MIGV4dGVuc2lvbnMuICBXaGVyZSB5b3UgcGxhY2UgdGhlIGV4dGVu c2lvbnMgc2hvdWxkIGJlIHNwZWNpZmljIHRvIHRoZSBsb2dpY2FsIGdyb3VwaW5nIG9mIHRoZSBw YXJlbnQgZWxlbWVudHMgc28geW91IGNhbiB1bmRlcnN0YW5kIG1vcmUgYWJvdXQgdGhlIGluY2x1 ZGVkIGRhdGEgaW4gbW9zdCBjYXNlcy4NCj4NCj4gVGhlIEltcGFjdCBjbGFzcyBjYW4gYmUgdXNl ZCB0byBwcm92aWRlIGNvbnRleHQgaW5mb3JtYXRpb24gb24gdGhlIGluY2x1ZGVkIGRhdGEgb2Yg dGhlIHJlcG9ydCBhbmQgYWxzbyBjYW4gaW5jbHVkZSBhIGNvbmZpZGVuY2UgcmF0aW5nIG9uIHRo ZSByZXBvcnQgYXMgYSB3aG9sZS4gIEV4dGVuc2lvbnMgcmVsYXRlZCB0byBpbXBhY3Qgd291bGQg YmUgb25lIGxldmVsIGhpZ2hlciAoYXQgdGhlIG1vbWVudCkgaW4gdGhlIEFzc2Vzc21lbnQgY2xh c3MgdXNpbmcgdGhlIEFkZGl0aW9uYWxEYXRhIGV4dGVuc2lvbiBwb2ludC4NCj4NCj4gVGFrZSBh c2tlZCBhYm91dCBpbmNsdWRpbmcgdnVsbmVyYWJpbGl0eSBpbmZvcm1hdGlvbiwgSSB3b3VsZCB0 aGluayB0aGF0IHdvdWxkIGZpdCB1bmRlciB0aGUgVnVsbmVyYWJpbGl0eSBleHRlbnNpb24gcG9p bnQgb2YgdGhlIFNDSSBkcmFmdCBpbiB0aGUgTWV0aG9kIGNsYXNzLiAgSGUgZGlkIGFzayBhYm91 dCBub24tWE1MLiAgUmVjb3JkSXRlbSBvciBBZGRpdGlvbmFsRGF0YSBkbyBhbGxvdyBmb3Igbm9u LVhNTCBleHRlbnNpb24gcG9pbnRzLCB3ZSBjb3VsZCBlaXRoZXIgaGF2ZSB0aGUgU0NJIGRyYWZ0 IGhhbmRsZSB0aGVzZSBhcyB3ZWxsIG9yIGhhdmUgdGhlIGV4dGVuc2lvbnMgdGhhdCBhcmUgbm9u LVhNTCBjb21lIGRpcmVjdGx5IG9mZiB0aGUgQWRkaXRpb25hbERhdGEgb3IgUmVjb3JkSXRlbSBj bGFzc2VzIGFjY29yZGluZyB0byB3aGF0IG1ha2VzIHNlbnNlIGZyb20gYSBsb2dpY2FsIHN0YW5k cG9pbnQuDQo+DQo+IEFzIGZvciBteSBxdWVzdGlvbiwgaXQgd2FzIHR3by1mb2xkLg0KPg0KPiBJ bmRpY2F0b3IgYmFzZWQgc2NoZW1hcyBoYXZlIGEgcmVmZXJlbmNlIG51bWJlciBvciBhIEdVSUQg Zm9yIHRoZSB2YXJpb3VzIGluZGljYXRvcnMgdGhleSBzaGFyZS4gIElmIHdlIGFyZSBleHRlbmRp bmcgdG8gZW1iZWQgb3RoZXIgc2NoZW1hcyB0aGF0IGluY2x1ZGUgc3VjaCByZWZlcmVuY2Ugb3Ig R1VJRCBpZGVudGlmaWVycywgZG8gd2Ugd2FudCB0byBhZGQgYW4gYXR0cmlidXRlIHRvIHRoZSB2 YXJpb3VzIGVsZW1lbnRzIGluIElPREVGIHRoYXQgY291bGQgYmUgaW5kaWNhdG9ycz8gIElzIHRo aXMgZW5vdWdoIHRvIG1ha2UgdGhlIGNvbm5lY3Rpb25zIG9yIGlzIHNvbWV0aGluZyBlbHNlIGVs c2UgbmVlZGVkPyAgV2UgY291bGQgYWRkIHNvbWV0aGluZyBsaWtlIGFuIEluZGljYXRvcl9JRCBp biBSRkM1MDcwLWJpcyB3aGljaCB3b3VsZCB0aGVuIGNvcnJlbGF0ZSB0byB0aGUgcmVmZXJlbmNl IG9yIEdVSUQgaWRlbnRpZmllcnMuDQo+DQo+IFRoZW4gdGhlIG90aGVyIHF1ZXN0aW9uIHdhcyBv biBob3cgdG8gaW5jbHVkZSBpbmRpY2F0b3JzIHRoYXQgYXJlIG5vdCBpbiB0aGUgYmFzZSBzY2hl bWEgdGhhdCBtYXkgYmUgcmVsYXRlZCBvciBoYXZlIGxhbmd1YWdlIHdpdGggImFuZCIgIm9yIiB0 byBzcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXBzLiAgSW4gc29tZSBjYXNlcywgeW91IHdpbGwgd2Fu dCB0byBncm91cCB0aGVzZSBpbmRpY3RvcnMgaW4gb25lIGV4dGVuc2lvbiBwb2ludCwgd2hlcmUg dGhleSBtYXkgZml0IGxvZ2ljYWxseSBpbiBtdWx0aXBsZSBwbGFjZXMgaWYgdGhlIHJlbGF0aW9u c2hpcHMgZGlkIG5vdCBuZWVkIHRvIGJlIHNob3duIGluIHRoZSBkYXRhIGZvcm1hdC4gIElmIHdl IGhhdmUgY2FzZXMgbGlrZSB0aGlzIHdoZXJlIHlvdSBuZWVkIG1vcmUgY29tcGxleCByZXByZXNl bnRhdGlvbnMsIHNob3VsZCB3ZSB1c2Ugb25lIGV4dGVuc2lvbiBwb2ludCB2aWEgdGhlIFNDSSBk cmFmdCBvZmYgb2YgdGhlIEV2ZW50RGF0YSBjbGFzcyBBZGRpdGlvbmFsRGF0YSBleHRlbnNpb24g cG9pbnQ/ICBPcGluaW9ucyBhcmUgbmVlZGVkIGhlcmUuLi4uDQo+DQo+IEEgZmV3IHBlb3BsZSBo YXZlIG1lbnRpb25lZCB3YW50aW5nIHRvIGluY2x1ZGUgc29tZSBjb21tb25seSBzaGFyZWQgaW5k aWN0b3JzIGludG8gdGhlIGJhc2UgSU9ERUYgZG9jdW1lbnQuICBXZSBjb3VsZCBoYXZlIGEgY2F0 Y2gtYWxsIGNsYXNzIHRoYXQgZG9lcyB0aGlzIGFuZCBoYXMgYW4gZXh0ZW5zaW9uIHBvaW50IG9m ZiBvZiBpdCBpbiBFdmVudERhdGEgb3Igd2UgY291bGQgY29udGludWUgdG8gZ3JvdXAgaXRlbXMg aW4gbG9naWNhbCBwbGFjZXMgYXMgaXMgZG9uZSBub3cgaW4gSU9ERUYgYW5kIHRoZW4gaGF2ZSB0 aGUgZXh0ZW5zaW9uIHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZpYSBTQ0kuICBJIHRo aW5rIEkgbGlrZSB0aGUgbGF0dGVyIGFwcHJvYWNoLg0KPg0KPiBUaGFuayB5b3UsDQo+IEthdGhs ZWVuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTog bWlsZS1ib3VuY2VzQGlldGYub3JnPC9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9y Zz4gW21pbGUtYm91bmNlc0BpZXRmLm9yZzwvbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQy4gSGVucnkgQWRhbXMgJiBCSUUgW2NoYXRsZ2EyMDAwQHlh aG9vLmNvbTwvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+XQ0KPiBTZW50OiBT YXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMyAzOjA1IEFNDQo+IFRvOiBtaWxlQGlldGYub3JnPC9t Yy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+DQo+IENjOiBDLiBIZW5yeSBBZGFtcw0KPiBTdWJq ZWN0OiBSZTogW21pbGVdIElPQ3MNCj4NCj4gR3JlZXRpbmdzIEV2ZXJ5b25lLA0KPg0KPiBUYWtl IG1lbnRpb25lZCB0d28gdHlwZXMgb2YgaW5kaWNhdG9ycyBiYXNlZCBvbiB0aGUgOg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gMSkgSWYgdGhlIGlu ZGljYXRvcnMgYXJlIHNvbWV0aGluZyBsaWtlIGFuIFhNTC1iYXNlZCBhbGVydC93YXJuaW5nIG9m DQo+IGluZm9ybWF0aW9uIGxlYWthZ2UsIGl0IGNvdWxkIGJlIGFuIGV2ZW50IHRoYXQgYXJlIGNv bnZleWVkIGluIHRoZSBTQ0kncw0KPiBFdmVudFJlcG9ydCBjbGFzcywgSU1ITy4NCj4NCj4gMikg SWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGluZyBsaWtlIGFuIG5vbi1YTUwgb25lcywgSSBn dWVzcyBpdCBjb3VsZCBiZQ0KPiBjb252ZXllZCB3aXRob3V0IHVzaW5nIFNDSSBkcmFmdC4NCj4g Rm9yIGluc3RhbmNlLCB3ZSBjb3VsZCB1c2UgSW1wYWN0IGNsYXNzIG9mIHRoZSBiYXNlIElPREVG IHRvIGNvbnZleSB0aGUNCj4gaW5kaWNhdG9ycy4NCj4gV2UgY291bGQgZm9yIGluc3RhbmNlIGV4 dGVuZCB0aGUgbGlzdCBvZiBpbmRpY2F0b3JzIG9mIHRoZSBJbXBhY3QgY2xhc3MsIGlmDQo+IG5l ZWRlZC4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+IEluIGRvaW5nIHNvIGhlIHBvaW50ZWQgb3V0IHRoZSAiSW1wYWN0IENsYXNzIg0KPg0KPiBX aGVyZWFzLCBLYXRobGVlbiBzdGF0ZWQsDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IEZvciB0aGUgZGlzY3Vzc2lvbiBiZWxvdywgSSB3YXMgdGhp bmtpbmcgbW9yZSBvZiBjb21iaW5lZCBzZXQgd2l0aCByZWxhdGlvbnNoaXBzIHRoYXQgbWF5IGJl IGluY2x1ZGVkIGluIGEgc2luZ2xlIGV4dGVuc2lvbiBwb2ludCwgc28gdGhhdCdzIHdoeSBJIHdh cyB0aGlua2luZyBhYm91dCB0aGUgRXZlbnREYXRhIGNsYXNzLCBidXQgdGhlcmUgbWF5IGJlIGJl dHRlciBsb2NhdGlvbnMgb3IgYSBzcGVjaWZpYyBhcmVhIHdpdGhpbiB0aGUgRXZlbnREYXRhLg0K Pg0KPiBQYXVsIFN0b2Vja2VyIGhhZCBzdWdnZXN0ZWQgYSAiRGV0ZWN0aW9uIiBjbGFzcyBhcyBh IGNvbnNpZGVyYXRpb24uDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4NCj4gS2F0aGxlZW4gdGhvdWdodHMgcmVsYXRlZCB5ZXQgc3RpbGwgd2l0aCBvdGhl ciBpbmRpY2F0b3JzIGFuZCB0aGUgRXZlbnREYXRhIENsYXNzLg0KPg0KPiBJcyB0aGVyZSBhIHBv c3NpYmxlIHdheSB0byBjcmVhdGUgYSBuZXcgWE1MIGNsYXNzIHdoaWNoIGVuY29tcGFzcyBjb21i aW5pbmcgdGhlIEV2ZW50RGF0YSwgRGV0ZWN0aW9uIGFuZCBiYXNlIElPREVGIGNsYXNzZXMgdG8g c2ltcGxpZnkgdGhpcyBpc3N1ZT8NCj4NCj4NCj4gQy4gSGVucnkgQWRhbXMNCj4gY2hhdGxnYTIw MDBAeWFob28uY29tPC9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbT4gKERpcmVj dCBFbWFpbCkNCj4gY2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb208L21jL2NvbXBvc2U/dG89 Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20+DQo+DQo+DQo+IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgb3JpZ2luYWwg cmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgZGlzdHJp YnV0aW9uIHdpdGhpbiB0aGUgcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5u aW5nIHB1cnBvc2VzIG9ubHkuIEZ1cnRoZXIgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBwcml2YXRl IG9yIHB1YmxpYyBpcyBwcm9oaWJpdGVkLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBtaWxlIG1haWxpbmcgbGlzdA0KPiBtaWxlQGlldGYub3Jn PC9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlsZQ0KDQoNCg== --_000_F5063677821E3B4F81ACFB7905573F24CE9E2823MX15Acorpemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5BbGwg4oCTIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SeKAmWQgbGlrZSB5b3VyIGlu cHV0IGFuZCB3aWxsIHJlZm9jdXMgdGhlIHRocmVhZCB0byBnZXQgb3BpbmlvbnMgZnJvbSB0aGUg bGlzdCBvbiBvcHRpb25zIHRvIGhlbHAgc29sdmUgdGhlIHByb2JsZW1zIHJhaXNlZCBpbiBteSBt ZXNzYWdlIGFuZCBhZGRpdGlvbmFsbHkgaW4gUGF1bOKAmXMgbWVzc2FnZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkludGVyZXN0aW5nIHBvaW50LCBDLiBIZW5yeS7CoCBPdXIgb2JqZWN0aXZlIGhlcmUg aXMgdG8gaGF2ZSBtYWNoaW5lIGF1dG9tYXRlZCBleGNoYW5nZXMsIHNvIHdlIHJlbHkgb24gZW5j cnlwdGlvbiByYXRoZXIgdGhhbiBvYmZ1c2NhdGlvbiB0byBhY2hpZXZlIHRoZSBuZWNlc3Nhcnkg bGV2ZWwgb2YgY29uZmlkZW50aWFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGF1bCBtZW50aW9u ZWQgdGhlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggaW5kaWNhdG9ycyBvZiBjb21wcm9taXNlIGZyb20g Y29udGV4dCBpbmZvcm1hdGlvbiB0aGF0IG1heSBhbHNvIGluY2x1ZGUgSVAgYWRkcmVzcyBvciBv dGhlciBkYXRhIHRoYXQgY291bGQgYmUgaW5kaWNhdG9ycy7CoCBUaGUgcXVlc3Rpb24gSSByYWlz ZWQgd2FzIG9uIGhvdyB0byBjb25uZWN0IHNldHMgb2YgaW5kaWNhdG9ycyBpbiB0aGUgc2FtZSBJ T0RFRiBkb2N1bWVudCwgYXNzdW1pbmcgdGhlIGFiaWxpdHkgdG8gaGF2ZSB3YXRjaGxpc3RzIHRo YXQgY291bGQgaGF2ZSBzZXZlcmFsIHNldHMgb2YgaW5kaWNhdG9ycyBpbmNsdWRlZCwgYXMgd2Vs bCBhcyB0byBjb25uZWN0IGluZGljYXRvcnMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4gZW1iZWRk ZWQgc2NoZW1hcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIHdlIGFkZCBhbiBhdHRyaWJ1dGUgb24g YWxsIG9mIHRoZSByZWxldmFudCBpbmRpY2F0b3JzLCBsZXTigJlzIHNheSDigJhpbmRpY2F0b3It dWlk4oCZIGhvdyBkbyB3ZSBtYXJrIHRoZSBpbmRpY2F0b3JzP8KgIERvIHdlIHVzZSB0aGlzIHRv IG1hcmsgd2hvIHNlbnQgdGhlIGluZGljYXRvciBhcyB3ZWxsIHNvIHRoYXQgd2UgY2FuIHByZXZl bnQgZm9yd2FyZCBzaGFyaW5nIHdoZW4gaXQgaXMgbm90IHBlcm1pdHRlZCBvciBoYW5kbGUgdGhh dCBzZXBhcmF0ZWx5P8KgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlbiBmb3IgaW5kaWNhdG9ycyBu b3QgaW5jbHVkZWQgaW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IG5vdCBmaXQgaW50byBhIGNh dGVnb3J5IGluIHRoZSBTQ0kgZHJhZnQsIGRvIHdlIGNyZWF0ZSBhIHBsYWNlIGZvciB0aGVzZSBv ZmYgb2YgU0NJIG9yIHJpZ2h0IG9mZiBvZiB0aGUgSU9ERSBzY2hlbWEgaW4gRXZlbnREYXRhPyAo bW9yZSBkZXRhaWxzIG9uIHRoaXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5Db21tZW50cyBhbmQgcXVlc3Rpb25zIGVuY291cmFnZWQgdG8gZmlndXJlIG91dCB0aGUg cmlnaHQgdGVjaG5pY2FsIHNvbHV0aW9uIHRvIGhhdmUgdGhpcyBtYWNoaW5lIGF1dG9tYXRhYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5LYXRobGVlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBtaWxlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP ZiA8L2I+Qy4gSGVucnkgQWRhbXMgJmFtcDsgQklFPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEph bnVhcnkgMjgsIDIwMTMgMTE6MjUgUE08YnI+PGI+VG86PC9iPiBNSUxFIElFVEY8YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbbWlsZV0gSU9DczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1h bFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MD48dHI+PHRkIHZhbGln bj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ VGVtcG9yYWwgRGVwZW5kZW5jeSBzb3VuZHMgaW50ZXJlc3RpbmcuJm5ic3A7IEkgcmVtZW1iZXIg d2hlbiBJIGZpcnN0IHJhbiBhY3Jvc3MgdGhpcyBwYXJ0aWN1bGFyIGNyYWZ0LCBhbiBleHBlcmll bmNlZCBjb2xsZWFndWUgYXNrZWQgbWUgYSBwZWN1bGlhciBxdWVzdGlvbi4mbmJzcDsgSGUgc2Fp ZCwgJnF1b3Q7IEhvdyBkbyB5b3Ugc3RvcCBzb21lb25lIGZyb20gdHJhY2tpbmcgdGhlIElQIEFk ZHJlc3MgdG8geW91ciBjb21wdXRlcj8mcXVvdDsmbmJzcDsgPGJyPjxicj5JIHJlcGxpZWQsICZx dW90O0kgZG9uJ3Qga25vdywgaG93PyZxdW90OyA8YnI+PGJyPlRoZW4gaGUgc2FpZCwgJnF1b3Q7 Q3V0IHRoZSBkb2ctZ29uZSB0aGluZyBvZmYmbmJzcDsgYW5kIHRoZSBtb2RlbSB0aGF0IGl0IGlz IGNvbm5lY3RlZC0gd2hpY2ggaXMgY29uc3RhbnRseSBvbiEmcXVvdDsmbmJzcDsmbmJzcDsgTE9M PGJyPjxicj5IZXJlJ3MgbXkgcG9pbnQgKEh5cG90aGV0aWNhbCBTaXR1YXRpb24pIDombmJzcDsg VGhlcmUgaXMgYSAxc3QgUmVzcG9uZGVyIHNlYXJjaGluZyBhIE5laWdoYm9yaG9vZCBmb3IgU3Vy dml2b3JzIHdoaWNoIHdlcmUgaGl0IGJ5IGEgRGlzYXN0ZXIgb3IgbGV0J3MganVzdCBzYXkgJnF1 b3Q7TGl2ZSZxdW90OyBUZXJyb3Jpc3QgU2l0dWF0aW9uLiZuYnNwOyBIZSAvb3IgU2hlIG5lZWRz IHRvIGNvbW11bmljYXRpb24gYmFjayB0byBvdGhlciBPZmZpY2lhbHMgdGhhdCBoZSAvb3Igc29t ZWhvdyBpcyBpbiBEYW5nZXIuJm5ic3A7IFRoZSBkZXZpY2UgdXNlZCB0byBjb21tdW5pY2F0ZSBo YXMgYmVlbiBjYXB0dXJlZCBieSB0aGUgZ3JlYXQgbWluZHMgb2YgdGhlIGVuZW15LiZuYnNwOyBJ dCdzIG9ubHkgYSBtYXR0ZXIgb2YgdGltZSBiZWZvcmUgdGhleSB1dGlsaXplIHJldmVyc2UgZW5n aW5lZXJpbmcgdG8gZmlndXJlIG91dCBob3cgaXQgZnVuY3Rpb25zLiZuYnNwOyBIb3dldmVyLCB0 aGVpciBwcmlkZSBjb21lcyBiZWZvcmUgYSBmYWxsIHdoZW4gc2Vla2luZyB0aGUgbG9jYXRpb24g b2Ygb3RoZXIgc2ltaWxhciBkZXZpY2VzIHRvIGF0dGFjay4mbmJzcDsgV2h5PyBQZXJoYXBzIHRo ZSBsZXNzIHRob3VnaHQgb2YgY29uY2VwdHMgdGhhdCBtYWtlcyB0aGUgZGV2aWNlIGZ1bmN0aW9u IHByb3Blcmx5LCBzYXZlcyB0aGUgZGF5IGJ5IGRpc2d1aXNlIG9yIGN1dHRpbmcgaXQgb2ZmIChm aWd1cmF0aXZlbHkgc3BlYWtpbmcpLjxicj48YnI+SnVzdCBhIHZpc2lvbmFyeSB0aG91Z2h0Ljxi cj48YnI+Qy4gSGVucnkgQWRhbXM8YnI+PGEgaHJlZj0ibWFpbHRvOmNoZW5yeWFkYW1zQGJpZW1l ZGlhZ3JvdXAuY29tIj5jaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbTwvYT48YnI+PGEgaHJl Zj0iaHR0cDovL2JpZW1lZGlhZ3JvdXAuY29tIj5odHRwOi8vYmllbWVkaWFncm91cC5jb208L2E+ PGJyPjxicj48YnI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZSBvcmlnaW5hbCByZWNpcGllbnQuIFRoaXMgaW5mb3JtYXRpb24g aXMgZ3JhbnRlZCBmb3IgbGltaXRlZCBkaXN0cmlidXRpb24gd2l0aGluIHRoZSByZWNpcGllbnQn cyBwbGFjZSBvZiBidXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlciBk aXNzZW1pbmF0aW9uLCB3aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuPGJy Pjxicj4tLS0gT24gPGI+TW9uLCAxLzI4LzEzLCBEYXZlIE1pc2VsbCA8aT4mbHQ7PGEgaHJlZj0i bWFpbHRvOmRhdmlkLm1pc2VsbEBiY3Mub3JnIj5kYXZpZC5taXNlbGxAYmNzLm9yZzwvYT4mZ3Q7 PC9pPjwvYj4gd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPkZyb206IERhdmUgTWlzZWxsICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWQubWlzZWxsQGJjcy5vcmciPmRhdmlkLm1pc2VsbEBiY3Mub3JnPC9hPiZndDs8 YnI+U3ViamVjdDogUmU6IFttaWxlXSBJT0NzPGJyPlRvOiAmcXVvdDtDLiBIZW5yeSBBZGFtcyAm YW1wOyBCSUUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGF0bGdhMjAwMEB5YWhvby5jb20i PmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvYT4mZ3Q7PGJyPkRhdGU6IE1vbmRheSwgSmFudWFyeSAy OCwgMjAxMywgOToyNSBQTTxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VUlEIGNvdWxkIGJlIG1pcnJvcmVkIHdpdGggRE5T IFNFQyBhIHBlbWFuZW50IGFuZCB0ZW1wb3JhbCBrZXksIHdpdGggYSB0ZW1wb3JhbCBJZD88YnI+ PGJyPllvdXJzIEZhaXRoZnVsbHksPGJyPjxicj5EYXZlIE1pc2VsbCBNU2MgQ0lTU1A8YnI+U2ls ZW50Q2lyY2xlJm5ic3A7IGRzbTxicj4wNzcxMCAzODAwNDQ8YnI+PGEgaHJlZj0iL21jL2NvbXBv c2U/dG89ZGF2aWQubWlzZWxsQGJjcy5vcmciPmRhdmlkLm1pc2VsbEBiY3Mub3JnPC9hPjxicj48 YnI+PGJyPk9uIDI5IEphbiAyMDEzLCBhdCAwMDozOSwgQy4gSGVucnkgQWRhbXMgJmFtcDsgQklF ICZsdDs8YSBocmVmPSIvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20iPmNoYXRs Z2EyMDAwQHlhaG9vLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0OyBTZXJpYWxpemF0aW9u IG9mIGEgcGFydGljdWxhciBMaXN0cyBvZiBYTUwgQ2xhc3NlcyBpbiBhIHVuaXF1ZSB3YXkgd2Fz IGNsb3NlbHkgcmVsYXRlZCB0byB3aGF0IEkgYXR0ZW1wdGVkIHRvIGV4cHJlc3Mgd2hlbiBJIHN0 YXRlZCwgJnF1b3Q7Y29uc2lkZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBlYXJzIHRvIGJlIGlsbG9n aWNhbCBpbiBicmlsbGlhbnQgbWluZHMgaW4gc29tZSBpbnN0YW5jZXMuJnF1b3Q7PGJyPiZndDsg PGJyPiZndDsgSG93ZXZlciwgSSBzZWUgRHIuIFN0b2Vja2VyJ3MgcG9pbnQgYSBsaXR0bGUgY2xl YXJlci4mbmJzcDsgSG93ZXZlciwgaXQgd291bGQgYmUgbmljZSBpZiB0aGUgVUlEIHdhcyBpbiBz b21lIHdheSBkaXNndWlzZWQgZnJvbSB0aG9zZSB3aG8gc3R1ZHkgdGhpcyBTZWN1cml0eSBBcnQg Rm9ybSBpbiBhIG5lZ2F0aXZlIHdheS48YnI+Jmd0OyA8YnI+Jmd0OyBDLiBIZW5yeSBBZGFtczxi cj4mZ3Q7IDxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbSI+Y2hh dGxnYTIwMDBAeWFob28uY29tPC9hPiAoRGlyZWN0IEVtYWlsKTxicj4mZ3Q7IDxhIGhyZWY9Ii9t Yy9jb21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tIj5jaGVucnlhZGFtc0Bi aWVtZWRpYWdyb3VwLmNvbTwvYT48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIG9y aWdpbmFsIHJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVk IGRpc3RyaWJ1dGlvbiB3aXRoaW4gdGhlIHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZv ciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyIGRpc3NlbWluYXRpb24sIHdoZXRoZXIg cHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC48YnI+Jmd0OyA8YnI+Jmd0OyBSZTogW21p bGVdIElPQ3M8YnI+Jmd0OyA8YnI+Jmd0OyBTdW5kYXksIEphbnVhcnkgMjcsIDIwMTMgODo1MiBQ TTxicj4mZ3Q7IEZyb206PGJyPiZndDsgJnF1b3Q7U3RvZWNrZXIsIFBhdWwmcXVvdDsgJmx0Ozxh IGhyZWY9Ii9tYy9jb21wb3NlP3RvPVBhdWwuU3RvZWNrZXJAcnNhLmNvbSI+UGF1bC5TdG9lY2tl ckByc2EuY29tPC9hPiZndDs8YnI+Jmd0OyBUbzo8YnI+Jmd0OyAmcXVvdDs8YSBocmVmPSIvbWMv Y29tcG9zZT90bz1taWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0iL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPiZndDsgSSB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgdGhpcyBmcm9tIGEgc2xpZ2h0bHkgZGlm ZmVyZW50IHBlcnNwZWN0aXZlxaBsZXQnczxicj4mZ3Q7IHNheSBJIGdldCBhbiBYTUwgZG9jdW1l bnQgdGhhdCB0ZWxscyBtZSBhYm91dCBhbiBpbmNpZGVudC4mbmJzcDsgVGhpcyBkb2N1bWVudDxi cj4mZ3Q7IGhhcyBzb3VyY2UgSVAgYW5kIGRlc3RpbmF0aW9uIElQIHRoYXQgaXMgYmVpbmcgc2hh cmVkLiZuYnNwOyBIb3dldmVyLCB3aGF0IEk8YnI+Jmd0OyBkb24ndCBrbm93IGlzIHdoaWNoIElQ IGFkZHJlc3MgaXMgbXkgaW5kaWNhdG9yIGFuZCB3aGljaCBpcyBqdXN0IGE8YnI+Jmd0OyBjb250 ZXh0dWFsIHBpZWNlIG9mIGluZm9ybWF0aW9uLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgbXkgZGV0 ZWN0aW9uIHByb2R1Y3Q8YnI+Jmd0OyBpc24ndCBnb2luZyB0byBrbm93IHdoaWNoIG9uZSB0byB1 c2UgZWl0aGVyLCBiZWNhdXNlIHRoZXJlIGlzIG5vdGhpbmcgdG88YnI+Jmd0OyB0ZWxsIG1lIHdo aWNoIElQIGlzIHRoZSBvbmUsIGV2ZW4gaWYgdGhlIHJvbGVzIGFyZSBzZXQgaXQgc3RpbGwgbWln aHQgbm90PGJyPiZndDsgYmUgZW5vdWdoIHRvIHRlbGwgbXkgc3lzdGVtIHdoaWNoIG9uZSBJIHNo b3VsZCB1c2UgYXMgdGhlIGluZGljYXRvci48YnI+Jmd0OyA8YnI+Jmd0OyBJZiB3ZSBoYWQgc29t ZXRoaW5nIGxpa2UgaW5kaWNhdG9yX2lkIGFzIGFuIGF0dHJpYnV0ZSwgaXQgd291bGQgYWxsb3cg dXM8YnI+Jmd0OyB0byBlYXNpbHkgaWRlbnRpZnkgaW5kaWNhdG9ycyBmcm9tIGNvbnRleHR1YWwg ZGF0YS4mbmJzcDsgSSBkbyBhZG1pdCB0byBiZWluZzxicj4mZ3Q7IGJpYXNlZCBhcyBJIGhhdmUg c3BlbnQgbXVjaCBvZiBteSBjYXJlZXIgd29ya2luZyBvbiB0aGUgbW9uaXRvcmluZyBhbmQ8YnI+ Jmd0OyBkZXRlY3Rpb24gc2lkZSBvZiB0aGVzZSB0aGluZ3MsIHNvIEkgYW0ganVzdCB0aGlua2lu ZyBvZiB3YXlzIHRvIG1ha2UgaXQ8YnI+Jmd0OyB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGluZGljYXRv cnMgYXJlIGluIHRoZSBYTUwgZG9jdW1lbnQgYW5kIHRoZSBvdGhlciBkYXRhPGJyPiZndDsgdGhh dCBtYXkgYmUgaW1wb3J0YW50IGFzIEkgaW52ZXN0aWdhdGUgYWN0aXZpdHkgdGhhdCBJIGhhdmUg ZGV0ZWN0ZWQgb2ZmPGJyPiZndDsgb2YgdGhvc2UgaW5kaWNhdG9ycy48YnI+Jmd0OyA8YnI+Jmd0 OyA8YnI+Jmd0OyBJIGRpZCBzdWdnZXN0IHRoZSBkZXRlY3Rpb24gY2xhc3MsIGJ1dCBJIHRoaW5r IHdlIG1heSBnZXQgbW9yZSBmbGV4aWJpbGl0eTxicj4mZ3Q7IHdpdGggdGhlIGluZGljYXRvcl91 aWQuJm5ic3A7IE9uZSB0aGluZyB0aGF0IEkgaGF2ZW4ndCBjb25zaWRlcmVkIGlzIHRoZSBVSUQ8 YnI+Jmd0OyBwb3J0aW9uIG9mIHRoaXPFoGhvdyBkbyB3ZSB1c2UgdGhhdCBVSUQ/Jm5ic3A7IEhv dyBpcyB0aGUgVUlEIGNyZWF0ZWQ/Jm5ic3A7IEFyZTxicj4mZ3Q7IHRoZXJlIHN0YW5kYXJkcyBm b3IgVUlEcz88YnI+Jmd0OyA8YnI+Jmd0OyBSZWdhcmRzLDxicj4mZ3Q7IDxicj4mZ3Q7IFBhdWw8 YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBQYXVsIFcuIFN0b2Vja2VyLCBQaC5E Ljxicj4mZ3Q7IFNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0PGJyPiZndDsgUlNBLCBUaGUgU2Vj dXJpdHkgRGl2aXNpb24gb2YgRU1DPGJyPiZndDsgY2VsbDogMzAyLjM3OS4zMzc1IHwgZTogPGEg aHJlZj0iL21jL2NvbXBvc2U/dG89cGF1bC5zdG9lY2tlckByc2EuY29tIj5wYXVsLnN0b2Vja2Vy QHJzYS5jb208L2E+PGJyPiZndDsgPGJyPiZndDsgLS0tIE9uIFNhdCwgMS8yNi8xMywgQy4gSGVu cnkgQWRhbXMgJmFtcDsgQklFICZsdDs8YSBocmVmPSIvbWMvY29tcG9zZT90bz1jaGF0bGdhMjAw MEB5YWhvby5jb20iPmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4mZ3Q7 IDxicj4mZ3Q7IEZyb206IEMuIEhlbnJ5IEFkYW1zICZhbXA7IEJJRSAmbHQ7PGEgaHJlZj0iL21j L2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tIj5jaGF0bGdhMjAwMEB5YWhvby5jb208 L2E+Jmd0Ozxicj4mZ3Q7IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dczxicj4mZ3Q7IFRvOiAmcXVv dDtLYXRobGVlbk1vcmlhcnR5JnF1b3Q7ICZsdDs8YSBocmVmPSIvbWMvY29tcG9zZT90bz1rYXRo bGVlbi5tb3JpYXJ0eUBlbWMuY29tIj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9hPiZndDs8 YnI+Jmd0OyBDYzogPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBp ZXRmLm9yZzwvYT48YnI+Jmd0OyBEYXRlOiBTYXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMywgNjox NyBQTTxicj4mZ3Q7IDxicj4mZ3Q7IEdyZWV0aW5ncyBLYXRobGVlbiw8YnI+Jmd0OyA8YnI+Jmd0 OyBZb3VyIGxvZ2ljIHN0aW11bGF0ZXMgbXkgdmlzaW9uYXJ5IGJyYWluIGJlY2F1c2UgSSdtIGFt YXplZCBhdCB0aGUgbWFueSBhdmVudWVzIHlvdSByZXZpZXcgd2l0aCB0aGlzIGFwcHJvYWNoIGF0 IG9uY2UuJm5ic3A7IEhvd2V2ZXIsJm5ic3A7IGNvdWxkIHlvdSBzaGFyZSBhIGZldyBhZHZhbnRh Z2VzIGFuZCBkaXNhZHZhbnRhZ2VzIHRvIHRoZSBsYXR0ZXI/PGJyPiZndDsgPGJyPiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+Jmd0OyAmcXVvdDt3ZSBjb3VsZCBjb250aW51ZSB0byBncm91cCBpdGVtcyBpbiBs b2dpY2FsIHBsYWNlcyBhcyBpcyBkb25lIG5vdyBpbiBJT0RFRiBhbmQgdGhlbiBoYXZlIHRoZSBl eHRlbnNpb24gcG9pbnQgZm9yIGNvbWJpbmVkIGluZGljYXRvcnMgdmlhIFNDSS4mcXVvdDs8YnI+ Jmd0OyA8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgPGJyPiZndDsgWW91IHBvaW50ZWQgb3V0IHdo YXQgeW91IGNvbnNpZGVyIHRvIGJlIGxvZ2ljYWwgcGxhY2VzLCBidXQgaWYgSSB3YW50ZWQgdG8g cHJvdGVjdCBpbmZvcm1hdGlvbiBmcm9tIHBhcnRpZXMgY2FwYWJsZSBvZiBhc2NlcnRhaW5pbmcg aXQgZnJvbSB5b3VyIGxvZ2ljYWwgcGxhY2VzLCBwZXJoYXBzIHdlIHNob3VsZCBhbHNvIGNvbnNp ZGVyIHRvIGEgZGVncmVlIHdoYXQgYXBwZWFycyB0byBiZSBpbGxvZ2ljYWwgaW4gYnJpbGxpYW50 IG1pbmRzIGluIHNvbWUgaW5zdGFuY2VzLjxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4m Z3Q7IEMuIEhlbnJ5IEFkYW1zPGJyPiZndDsgPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89Y2hhdGxn YTIwMDBAeWFob28uY29tIj5jaGF0bGdhMjAwMEB5YWhvby5jb208L2E+IChEaXJlY3QgRW1haWwp PGJyPiZndDsgPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91 cC5jb20iPmNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPC9hPjxicj4mZ3Q7IDxicj4mZ3Q7 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVz ZSBvZiB0aGUgb3JpZ2luYWwgcmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQg Zm9yIGxpbWl0ZWQgZGlzdHJpYnV0aW9uIHdpdGhpbiB0aGUgcmVjaXBpZW50J3MgcGxhY2Ugb2Yg YnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1cnBvc2VzIG9ubHkuIEZ1cnRoZXIgZGlzc2VtaW5hdGlv biwgd2hldGhlciBwcml2YXRlIG9yIHB1YmxpYyBpcyBwcm9oaWJpdGVkLjxicj4mZ3Q7IDxicj4m Z3Q7IC0tLSBPbiBTYXQsIDEvMjYvMTMsIE1vcmlhcnR5LCBLYXRobGVlbiAmbHQ7PGEgaHJlZj0i L21jL2NvbXBvc2U/dG89a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSI+a2F0aGxlZW4ubW9yaWFy dHlAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4mZ3Q7IDxicj4mZ3Q7IEZyb206IE1vcmlhcnR5 LCBLYXRobGVlbiAmbHQ7PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89a2F0aGxlZW4ubW9yaWFydHlA ZW1jLmNvbSI+a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTwvYT4mZ3Q7PGJyPiZndDsgU3ViamVj dDogUkU6IFttaWxlXSBJT0NzPGJyPiZndDsgVG86ICZxdW90O0MuIEhlbnJ5IEFkYW1zICZhbXA7 IEJJRSZxdW90OyAmbHQ7PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28u Y29tIj5jaGF0bGdhMjAwMEB5YWhvby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0iL21jL2Nv bXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Ii9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4mZ3Q7IERhdGU6IFNhdHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzLCAxMDoxMyBBTTxicj4mZ3Q7 IDxicj4mZ3Q7IEhlbGxvIEMuIEhlbnJ5ICZhbXA7IG90aGVycyw8YnI+Jmd0OyA8YnI+Jmd0OyBU aGFua3MgZm9yIHRha2luZyBhIGxvb2sgYXQgdGhpcy4mbmJzcDsgV2UgaGF2ZSBhIGZldyBjb25z aWRlcmF0aW9ucyBpbiB0aGlzIGVtYWlsIHRocmVhZCBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aG91 Z2h0cyBvbiAoYW5kIHRoZXJlIG1heSBiZSBtb3JlIG9uY2UgUkZDNTA3MC1iaXMgaXMgYWN0aXZl bHkgZWRpdGVkKS48YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgQWRkaXRpb25hbERhdGEgY2xhc3MgYW5k IHRoZSBSZWNvcmRJdGVtIGNsYXNzIGJvdGggYWxsb3cgZm9yIG5vbi1YTUwgZXh0ZW5zaW9ucy4m bmJzcDsgV2hlcmUgeW91IHBsYWNlIHRoZSBleHRlbnNpb25zIHNob3VsZCBiZSBzcGVjaWZpYyB0 byB0aGUgbG9naWNhbCBncm91cGluZyBvZiB0aGUgcGFyZW50IGVsZW1lbnRzIHNvIHlvdSBjYW4g dW5kZXJzdGFuZCBtb3JlIGFib3V0IHRoZSBpbmNsdWRlZCBkYXRhIGluIG1vc3QgY2FzZXMuJm5i c3A7IDxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBJbXBhY3QgY2xhc3MgY2FuIGJlIHVzZWQgdG8gcHJv dmlkZSBjb250ZXh0IGluZm9ybWF0aW9uIG9uIHRoZSBpbmNsdWRlZCBkYXRhIG9mIHRoZSByZXBv cnQgYW5kIGFsc28gY2FuIGluY2x1ZGUgYSBjb25maWRlbmNlIHJhdGluZyBvbiB0aGUgcmVwb3J0 IGFzIGEgd2hvbGUuJm5ic3A7IEV4dGVuc2lvbnMgcmVsYXRlZCB0byBpbXBhY3Qgd291bGQgYmUg b25lIGxldmVsIGhpZ2hlciAoYXQgdGhlIG1vbWVudCkgaW4gdGhlIEFzc2Vzc21lbnQgY2xhc3Mg dXNpbmcgdGhlIEFkZGl0aW9uYWxEYXRhIGV4dGVuc2lvbiBwb2ludC4mbmJzcDsgPGJyPiZndDsg PGJyPiZndDsgVGFrZSBhc2tlZCBhYm91dCBpbmNsdWRpbmcgdnVsbmVyYWJpbGl0eSBpbmZvcm1h dGlvbiwgSSB3b3VsZCB0aGluayB0aGF0IHdvdWxkIGZpdCB1bmRlciB0aGUgVnVsbmVyYWJpbGl0 eSBleHRlbnNpb24gcG9pbnQgb2YgdGhlIFNDSSBkcmFmdCBpbiB0aGUgTWV0aG9kIGNsYXNzLiZu YnNwOyBIZSBkaWQgYXNrIGFib3V0IG5vbi1YTUwuJm5ic3A7IFJlY29yZEl0ZW0gb3IgQWRkaXRp b25hbERhdGEgZG8gYWxsb3cgZm9yIG5vbi1YTUwgZXh0ZW5zaW9uIHBvaW50cywgd2UgY291bGQg ZWl0aGVyIGhhdmUgdGhlIFNDSSBkcmFmdCBoYW5kbGUgdGhlc2UgYXMgd2VsbCBvciBoYXZlIHRo ZSBleHRlbnNpb25zIHRoYXQgYXJlIG5vbi1YTUwgY29tZSBkaXJlY3RseSBvZmYgdGhlIEFkZGl0 aW9uYWxEYXRhIG9yIFJlY29yZEl0ZW0gY2xhc3NlcyBhY2NvcmRpbmcgdG8gd2hhdCBtYWtlcyBz ZW5zZSBmcm9tIGEgbG9naWNhbCBzdGFuZHBvaW50Ljxicj4mZ3Q7IDxicj4mZ3Q7IEFzIGZvciBt eSBxdWVzdGlvbiwgaXQgd2FzIHR3by1mb2xkLjxicj4mZ3Q7IDxicj4mZ3Q7IEluZGljYXRvciBi YXNlZCBzY2hlbWFzIGhhdmUgYSByZWZlcmVuY2UgbnVtYmVyIG9yIGEgR1VJRCBmb3IgdGhlIHZh cmlvdXMgaW5kaWNhdG9ycyB0aGV5IHNoYXJlLiZuYnNwOyBJZiB3ZSBhcmUgZXh0ZW5kaW5nIHRv IGVtYmVkIG90aGVyIHNjaGVtYXMgdGhhdCBpbmNsdWRlIHN1Y2ggcmVmZXJlbmNlIG9yIEdVSUQg aWRlbnRpZmllcnMsIGRvIHdlIHdhbnQgdG8gYWRkIGFuIGF0dHJpYnV0ZSB0byB0aGUgdmFyaW91 cyBlbGVtZW50cyBpbiBJT0RFRiB0aGF0IGNvdWxkIGJlIGluZGljYXRvcnM/Jm5ic3A7IElzIHRo aXMgZW5vdWdoIHRvIG1ha2UgdGhlIGNvbm5lY3Rpb25zIG9yIGlzIHNvbWV0aGluZyBlbHNlIGVs c2UgbmVlZGVkPyZuYnNwOyBXZSBjb3VsZCBhZGQgc29tZXRoaW5nIGxpa2UgYW4gSW5kaWNhdG9y X0lEIGluIFJGQzUwNzAtYmlzIHdoaWNoIHdvdWxkIHRoZW4gY29ycmVsYXRlIHRvIHRoZSByZWZl cmVuY2Ugb3IgR1VJRCBpZGVudGlmaWVycy48YnI+Jmd0OyA8YnI+Jmd0OyBUaGVuIHRoZSBvdGhl ciBxdWVzdGlvbiB3YXMgb24gaG93IHRvIGluY2x1ZGUgaW5kaWNhdG9ycyB0aGF0IGFyZSBub3Qg aW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IGJlIHJlbGF0ZWQgb3IgaGF2ZSBsYW5ndWFnZSB3 aXRoICZxdW90O2FuZCZxdW90OyAmcXVvdDtvciZxdW90OyB0byBzcGVjaWZ5IHRoZSByZWxhdGlv bnNoaXBzLiZuYnNwOyBJbiBzb21lIGNhc2VzLCB5b3Ugd2lsbCB3YW50IHRvIGdyb3VwIHRoZXNl IGluZGljdG9ycyBpbiBvbmUgZXh0ZW5zaW9uIHBvaW50LCB3aGVyZSB0aGV5IG1heSBmaXQgbG9n aWNhbGx5IGluIG11bHRpcGxlIHBsYWNlcyBpZiB0aGUgcmVsYXRpb25zaGlwcyBkaWQgbm90IG5l ZWQgdG8gYmUgc2hvd24gaW4gdGhlIGRhdGEgZm9ybWF0LiZuYnNwOyBJZiB3ZSBoYXZlIGNhc2Vz IGxpa2UgdGhpcyB3aGVyZSB5b3UgbmVlZCBtb3JlIGNvbXBsZXggcmVwcmVzZW50YXRpb25zLCBz aG91bGQgd2UgdXNlIG9uZSBleHRlbnNpb24gcG9pbnQgdmlhIHRoZSBTQ0kgZHJhZnQgb2ZmIG9m IHRoZSBFdmVudERhdGEgY2xhc3MgQWRkaXRpb25hbERhdGEgZXh0ZW5zaW9uIHBvaW50PyZuYnNw OyBPcGluaW9ucyBhcmUgbmVlZGVkIGhlcmUuLi4uIDxicj4mZ3Q7IDxicj4mZ3Q7IEEgZmV3IHBl b3BsZSBoYXZlIG1lbnRpb25lZCB3YW50aW5nIHRvIGluY2x1ZGUgc29tZSBjb21tb25seSBzaGFy ZWQgaW5kaWN0b3JzIGludG8gdGhlIGJhc2UgSU9ERUYgZG9jdW1lbnQuJm5ic3A7IFdlIGNvdWxk IGhhdmUgYSBjYXRjaC1hbGwgY2xhc3MgdGhhdCBkb2VzIHRoaXMgYW5kIGhhcyBhbiBleHRlbnNp b24gcG9pbnQgb2ZmIG9mIGl0IGluIEV2ZW50RGF0YSBvciB3ZSBjb3VsZCBjb250aW51ZSB0byBn cm91cCBpdGVtcyBpbiBsb2dpY2FsIHBsYWNlcyBhcyBpcyBkb25lIG5vdyBpbiBJT0RFRiBhbmQg dGhlbiBoYXZlIHRoZSBleHRlbnNpb24gcG9pbnQgZm9yIGNvbWJpbmVkIGluZGljYXRvcnMgdmlh IFNDSS4mbmJzcDsgSSB0aGluayBJIGxpa2UgdGhlIGxhdHRlciBhcHByb2FjaC48YnI+Jmd0OyA8 YnI+Jmd0OyBUaGFuayB5b3UsPGJyPiZndDsgS2F0aGxlZW48YnI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgRnJvbTogPGEgaHJlZj0iL21jL2Nv bXBvc2U/dG89bWlsZS1ib3VuY2VzQGlldGYub3JnIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSIvbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmciPm1pbGUtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBDLiBIZW5yeSBBZGFtcyAmYW1wOyBCSUUg WzxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbSI+Y2hhdGxnYTIw MDBAeWFob28uY29tPC9hPl08YnI+Jmd0OyBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAyNiwgMjAx MyAzOjA1IEFNPGJyPiZndDsgVG86IDxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5v cmciPm1pbGVAaWV0Zi5vcmc8L2E+PGJyPiZndDsgQ2M6IEMuIEhlbnJ5IEFkYW1zPGJyPiZndDsg U3ViamVjdDogUmU6IFttaWxlXSBJT0NzPGJyPiZndDsgPGJyPiZndDsgR3JlZXRpbmdzIEV2ZXJ5 b25lLDxicj4mZ3Q7IDxicj4mZ3Q7IFRha2UgbWVudGlvbmVkIHR3byB0eXBlcyBvZiBpbmRpY2F0 b3JzIGJhc2VkIG9uIHRoZSA6PGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgMSkgSWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGlu ZyBsaWtlIGFuIFhNTC1iYXNlZCBhbGVydC93YXJuaW5nIG9mPGJyPiZndDsgaW5mb3JtYXRpb24g bGVha2FnZSwgaXQgY291bGQgYmUgYW4gZXZlbnQgdGhhdCBhcmUgY29udmV5ZWQgaW4gdGhlIFND SSdzPGJyPiZndDsgRXZlbnRSZXBvcnQgY2xhc3MsIElNSE8uPGJyPiZndDsgPGJyPiZndDsgMikg SWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGluZyBsaWtlIGFuIG5vbi1YTUwgb25lcywgSSBn dWVzcyBpdCBjb3VsZCBiZTxicj4mZ3Q7IGNvbnZleWVkIHdpdGhvdXQgdXNpbmcgU0NJIGRyYWZ0 Ljxicj4mZ3Q7IEZvciBpbnN0YW5jZSwgd2UgY291bGQgdXNlIEltcGFjdCBjbGFzcyBvZiB0aGUg YmFzZSBJT0RFRiB0byBjb252ZXkgdGhlPGJyPiZndDsgaW5kaWNhdG9ycy48YnI+Jmd0OyBXZSBj b3VsZCBmb3IgaW5zdGFuY2UgZXh0ZW5kIHRoZSBsaXN0IG9mIGluZGljYXRvcnMgb2YgdGhlIElt cGFjdCBjbGFzcywgaWY8YnI+Jmd0OyBuZWVkZWQuPGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgPGJyPiZndDsgSW4gZG9pbmcgc28g aGUgcG9pbnRlZCBvdXQgdGhlICZxdW90O0ltcGFjdCBDbGFzcyZxdW90Ozxicj4mZ3Q7IDxicj4m Z3Q7IFdoZXJlYXMsIEthdGhsZWVuIHN0YXRlZCw8YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IEZvciB0aGUgZGlzY3Vz c2lvbiBiZWxvdywgSSB3YXMgdGhpbmtpbmcgbW9yZSBvZiBjb21iaW5lZCBzZXQgd2l0aCByZWxh dGlvbnNoaXBzIHRoYXQgbWF5IGJlIGluY2x1ZGVkIGluIGEgc2luZ2xlIGV4dGVuc2lvbiBwb2lu dCwgc28gdGhhdCdzIHdoeSBJIHdhcyB0aGlua2luZyBhYm91dCB0aGUgRXZlbnREYXRhIGNsYXNz LCBidXQgdGhlcmUgbWF5IGJlIGJldHRlciBsb2NhdGlvbnMgb3IgYSBzcGVjaWZpYyBhcmVhIHdp dGhpbiB0aGUgRXZlbnREYXRhLjxicj4mZ3Q7IDxicj4mZ3Q7IFBhdWwgU3RvZWNrZXIgaGFkIHN1 Z2dlc3RlZCBhICZxdW90O0RldGVjdGlvbiZxdW90OyBjbGFzcyBhcyBhIGNvbnNpZGVyYXRpb24u PGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4m Z3Q7IDxicj4mZ3Q7IEthdGhsZWVuIHRob3VnaHRzIHJlbGF0ZWQgeWV0IHN0aWxsIHdpdGggb3Ro ZXIgaW5kaWNhdG9ycyBhbmQgdGhlIEV2ZW50RGF0YSBDbGFzcy48YnI+Jmd0OyA8YnI+Jmd0OyBJ cyB0aGVyZSBhIHBvc3NpYmxlIHdheSB0byBjcmVhdGUgYSBuZXcgWE1MIGNsYXNzIHdoaWNoIGVu Y29tcGFzcyBjb21iaW5pbmcgdGhlIEV2ZW50RGF0YSwgRGV0ZWN0aW9uIGFuZCBiYXNlIElPREVG IGNsYXNzZXMgdG8gc2ltcGxpZnkgdGhpcyBpc3N1ZT88YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0 OyBDLiBIZW5yeSBBZGFtczxicj4mZ3Q7IDxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWNoYXRsZ2Ey MDAwQHlhaG9vLmNvbSI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPiAoRGlyZWN0IEVtYWlsKTxi cj4mZ3Q7IDxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAu Y29tIj5jaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbTwvYT48YnI+Jmd0OyA8YnI+Jmd0OyA8 YnI+Jmd0OyBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIG9yaWdpbmFsIHJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBn cmFudGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW4gdGhlIHJlY2lwaWVudCdzIHBs YWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyIGRpc3Nl bWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC48YnI+Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7 IG1pbGUgbWFpbGluZyBsaXN0PGJyPiZndDsgPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bWlsZUBp ZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PG86cD48L286cD48L3A+PC9kaXY+ PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_F5063677821E3B4F81ACFB7905573F24CE9E2823MX15Acorpemccom_-- From Christopher.Harrington@emc.com Fri Feb 1 09:01:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2735121E80BC for ; Fri, 1 Feb 2013 09:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUkgzTPYf6wh for ; Fri, 1 Feb 2013 09:01:25 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1C321E80BB for ; Fri, 1 Feb 2013 09:01:21 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r11H1K3r005657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2013 12:01:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Fri, 1 Feb 2013 12:01:00 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r11H0wi9028496 for ; Fri, 1 Feb 2013 12:00:59 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Fri, 1 Feb 2013 12:00:57 -0500 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , MILE IETF Date: Fri, 1 Feb 2013 12:00:56 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac392LfqtE12Sv21RDmeR7wzUTqasgCvxeJgAADUQZA= Message-ID: References: <71238F9C-AD03-44B9-A065-541351FB4087@bcs.org> <1359433497.20429.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AC2_01CE0073.CA46F510" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:01:27 -0000 ------=_NextPart_000_0AC2_01CE0073.CA46F510 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0AC3_01CE0073.CA46F510" ------=_NextPart_001_0AC3_01CE0073.CA46F510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related: =20 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise.=20 =20 Two or more indicators of the same type that relate to the same threat:=20 2 different registry values for the same registry key. If either value = is present it is a compromise indicator but both will not be present.=20 =20 The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that = logical groupings of Indicators are related as well. We can=E2=80=99t = send multiple IODEF messages for this from what I remember reading.=20 =20 The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=E2=80=99s not uncommon = to send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping.=20 =20 Thoughts? =20 Thanks, =20 --Chris =20 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =20 All =E2=80=93=20 =20 I=E2=80=99d like your input and will refocus the thread to get opinions = from the list on options to help solve the problems raised in my message = and additionally in Paul=E2=80=99s message. =20 Interesting point, C. Henry. Our objective here is to have machine = automated exchanges, so we rely on encryption rather than obfuscation to = achieve the necessary level of confidentiality. =20 Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators. The question I raised was on how to connect sets = of indicators in the same IODEF document, assuming the ability to have = watchlists that could have several sets of indicators included, as well = as to connect indicators that may be included in embedded schemas. =20 If we add an attribute on all of the relevant indicators, let=E2=80=99s = say =E2=80=98indicator-uid=E2=80=99 how do we mark the indicators? Do = we use this to mark who sent the indicator as well so that we can = prevent forward sharing when it is not permitted or handle that = separately? =20 =20 Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message). =20 Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =20 Temporal Dependency sounds interesting. I remember when I first ran = across this particular craft, an experienced colleague asked me a = peculiar question. He said, " How do you stop someone from tracking the = IP Address to your computer?" =20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off and the modem that it is = connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder = searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation. He /or She needs to = communication back to other Officials that he /or somehow is in Danger. = The device used to communicate has been captured by the great minds of = the enemy. It's only a matter of time before they utilize reverse = engineering to figure out how it functions. However, their pride comes = before a fall when seeking the location of other similar devices to = attack. Why? Perhaps the less thought of concepts that makes the device = function properly, saves the day by disguise or cutting it off = (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a = temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE = wrote: > Serialization of a particular Lists of XML Classes in a unique way was = closely related to what I attempted to express when I stated, "consider = to a degree what appears to be illogical in brilliant minds in some = instances." >=20 > However, I see Dr. Stoecker's point a little clearer. However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different = perspective=C5=A0let's > say I get an XML document that tells me about an incident. This = document > has source IP and destination IP that is being shared. However, what = I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing = to > tell me which IP is the one, even if the roles are set it still might = not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow = us > to easily identify indicators from contextual data. I do admit to = being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make = it > very clear what the indicators are in the XML document and the other = data > that may be important as I investigate activity that I have detected = off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more = flexibility > with the indicator_uid. One thing that I haven't considered is the = UID > portion of this=C5=A0how do we use that UID? How is the UID created? = Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once. However, could you = share a few advantages and disadvantages to the latter? >=20 > = -------------------------------------------------------------------------= ------------------------------------------------- > "we could continue to group items in logical places as is done now in = IODEF and then have the extension point for combined indicators via = SCI." >=20 > = -------------------------------------------------------------------------= ------------------------------------------------ >=20 > You pointed out what you consider to be logical places, but if I = wanted to protect information from parties capable of ascertaining it = from your logical places, perhaps we should also consider to a degree = what appears to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" = > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this. We have a few considerations in = this email thread I would like to hear thoughts on (and there may be = more once RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for = non-XML extensions. Where you place the extensions should be specific = to the logical grouping of the parent elements so you can understand = more about the included data in most cases. =20 >=20 > The Impact class can be used to provide context information on the = included data of the report and also can include a confidence rating on = the report as a whole. Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point. =20 >=20 > Take asked about including vulnerability information, I would think = that would fit under the Vulnerability extension point of the SCI draft = in the Method class. He did ask about non-XML. RecordItem or = AdditionalData do allow for non-XML extension points, we could either = have the SCI draft handle these as well or have the extensions that are = non-XML come directly off the AdditionalData or RecordItem classes = according to what makes sense from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the = various indicators they share. If we are extending to embed other = schemas that include such reference or GUID identifiers, do we want to = add an attribute to the various elements in IODEF that could be = indicators? Is this enough to make the connections or is something else = else needed? We could add something like an Indicator_ID in RFC5070-bis = which would then correlate to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not = in the base schema that may be related or have language with "and" "or" = to specify the relationships. In some cases, you will want to group = these indictors in one extension point, where they may fit logically in = multiple places if the relationships did not need to be shown in the = data format. If we have cases like this where you need more complex = representations, should we use one extension point via the SCI draft off = of the EventData class AdditionalData extension point? Opinions are = needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared = indictors into the base IODEF document. We could have a catch-all class = that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF = and then have the extension point for combined indicators via SCI. I = think I like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > = -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the = SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it = could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey = the > indicators. > We could for instance extend the list of indicators of the Impact = class, if > needed. > = -------------------------------------------------------------------------= ----------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > = -------------------------------------------------------------------------= ---------------------------- > For the discussion below, I was thinking more of combined set with = relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be = better locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > = -------------------------------------------------------------------------= --------------------------- >=20 > Kathleen thoughts related yet still with other indicators and the = EventData Class. >=20 > Is there a possible way to create a new XML class which encompass = combining the EventData, Detection and base IODEF classes to simplify = this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0AC3_01CE0073.CA46F510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related:

 

Two or more indicators of different type that relate to the same = threat:

The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise. =

 

Two or more indicators of the same type that relate to the same = threat:

2 different registry values for the same registry key. If either = value is present it is a compromise indicator but both will not be = present.

 

The problem compounds itself very quickly. Consider the scenario = where both groupings above are part of the same threat. I need to show = that logical groupings of Indicators are related as well. We = can=E2=80=99t send multiple IODEF messages for this from what I remember = reading.

 

The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=E2=80=99s not uncommon = to send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping.

 

Thoughts?=

 

Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security Engineer

GSO - Critical Incident Response Center

EMC - Where Information Lives

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 = AM
To: MILE IETF
Subject: Re: [mile] = IOCs

 

All =E2=80=93

 

I=E2=80=99d like your input and will refocus the thread to get = opinions from the list on options to help solve the problems raised in = my message and additionally in Paul=E2=80=99s = message.

 

Interesting point, C. Henry.  Our objective here is to have = machine automated exchanges, so we rely on encryption rather than = obfuscation to achieve the necessary level of = confidentiality.

 

Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators.  The question I raised was on how to connect = sets of indicators in the same IODEF document, assuming the ability to = have watchlists that could have several sets of indicators included, as = well as to connect indicators that may be included in embedded = schemas.

 

If we add an attribute on all of the relevant indicators, = let=E2=80=99s say =E2=80=98indicator-uid=E2=80=99 how do we mark the = indicators?  Do we use this to mark who sent the indicator as well = so that we can prevent forward sharing when it is not permitted or = handle that separately? 

 

Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message).

 

Comments and questions encouraged to figure out the right technical = solution to have this machine automatable.

 

Thank you,

Kathleen

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of C. Henry Adams & BIE
Sent: = Monday, January 28, 2013 11:25 PM
To: MILE = IETF
Subject: Re: [mile] IOCs

 

Temporal = Dependency sounds interesting.  I remember when I first ran across = this particular craft, an experienced colleague asked me a peculiar = question.  He said, " How do you stop someone from tracking = the IP Address to your computer?" 

I replied, "I = don't know, how?"

Then he said, "Cut the dog-gone = thing off  and the modem that it is connected- which is constantly = on!"   LOL

Here's my point (Hypothetical = Situation) :  There is a 1st Responder searching a Neighborhood for = Survivors which were hit by a Disaster or let's just say = "Live" Terrorist Situation.  He /or She needs to = communication back to other Officials that he /or somehow is in = Danger.  The device used to communicate has been captured by the = great minds of the enemy.  It's only a matter of time before they = utilize reverse engineering to figure out how it functions.  = However, their pride comes before a fall when seeking the location of = other similar devices to attack.  Why? Perhaps the less thought of = concepts that makes the device function properly, saves the day by = disguise or cutting it off (figuratively speaking).

Just a = visionary thought.

C. Henry Adams
chenryadams@biemediagroup.c= om
http://biemediagroup.com

The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is = prohibited.

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org>= wrote:


From: Dave Misell <david.misell@bcs.org>
Subj= ect: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Da= te: Monday, January 28, 2013, 9:25 PM

UID could be mirrored = with DNS SEC a pemanent and temporal key, with a temporal = Id?

Yours Faithfully,

Dave Misell MSc = CISSP
SilentCircle  dsm
07710 380044
david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:

> Serialization of a particular Lists of XML = Classes in a unique way was closely related to what I attempted to = express when I stated, "consider to a degree what appears to be = illogical in brilliant minds in some instances."
>
> = However, I see Dr. Stoecker's point a little clearer.  However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way.
>
> C. Henry = Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
>
> Re: [mile] = IOCs
>
> Sunday, January 27, 2013 8:52 PM
> = From:
> "Stoecker, Paul" <Paul.Stoecker@rsa.com= >
> To:
> "mile@ietf.org" <mile@ietf.org>
> I = would like to look at this from a slightly different = perspective=C5=A0let's
> say I get an XML document that tells me = about an incident.  This document
> has source IP and = destination IP that is being shared.  However, what I
> don't = know is which IP address is my indicator and which is just a
> = contextual piece of information.  This means that my detection = product
> isn't going to know which one to use either, because = there is nothing to
> tell me which IP is the one, even if the = roles are set it still might not
> be enough to tell my system = which one I should use as the indicator.
>
> If we had = something like indicator_id as an attribute, it would allow us
> = to easily identify indicators from contextual data.  I do admit to = being
> biased as I have spent much of my career working on the = monitoring and
> detection side of these things, so I am just = thinking of ways to make it
> very clear what the indicators are = in the XML document and the other data
> that may be important as = I investigate activity that I have detected off
> of those = indicators.
>
>
> I did suggest the detection class, = but I think we may get more flexibility
> with the = indicator_uid.  One thing that I haven't considered is the = UID
> portion of this=C5=A0how do we use that UID?  How is = the UID created?  Are
> there standards for UIDs?
> =
> Regards,
>
> Paul
>
>
> =
> Paul W. Stoecker, Ph.D.
> SMC Lead Content = Architect
> RSA, The Security Division of EMC
> cell: = 302.379.3375 | e: paul.stoecker@rsa.com=
>
> --- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:
>
> From: C. Henry Adams & BIE <chatlga2000@yahoo.com= >
> Subject: RE: [mile] IOCs
> To: = "KathleenMoriarty" <kathleen.moriarty@emc= .com>
> Cc: mile@ietf.org
> Date: = Saturday, January 26, 2013, 6:17 PM
>
> Greetings = Kathleen,
>
> Your logic stimulates my visionary brain = because I'm amazed at the many avenues you review with this approach at = once.  However,  could you share a few advantages and = disadvantages to the latter?
>
> = -------------------------------------------------------------------------= -------------------------------------------------
> "we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via = SCI."
>
> = -------------------------------------------------------------------------= ------------------------------------------------
>
> You = pointed out what you consider to be logical places, but if I wanted to = protect information from parties capable of ascertaining it from your = logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances.
>
> =
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
> The information contained herein is = for the exclusive use of the original recipient. This information is = granted for limited distribution within the recipient's place of = business for planning purposes only. Further dissemination, whether = private or public is prohibited.
>
> --- On Sat, 1/26/13, = Moriarty, Kathleen <kathleen.moriarty@emc= .com> wrote:
>
> From: Moriarty, Kathleen <kathleen.moriarty@emc= .com>
> Subject: RE: [mile] IOCs
> To: "C. Henry = Adams & BIE" <chatlga2000@yahoo.com= >, "mile@ietf.org" <mile@ietf.org>
> = Date: Saturday, January 26, 2013, 10:13 AM
>
> Hello C. = Henry & others,
>
> Thanks for taking a look at = this.  We have a few considerations in this email thread I would = like to hear thoughts on (and there may be more once RFC5070-bis is = actively edited).
>
> The AdditionalData class and the = RecordItem class both allow for non-XML extensions.  Where you = place the extensions should be specific to the logical grouping of the = parent elements so you can understand more about the included data in = most cases. 
>
> The Impact class can be used to = provide context information on the included data of the report and also = can include a confidence rating on the report as a whole.  = Extensions related to impact would be one level higher (at the moment) = in the Assessment class using the AdditionalData extension point.  =
>
> Take asked about including vulnerability information, = I would think that would fit under the Vulnerability extension point of = the SCI draft in the Method class.  He did ask about non-XML.  = RecordItem or AdditionalData do allow for non-XML extension points, we = could either have the SCI draft handle these as well or have the = extensions that are non-XML come directly off the AdditionalData or = RecordItem classes according to what makes sense from a logical = standpoint.
>
> As for my question, it was = two-fold.
>
> Indicator based schemas have a reference = number or a GUID for the various indicators they share.  If we are = extending to embed other schemas that include such reference or GUID = identifiers, do we want to add an attribute to the various elements in = IODEF that could be indicators?  Is this enough to make the = connections or is something else else needed?  We could add = something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers.
>
> Then the other = question was on how to include indicators that are not in the base = schema that may be related or have language with "and" = "or" to specify the relationships.  In some cases, you = will want to group these indictors in one extension point, where they = may fit logically in multiple places if the relationships did not need = to be shown in the data format.  If we have cases like this where = you need more complex representations, should we use one extension point = via the SCI draft off of the EventData class AdditionalData extension = point?  Opinions are needed here....
>
> A few people = have mentioned wanting to include some commonly shared indictors into = the base IODEF document.  We could have a catch-all class that does = this and has an extension point off of it in EventData or we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI.  I = think I like the latter approach.
>
> Thank you,
> = Kathleen
> ________________________________________
> From: = mile-bounces@ietf.org= [mile-bounces@ietf.org= ] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com= ]
> Sent: Saturday, January 26, 2013 3:05 AM
> To: mile@ietf.org
> Cc: C. = Henry Adams
> Subject: Re: [mile] IOCs
>
> Greetings = Everyone,
>
> Take mentioned two types of indicators based = on the :
> = -------------------------------------------------------------------------= -----------------------------
> 1) If the indicators are something = like an XML-based alert/warning of
> information leakage, it could = be an event that are conveyed in the SCI's
> EventReport class, = IMHO.
>
> 2) If the indicators are something like an = non-XML ones, I guess it could be
> conveyed without using SCI = draft.
> For instance, we could use Impact class of the base IODEF = to convey the
> indicators.
> We could for instance extend = the list of indicators of the Impact class, if
> needed.
> = -------------------------------------------------------------------------= -----------------------------
>
> In doing so he pointed = out the "Impact Class"
>
> Whereas, Kathleen = stated,
>
> = -------------------------------------------------------------------------= ----------------------------
> For the discussion below, I was = thinking more of combined set with relationships that may be included in = a single extension point, so that's why I was thinking about the = EventData class, but there may be better locations or a specific area = within the EventData.
>
> Paul Stoecker had suggested a = "Detection" class as a consideration.
> = -------------------------------------------------------------------------= ---------------------------
>
> Kathleen thoughts related = yet still with other indicators and the EventData Class.
> =
> Is there a possible way to create a new XML class which = encompass combining the EventData, Detection and base IODEF classes to = simplify this issue?
>
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
> = _______________________________________________
> mile mailing = list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile

 =

------=_NextPart_001_0AC3_01CE0073.CA46F510-- ------=_NextPart_000_0AC2_01CE0073.CA46F510 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMDEx NzAwNTVaMCMGCSqGSIb3DQEJBDEWBBQrW/dzEhpFQZKqwXqDK7Kwz4cmdTCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAxaFjf5m2rpxhWRQDhfAtb0QmCnkOFI+jmuRHYUPvh1cregUi0ILwvwA3qDOKcy3C NaQgHaVzRxNcHg3iAvg08UYF10Fc9Y/0Oo5Yro9stJ9PIBWR9wezEKDC/G+Ku6Y/uxlGQ4Xp2Kjc g77qRU4QttH/4SvTTyfmST5WuN0zTzAJQOD2FgVH20RzIM1nlSk2jMibL8m5AFdDEQLTiHwk4gLa YkZlgrP5ndrcnBg8FOP8dcNFesTewQ7bk7YIXRC7y+L+uYQbKrgNO46BE53vL2Ehb6PJU132+N18 +2qJG8ll14CrPzgrHuu0Tg88nplM8sLvkamAmjwlc747KS83BgAAAAAAAA== ------=_NextPart_000_0AC2_01CE0073.CA46F510-- From chatlga2000@yahoo.com Fri Feb 1 11:24:26 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B312F21E8049 for ; Fri, 1 Feb 2013 11:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.064 X-Spam-Level: **** X-Spam-Status: No, score=4.064 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_40=-0.185, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owh6NRuXfX73 for ; Fri, 1 Feb 2013 11:24:24 -0800 (PST) Received: from nm10-vm0.bullet.mail.ne1.yahoo.com (nm10-vm0.bullet.mail.ne1.yahoo.com [98.138.91.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49FCF21E8044 for ; Fri, 1 Feb 2013 11:24:24 -0800 (PST) Received: from [98.138.90.48] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 19:24:23 -0000 Received: from [98.138.89.248] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 19:24:23 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 19:24:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 56015.64189.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 72420 invoked by uid 60001); 1 Feb 2013 19:24:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359746662; bh=YN5AnOI2rqZqtOe+zdJkw4pXuCIZ3HRQMuSF3YbvVWQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=6sMfXTlDoK1MAeeB5LxaHqOfoKKKq0NahQbeZWh2Uj66mYUgN7cfqDByAL1U8mxvaLmYTLHWa2JjZWwn8YOrIkcKmIn+i3SbLpzxV9042Gn9U4IhKYmuUfMxWZKfZaoK28SkKfUmyVEPkctdyTC2cRyJHOC7WJOcHXnHPVPq2sw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=jgrWkMYp8A7jrABTXD5SlXILuhTIS0ZlMfBw2v3PwRus171ST/IstnjUv1Eq/xbQ8BD5Fm8XSWLOpbjFCliZ2TCLUNMiKG2F/hj50FXSnFVivJjchLIwPR94yae/y+pwKRQGhgure1Hm9KeQwwpAZDgjXcJF7SHwW2d+Cme0qJQ=; X-YMail-OSG: FuZ.sAoVM1m3TyL2F1mYAcpuEswcKA0ocv90LH4R8zQFoRY abCVfViQSNoRW.V25QU3A9icF5R5_hT.lXxN6MVtR6MQP4bZF.WxG3E4zP3u 97jb8uftqgmUpRbbUErHjOoBKekqs8gmob4lyPaoVyZ1yXOKHFQDcAdPmaPz cds3d0sL88z61wZIf_4Kwrr9LBQlUvOkPQBw_qc4zy.mQTwSMLzCJXOdG_Ma nvJTDPjutT7M9ix0x2XX3ltHYaa5R9CUFTRvuS4.CLQ3FejcZjdzac6Gcl.F gr2S3luFVhvUQHtDJyQLmDXW0BgVaKrFMyS9LUk6W.cuINvYlUuQIjFvlLWO xb3ndurxGBLN4k7vlp9oqElybjjYxUiutc6M_S_oU81UhtepVtoi.GUe8v9W saPWEuj4Ofh93Rhj7cKxPcsdLQ1nOXhq.62jSJnp41MoWs0IsObAkLckHTe_ 2bqXpKBMvm219DyIlQljiZFAkEDtScvCRphRg5.lwn_VwBlBILGYtm0gF4nF DmafFEkfO8iZtkMl6JwD7TVbQodvVAVtSE6kF3kLWhIQO9qDPIyRGzTSXKca KXmz5eJRRc9k- Received: from [71.22.243.36] by web121601.mail.ne1.yahoo.com via HTTP; Fri, 01 Feb 2013 11:24:22 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzLA0KDQpJdCBpcyB0cnVseSBhIHByaXZpbGVnZWQgdG8gYmUgaW4gdGhlIG1pZHN0IG9mIHNvIG1hbnkgSW50ZWxsaWdlbnQgQ3liZXIgU2VjdXJpdHkgTWluZHMuwqAgRWFjaCB0aW1lIEkgcmVhZCB0aGUgdGhyZWFkcyBvbiBNaWxlLCBJIGZpbmQgbXlzZWxmIHJlZmVyZW5jaW5nIHRlcm1pbm9sb2d5LCBhY3JvbnltcyByZWxhdGVkIHRvIGNvbXB1dGVyIHNjaWVuY2UgYW5kIFJGQ3MuDQoNCkZ1cnRoZXJtb3JlLCBpdCBpcyBteSBkZXNpcmUgdG8gdW5kZXJzdGFuZCBhbmQgc2hhcmUgdGhlIFYBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.131.499 Message-ID: <1359746662.67639.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Fri, 1 Feb 2013 11:24:22 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF , KathleenMoriarty MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1977980688-396984636-1359746662=:67639" Cc: "C. Henry Adams" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:24:26 -0000 ---1977980688-396984636-1359746662=:67639 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, It is truly a privileged to be in the midst of so many Intelligent Cyber Se= curity Minds.=C2=A0 Each time I read the threads on Mile, I find myself ref= erencing terminology, acronyms related to computer science and RFCs. Furthermore, it is my desire to understand and share the Vision of the Auth= or(s) which I'm assuming consist of Kathleen, as well as, others.=C2=A0 So,= please forgive me if you completely blow over my head with your logic, for= e, I'm not that far behind you in thought.=C2=A0=20 Kathleen, I understood your following statement: "Our objective here is to = have machine automated =0Aexchanges, so we rely on encryption rather than o= bfuscation to achieve =0Athe necessary level of confidentiality." Forgive me, but is not Encryption and Obfuscation one in the same depending= on how you look at it. Furthermore,=C2=A0 if I was to tell you that a "Simple Minded Computer Tech= nician" like myself could figure out analytically how to attack your indica= tors to set up a simple plan to disable your automated machine's communicat= ions, would you not believe me?=C2=A0 Oh, one more thing, the fact of the m= atter that the capabilities would be there- would be based on say the proto= col you put into place by complexity rather than simplicity. Paul has great points.=C2=A0 Chris and Dave are on point as well.=C2=A0=C2= =A0 I'm clearly not a technical writer, but I'm a visionary that enjoys put= ting things into action.=C2=A0 No offense or disrespect, just being counter= intuitive when comes to a train wreck. =0A =0A =0A From: =0A "Harringt= on, Christopher" =0A =09=0A = =09=0A =09=0A =09To: =0A =09"Moriarty, Kath= leen" , "MILE IETF" =0A = =09=0A Message contains attachments=0A =0A = 1 File (7KB)=0A =0A =0A smi= me.p7sI=0A think we have a bigger relationship issue to address. Let use th= e =0AWatchlist Use Case. A bunch of indicators are sent in one message. In = =0Athat message we could have groupings of indicators that we need to show = =0Aare related: =C2=A0Two or more indicators of different type that relate = to the same threat:The=0A file hash of a malicious file and the URL of the = C2 that the file uses.=0A Either or both may be present to indicate a compr= omise. =C2=A0Two or more indicators of the same type that relate to the sa= me threat: 2=0A different registry values for the same registry key. If eit= her value is=0A present it is a compromise indicator but both will not be p= resent. =C2=A0The=0A problem compounds itself very quickly. Consider the s= cenario where both=0A groupings above are part of the same threat. I need t= o show that =0Alogical groupings of Indicators are related as well. We can= =E2=80=99t send =0Amultiple IODEF messages for this from what I remember re= ading. =C2=A0The=0A last one I can think of would be when you have 2 diffe= rent indicators =0Athat represent the same indicator. It=E2=80=99s not unco= mmon to send both the =0AMD5 and SHA1 hash of a malicious file. The indicat= or is the file but the=0A IOCs are the 2 hash values. How do we show they a= re related? If we use a=0A unique Inidcator ID for each hash value there ne= eds to be a higher =0Alevel grouping. =C2=A0Thoughts? =C2=A0Thanks, =C2=A0= --Chris =C2=A0Christopher HarringtonConsulting Security EngineerGSO - Criti= cal Incident Response CenterEMC - Where Information Lives174 Middlesex Turn= pikeBedford, MA 01730781-515-5862 (work)603-583-1585 (cell) =C2=A0From: mil= e-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Ka= thleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =C2=A0All =E2=80=93 =C2=A0I=E2=80=99d=0A like you= r input and will refocus the thread to get opinions from the =0Alist on opt= ions to help solve the problems raised in my message and =0Aadditionally in= Paul=E2=80=99s message. =C2=A0Interesting=0A point, C. Henry.=C2=A0 Our ob= jective here is to have machine automated =0Aexchanges, so we rely on encry= ption rather than obfuscation to achieve =0Athe necessary level of confiden= tiality. =C2=A0Paul=0A mentioned the need to distinguish indicators of comp= romise from context=0A information that may also include IP address or othe= r data that could =0Abe indicators.=C2=A0 The question I raised was on how = to connect sets of =0Aindicators in the same IODEF document, assuming the a= bility to have =0Awatchlists that could have several sets of indicators inc= luded, as well =0Aas to connect indicators that may be included in embedded= schemas. =C2=A0If=0A we add an attribute on all of the relevant indicators= , let=E2=80=99s say =0A=E2=80=98indicator-uid=E2=80=99 how do we mark the i= ndicators?=C2=A0 Do we use this to mark =0Awho sent the indicator as well s= o that we can prevent forward sharing =0Awhen it is not permitted or handle= that separately?=C2=A0 =C2=A0Then=0A for indicators not included in the b= ase schema that may not fit into a =0Acategory in the SCI draft, do we crea= te a place for these off of SCI or =0Aright off of the IODE schema in Event= Data? (more details on this in my =0Afirst message). =C2=A0Comments and que= stions encouraged to figure out the right technical solution to have this m= achine automatable. =C2=A0Thank you,Kathleen =C2=A0From: mile-bounces@ietf.= org [mailto:mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =C2=A0Temporal=0A Dependency sounds interesting.= =C2=A0 I remember when I first ran across this=0A particular craft, an expe= rienced colleague asked me a peculiar =0Aquestion.=C2=A0 He said, " How do = you stop someone from tracking the IP =0AAddress to your computer?"=C2=A0= =20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off=C2=A0 and the modem that it is co= nnected- which is constantly on!"=C2=A0=C2=A0 LOL Here's=0A my point (Hypothetical Situation) :=C2=A0 There is a 1st Responde= r searching=0A a Neighborhood for Survivors which were hit by a Disaster or= let's just=0A say "Live" Terrorist Situation.=C2=A0 He /or She needs to co= mmunication back=0A to other Officials that he /or somehow is in Danger.=C2= =A0 The device used =0Ato communicate has been captured by the great minds = of the enemy.=C2=A0 It's =0Aonly a matter of time before they utilize rever= se engineering to figure =0Aout how it functions.=C2=A0 However, their prid= e comes before a fall when =0Aseeking the location of other similar devices= to attack.=C2=A0 Why? Perhaps =0Athe less thought of concepts that makes t= he device function properly, =0Asaves the day by disguise or cutting it off= (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The=0A information contained herein is for the exclusive use of the origina= l =0Arecipient. This information is granted for limited distribution within= =0Athe recipient's place of business for planning purposes only. Further = =0Adissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PMUID could be mirrored with DNS SEC a= pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle=C2=A0 dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrot= e: >=0A Serialization of a particular Lists of XML Classes in a unique way was= =0Aclosely related to what I attempted to express when I stated, "consider= =0Ato a degree what appears to be illogical in brilliant minds in some =0A= instances." >=20 > However, I see Dr. Stoecker's point a =0Alittle clearer.=C2=A0 However, i= t would be nice if the UID was in some way =0Adisguised from those who stud= y this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 >=0A The information contained herein is for the exclusive use of the =0Aor= iginal recipient. This information is granted for limited distribution=0A w= ithin the recipient's place of business for planning purposes only. =0AFurt= her dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different perspective=C5=A0l= et's > say I get an XML document that tells me about an incident.=C2=A0 This doc= ument > has source IP and destination IP that is being shared.=C2=A0 However, wha= t I > don't know is which IP address is my indicator and which is just a > contextual piece of information.=C2=A0 This means that my detection produ= ct > isn't going to know which one to use either, because there is nothing to > tell me which IP is the one, even if the roles are set it still might not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow us > to easily identify indicators from contextual data.=C2=A0 I do admit to b= eing > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make it > very clear what the indicators are in the XML document and the other data > that may be important as I investigate activity that I have detected off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more flexibilit= y > with the indicator_uid.=C2=A0 One thing that I haven't considered is the = UID > portion of this=C5=A0how do we use that UID?=C2=A0 How is the UID created= ?=C2=A0 Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 >=0A Your logic stimulates my visionary brain because I'm amazed at the man= y=0A avenues you review with this approach at once.=C2=A0 However,=C2=A0 co= uld you =0Ashare a few advantages and disadvantages to the latter? >=20 > -------------------------------------------------------------------------= ------------------------------------------------- >=0A "we could continue to group items in logical places as is done now in = =0AIODEF and then have the extension point for combined indicators via =0AS= CI." >=20 > -------------------------------------------------------------------------= ------------------------------------------------ >=20 >=0A You pointed out what you consider to be logical places, but if I wante= d=0A to protect information from parties capable of ascertaining it from = =0Ayour logical places, perhaps we should also consider to a degree what = =0Aappears to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=0A The information contained herein is for the exclusive use of the =0Aor= iginal recipient. This information is granted for limited distribution=0A w= ithin the recipient's place of business for planning purposes only. =0AFurt= her dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen wrote= : >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 >=0A Thanks for taking a look at this.=C2=A0 We have a few considerations i= n this=0A email thread I would like to hear thoughts on (and there may be m= ore =0Aonce RFC5070-bis is actively edited). >=20 > The =0AAdditionalData class and the RecordItem class both allow for non-X= ML =0Aextensions.=C2=A0 Where you place the extensions should be specific t= o the =0Alogical grouping of the parent elements so you can understand more= about=0A the included data in most cases.=C2=A0=20 >=20 > The Impact class =0Acan be used to provide context information on the inc= luded data of the =0Areport and also can include a confidence rating on the= report as a =0Awhole.=C2=A0 Extensions related to impact would be one leve= l higher (at the =0Amoment) in the Assessment class using the AdditionalDat= a extension =0Apoint.=C2=A0=20 >=20 > Take asked about including vulnerability =0Ainformation, I would think th= at would fit under the Vulnerability =0Aextension point of the SCI draft in= the Method class.=C2=A0 He did ask about =0Anon-XML.=C2=A0 RecordItem or A= dditionalData do allow for non-XML extension =0Apoints, we could either hav= e the SCI draft handle these as well or have =0Athe extensions that are non= -XML come directly off the AdditionalData or =0ARecordItem classes accordin= g to what makes sense from a logical =0Astandpoint. >=20 > As for my question, it was two-fold. >=20 >=0A Indicator based schemas have a reference number or a GUID for the =0Av= arious indicators they share.=C2=A0 If we are extending to embed other =0As= chemas that include such reference or GUID identifiers, do we want to =0Aad= d an attribute to the various elements in IODEF that could be =0Aindicators= ?=C2=A0 Is this enough to make the connections or is something else=0A else= needed?=C2=A0 We could add something like an Indicator_ID in =0ARFC5070-bi= s which would then correlate to the reference or GUID =0Aidentifiers. >=20 > Then the other question was on how to =0Ainclude indicators that are not = in the base schema that may be related =0Aor have language with "and" "or" = to specify the relationships.=C2=A0 In some =0Acases, you will want to grou= p these indictors in one extension point, =0Awhere they may fit logically i= n multiple places if the relationships did=0A not need to be shown in the d= ata format.=C2=A0 If we have cases like this =0Awhere you need more complex= representations, should we use one extension=0A point via the SCI draft of= f of the EventData class AdditionalData =0Aextension point?=C2=A0 Opinions = are needed here....=20 >=20 > A few =0Apeople have mentioned wanting to include some commonly shared in= dictors =0Ainto the base IODEF document.=C2=A0 We could have a catch-all cl= ass that does=0A this and has an extension point off of it in EventData or = we could =0Acontinue to group items in logical places as is done now in IOD= EF and =0Athen have the extension point for combined indicators via SCI.=C2= =A0 I think I=0A like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry= Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it could= be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey the > indicators. > We could for instance extend the list of indicators of the Impact class, = if > needed. > -------------------------------------------------------------------------= ----------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > -------------------------------------------------------------------------= ---------------------------- >=0A For the discussion below, I was thinking more of combined set with =0A= relationships that may be included in a single extension point, so =0Athat'= s why I was thinking about the EventData class, but there may be =0Abetter = locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --------------------------- >=20 > Kathleen thoughts related yet still with other indicators and the EventDa= ta Class. >=20 >=0A Is there a possible way to create a new XML class which encompass =0Ac= ombining the EventData, Detection and base IODEF classes to simplify =0Athi= s issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 >=0A The information contained herein is for the exclusive use of the =0Aor= iginal recipient. This information is granted for limited distribution=0A w= ithin the recipient's place of business for planning purposes only. =0AFurt= her dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. ---1977980688-396984636-1359746662=:67639 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Greetings,

It is truly a privileged to be in the midst of= so many Intelligent Cyber Security Minds.  Each time I read the threa= ds on Mile, I find myself referencing terminology, acronyms related to comp= uter science and RFCs.

Furthermore, it is my desire to understand an= d share the Vision of the Author(s) which I'm assuming consist of Kathleen,= as well as, others.  So, please forgive me if you completely blow ove= r my head with your logic, fore, I'm not that far behind you in thought.&nb= sp;

Kathleen, I understood your following statement: "Our objective here is to have machine automated =0Aexchan= ges, so we rely on encryption rather than obfuscation to achieve =0Athe nec= essary level of confidentiality."

Forgive me, but is not Encr= yption and Obfuscation one in the same depending on how you look at it.
=
Furthermore,  if I was to tell you that a "Simple Minded Computer = Technician" like myself could figure out analytically how to attack your in= dicators to set up a simple plan to disable your automated machine's commun= ications, would you not believe me?  Oh, one more thing, the fact of t= he matter that the capabilities would be there- would be based on say the p= rotocol you put into place by complexity rather than simplicity.

Pau= l has great points.  Chris and Dave are on point as well.   = I'm clearly not a technical writer, but I'm a visionary that enjoys putting= things into action.  No offense or disrespect, just being counter int= uitive when comes to a train wreck.




=0A =
=0A
=0A =
From:
=0A
"Harrington, Christopher" <Chri= stopher.Harrington@emc.com>
=0A =09
=0A = =09=0A =09
=0A =09
To:
=0A =09
"Moriarty, Kath= leen" <kathleen.moriarty@emc.com>, "MILE IETF" <mile@ietf.org><= /div>
=0A =09
=0A =
Message contains attachments=0A
=0A
1 File = (7KB)
=0A =0A
=0A

I=0A think we have a bigger relationship issue to addr= ess. Let use the =0AWatchlist Use Case. A bunch of indicators are sent in o= ne message. In =0Athat message we could have groupings of indicators that w= e need to show =0Aare related:

 

Two or more indicators of different ty= pe that relate to the same threat:

The=0A file h= ash of a malicious file and the URL of the C2 that the file uses.=0A Either= or both may be present to indicate a compromise.

 

Two or more indica= tors of the same type that relate to the same threat:

2=0A different registry values for the same registry key. If eithe= r value is=0A present it is a compromise indicator but both will not be pre= sent.

 

The=0A problem compounds itself very quickly. Consider the sce= nario where both=0A groupings above are part of the same threat. I need to = show that =0Alogical groupings of Indicators are related as well. We can=E2= =80=99t send =0Amultiple IODEF messages for this from what I remember readi= ng.

 

The=0A last one I can think of would be when you have 2 differen= t indicators =0Athat represent the same indicator. It=E2=80=99s not uncommo= n to send both the =0AMD5 and SHA1 hash of a malicious file. The indicator = is the file but the=0A IOCs are the 2 hash values. How do we show they are = related? If we use a=0A unique Inidcator ID for each hash value there needs= to be a higher =0Alevel grouping.

 

Thoughts?

 

= Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security En= gineer

GSO - Critical Incident Response Center

EMC - Where Information Lives<= /span>

1= 74 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

=

&nbs= p;

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of Moriarty, Kathleen
Sent: Friday, Februar= y 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] I= OCs

 

All =E2=80=93 =

=  

I=E2=80=99d=0A like your input and will refocus the thread to get op= inions from the =0Alist on options to help solve the problems raised in my = message and =0Aadditionally in Paul=E2=80=99s message.

 

<= p class=3D"yiv324648158MsoNormal">Interesting= =0A point, C. Henry.  Our objective here is to have machine automated = =0Aexchanges, so we rely on encryption rather than obfuscation to achieve = =0Athe necessary level of confidentiality.

 

Paul=0A mentioned the need= to distinguish indicators of compromise from context=0A information that m= ay also include IP address or other data that could =0Abe indicators. = The question I raised was on how to connect sets of =0Aindicators in the s= ame IODEF document, assuming the ability to have =0Awatchlists that could h= ave several sets of indicators included, as well =0Aas to connect indicator= s that may be included in embedded schemas.

 

If=0A we add an attribute= on all of the relevant indicators, let=E2=80=99s say =0A=E2=80=98indicator= -uid=E2=80=99 how do we mark the indicators?  Do we use this to mark = =0Awho sent the indicator as well so that we can prevent forward sharing = =0Awhen it is not permitted or handle that separately? 

 =

Then=0A= for indicators not included in the base schema that may not fit into a =0A= category in the SCI draft, do we create a place for these off of SCI or =0A= right off of the IODE schema in EventData? (more details on this in my =0Af= irst message).

 

Comments and questions encouraged to figure out the ri= ght technical solution to have this machine automatable.

 

<= p class=3D"yiv324648158MsoNormal">Thank you,

Ka= thleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of C. Henry Adams & BIE
Sent: Monday, January 28, 2013 11= :25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

 

Temporal=0A Dependency sounds interesting.  I remember wh= en I first ran across this=0A particular craft, an experienced colleague as= ked me a peculiar =0Aquestion.  He said, " How do you stop someone fro= m tracking the IP =0AAddress to your computer?" 

I replied, "I= don't know, how?"

Then he said, "Cut the dog-gone thing off  = and the modem that it is connected- which is constantly on!"   LO= L

Here's=0A my point (Hypothetical Situation) :  There is a 1st= Responder searching=0A a Neighborhood for Survivors which were hit by a Di= saster or let's just=0A say "Live" Terrorist Situation.  He /or She ne= eds to communication back=0A to other Officials that he /or somehow is in D= anger.  The device used =0Ato communicate has been captured by the gre= at minds of the enemy.  It's =0Aonly a matter of time before they util= ize reverse engineering to figure =0Aout how it functions.  However, t= heir pride comes before a fall when =0Aseeking the location of other simila= r devices to attack.  Why? Perhaps =0Athe less thought of concepts tha= t makes the device function properly, =0Asaves the day by disguise or cutti= ng it off (figuratively speaking).

Just a visionary thought.

= C. Henry Adams
chenryad= ams@biemediagroup.com
http://biemediagroup.com


The=0A in= formation contained herein is for the exclusive use of the original =0Areci= pient. This information is granted for limited distribution within =0Athe r= ecipient's place of business for planning purposes only. Further =0Adissemi= nation, whether private or public is prohibited.

--- On Mon, 1/28= /13, Dave Misell <david.misel= l@bcs.org> wrote:


From: Dave Misell <david.misell@bcs.org>
Subject: Re: [mile] IOCs=
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Date: Monday, January 28, 2013, 9:25 = PM

UID could be mirrored with DNS SEC a pemanent and temporal key, with a t= emporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
Silent= Circle  dsm
07710 380044
david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote:

>=0A Serialization of a= particular Lists of XML Classes in a unique way was =0Aclosely related to = what I attempted to express when I stated, "consider =0Ato a degree what ap= pears to be illogical in brilliant minds in some =0Ainstances."
> > However, I see Dr. Stoecker's point a =0Alittle clearer.  Howeve= r, it would be nice if the UID was in some way =0Adisguised from those who = study this Security Art Form in a negative way.
>
> C. Henry A= dams
> chatlga2000@yahoo.com (Direct Email)> chenryadams@biemediagroup.com
>
&g= t;
>=0A The information contained herein is for the exclusive use of= the =0Aoriginal recipient. This information is granted for limited distrib= ution=0A within the recipient's place of business for planning purposes onl= y. =0AFurther dissemination, whether private or public is prohibited.
&g= t;
> Re: [mile] IOCs
>
> Sunday, January 27, 2013 8:52 = PM
> From:
> "Stoecker, Paul" <Paul.Stoe= cker@rsa.com>
> To:
> "mile@ietf.org= " <mile@ietf.org>
> I would like to= look at this from a slightly different perspective=C5=A0let's
> say = I get an XML document that tells me about an incident.  This document<= br>> has source IP and destination IP that is being shared.  Howeve= r, what I
> don't know is which IP address is my indicator and which = is just a
> contextual piece of information.  This means that my= detection product
> isn't going to know which one to use either, bec= ause there is nothing to
> tell me which IP is the one, even if the r= oles are set it still might not
> be enough to tell my system which o= ne I should use as the indicator.
>
> If we had something like ind= icator_id as an attribute, it would allow us
> to easily identify ind= icators from contextual data.  I do admit to being
> biased as I= have spent much of my career working on the monitoring and
> detecti= on side of these things, so I am just thinking of ways to make it
> v= ery clear what the indicators are in the XML document and the other data> that may be important as I investigate activity that I have detected = off
> of those indicators.
>
>
> I did suggest th= e detection class, but I think we may get more flexibility
> with the= indicator_uid.  One thing that I haven't considered is the UID
>= ; portion of this=C5=A0how do we use that UID?  How is the UID created= ?  Are
> there standards for UIDs?
>
> Regards,
= >
> Paul
>
>
>
> Paul W. Stoecker, Ph.D.
> SMC Lead Content Architect
> RSA, The Security Divisio= n of EMC
> cell: 302.379.3375 | e: paul.stoecker@= rsa.com
>
> --- On Sat, 1/26/13, C. Henry Adams & BIE = <chatlga2000@yahoo.com> wrote:
>
&g= t; From: C. Henry Adams & BIE <chatlga2000@yahoo= .com>
> Subject: RE: [mile] IOCs
> To: "KathleenMoriarty= " <kathleen.moriarty@emc.com>
> Cc: mile@ietf.org
> Date: Saturday, January 26, 2013= , 6:17 PM
>
> Greetings Kathleen,
>
>=0A Your log= ic stimulates my visionary brain because I'm amazed at the many=0A avenues = you review with this approach at once.  However,  could you =0Ash= are a few advantages and disadvantages to the latter?
>
> ----= ---------------------------------------------------------------------------= -------------------------------------------
>=0A "we could continue t= o group items in logical places as is done now in =0AIODEF and then have th= e extension point for combined indicators via =0ASCI."
>
> ---= ---------------------------------------------------------------------------= -------------------------------------------
>
>=0A You pointed= out what you consider to be logical places, but if I wanted=0A to protect = information from parties capable of ascertaining it from =0Ayour logical pl= aces, perhaps we should also consider to a degree what =0Aappears to be ill= ogical in brilliant minds in some instances.
>
>
>
= > C. Henry Adams
> chatlga2000@yahoo.com (= Direct Email)
> chenryadams@biemediagroup.com=
>
>=0A The information contained herein is for the exclusive = use of the =0Aoriginal recipient. This information is granted for limited d= istribution=0A within the recipient's place of business for planning purpos= es only. =0AFurther dissemination, whether private or public is prohibited.=
>
> --- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:
>
> From: Mori= arty, Kathleen <kathleen.moriarty@emc.com>> Subject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE" <<= a rel=3D"nofollow">chatlga2000@yahoo.com>, "mile= @ietf.org" <mile@ietf.org>
> Date: = Saturday, January 26, 2013, 10:13 AM
>
> Hello C. Henry & = others,
>
>=0A Thanks for taking a look at this.  We have= a few considerations in this=0A email thread I would like to hear thoughts= on (and there may be more =0Aonce RFC5070-bis is actively edited).
>=
> The =0AAdditionalData class and the RecordItem class both allow f= or non-XML =0Aextensions.  Where you place the extensions should be sp= ecific to the =0Alogical grouping of the parent elements so you can underst= and more about=0A the included data in most cases. 
>
> = The Impact class =0Acan be used to provide context information on the inclu= ded data of the =0Areport and also can include a confidence rating on the r= eport as a =0Awhole.  Extensions related to impact would be one level = higher (at the =0Amoment) in the Assessment class using the AdditionalData = extension =0Apoint. 
>
> Take asked about including vuln= erability =0Ainformation, I would think that would fit under the Vulnerabil= ity =0Aextension point of the SCI draft in the Method class.  He did a= sk about =0Anon-XML.  RecordItem or AdditionalData do allow for non-XM= L extension =0Apoints, we could either have the SCI draft handle these as w= ell or have =0Athe extensions that are non-XML come directly off the Additi= onalData or =0ARecordItem classes according to what makes sense from a logi= cal =0Astandpoint.
>
> As for my question, it was two-fold.>
>=0A Indicator based schemas have a reference number or a GUID= for the =0Avarious indicators they share.  If we are extending to emb= ed other =0Aschemas that include such reference or GUID identifiers, do we = want to =0Aadd an attribute to the various elements in IODEF that could be = =0Aindicators?  Is this enough to make the connections or is something= else=0A else needed?  We could add something like an Indicator_ID in = =0ARFC5070-bis which would then correlate to the reference or GUID =0Aident= ifiers.
>
> Then the other question was on how to =0Ainclude i= ndicators that are not in the base schema that may be related =0Aor have la= nguage with "and" "or" to specify the relationships.  In some =0Acases= , you will want to group these indictors in one extension point, =0Awhere t= hey may fit logically in multiple places if the relationships did=0A not ne= ed to be shown in the data format.  If we have cases like this =0Awher= e you need more complex representations, should we use one extension=0A poi= nt via the SCI draft off of the EventData class AdditionalData =0Aextension= point?  Opinions are needed here....
>
> A few =0Apeopl= e have mentioned wanting to include some commonly shared indictors =0Ainto = the base IODEF document.  We could have a catch-all class that does=0A= this and has an extension point off of it in EventData or we could =0Acont= inue to group items in logical places as is done now in IODEF and =0Athen h= ave the extension point for combined indicators via SCI.  I think I=0A= like the latter approach.
>
> Thank you,
> Kathleen
= > ________________________________________
> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE [chatlga2000@= yahoo.com]
> Sent: Saturday, January 26, 2013 3:05 AM
> To:= mile@ietf.org
> Cc: C. Henry Adams
> S= ubject: Re: [mile] IOCs
>
> Greetings Everyone,
>
&g= t; Take mentioned two types of indicators based on the :
> ----------= ---------------------------------------------------------------------------= -----------------
> 1) If the indicators are something like an XML-ba= sed alert/warning of
> information leakage, it could be an event that= are conveyed in the SCI's
> EventReport class, IMHO.
>
>= ; 2) If the indicators are something like an non-XML ones, I guess it could be
> conveyed without using SCI draft.
> For instance, we coul= d use Impact class of the base IODEF to convey the
> indicators.
&= gt; We could for instance extend the list of indicators of the Impact class= , if
> needed.
> ----------------------------------------------= --------------------------------------------------------
>
> I= n doing so he pointed out the "Impact Class"
>
> Whereas, Kath= leen stated,
>
> ---------------------------------------------= --------------------------------------------------------
>=0A For the= discussion below, I was thinking more of combined set with =0Arelationship= s that may be included in a single extension point, so =0Athat's why I was = thinking about the EventData class, but there may be =0Abetter locations or= a specific area within the EventData.
>
> Paul Stoecker had s= uggested a "Detection" class as a consideration.
> ------------------= ---------------------------------------------------------------------------= -------
>
> Kathleen thoughts related yet still with other ind= icators and the EventData Class.
>
>=0A Is there a possible wa= y to create a new XML class which encompass =0Acombining the EventData, Det= ection and base IODEF classes to simplify =0Athis issue?
>
> <= br>> C. Henry Adams
> chatlga2000@yahoo.com (Direct Email)
> chenryadams@biemediagroup.com<= /a>
>
>
>=0A The information contained herein is for th= e exclusive use of the =0Aoriginal recipient. This information is granted f= or limited distribution=0A within the recipient's place of business for pla= nning purposes only. =0AFurther dissemination, whether private or public is= prohibited.
> _______________________________________________
>= ; mile mailing list
> mile@ietf.org
> <= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/mile">https://www.ietf.org/mailman/listinfo/mile


<= br>C. Henry Adams
=0Achatlga2000@yahoo.com (Direct Email)
=0Achenryad= ams@biemediagroup.com
=0A
=0A
=0AThe information contained herein = is for the exclusive use of the original recipient. This information is gra= nted for limited distribution within the recipient's place of business for = planning purposes only. Further dissemination, whether private or public is= prohibited.
---1977980688-396984636-1359746662=:67639-- From kathleen.moriarty@emc.com Sun Feb 3 14:11:57 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCD021F88CF for ; Sun, 3 Feb 2013 14:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[AWL=-2.141, BAYES_05=-1.11, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHDn-s0iPuxU for ; Sun, 3 Feb 2013 14:11:55 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB621F853C for ; Sun, 3 Feb 2013 14:11:54 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r13MBrAG020307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Feb 2013 17:11:53 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sun, 3 Feb 2013 17:11:39 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r13MBdUx006930 for ; Sun, 3 Feb 2013 17:11:39 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Sun, 3 Feb 2013 17:11:38 -0500 From: "Moriarty, Kathleen" To: "Harrington, Christopher" , MILE IETF Date: Sun, 3 Feb 2013 17:11:36 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac392LfqtE12Sv21RDmeR7wzUTqasgCvxeJgAADUQZAAb0Tw0A== Message-ID: References: <71238F9C-AD03-44B9-A065-541351FB4087@bcs.org> <1359433497.20429.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0024_01CE0231.85F0B1C0" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 22:11:57 -0000 ------=_NextPart_000_0024_01CE0231.85F0B1C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0025_01CE0231.85F0B1C0" ------=_NextPart_001_0025_01CE0231.85F0B1C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =20 The list has already said they would like to see indicators added to the = definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to = =E2=80=98parts of an incident or the useful information on an incident = for sharing purposes. It was written before we used terms like = indicators. With that in mind, Rosella proposed a number of changes = back in July, both for guidance and for format updates. It may help to = have the first draft try to address at least some of these issues so = people can understand the problems and at least a proposed solution. =20 As you point out, we need to be able to show relationships between sets = of indicators, where we may have a few sets of indicators that could = have a relationship to each other within a document. In the July = presentation, one of the questions was to see if we should add new = category attribute values for the System class that would connect the = list of included indicators. I think we should still keep the concept = of a Node to a single node, but perhaps within System, list multiple = sets of Nodes that may be one type of attack. Rosella had suggested = pulling forward the =E2=80=9CFraudType=E2=80=9D from RFC5901, this would = help solve the issue as NodeRole values would compliment an AttackType = (FraudType values could be included in AttackType or some broader term). = It may be better to have the FraudTypes, plus attribute values like = =E2=80=9CC2-server=E2=80=9D, =E2=80=9Csinkhole=E2=80=9D, = =E2=80=9CMalwareDistribution=E2=80=9D for added context so you know what = to do with the received set of indicators. =20 I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method = to connect indicators and indicator sets within an IODEF using an = attribute of indicator_uid (or some other name) with a string value to = make the connection points, and add a few indicators that are commonly = shared into the base IODEF. =20 Back in July, we talked about adding Registry Key/Value pairs and hashes = to the main IODEF document (trying to see if this will help Chris = below). What if we added the Registry Key/Value pairs as a class off of = RecordData, using a similar structure to what is in RFC5901, and also = added the ability to include hashes in RecordData? I think if we then = had the indicator_uid at the RecordData level, we could connect a set = within that structure and repeat the structure for other sets in the = same way we would do with Node inside of the System class, using the = indicator_uid to tie the set together. Then at the more specific level = for the hash, registry Key/value, IP, etc. use an indicator_uid if we = needed them marked at this level as well? Maybe we want indicator_set = at the higher level? I=E2=80=99d like some opinions on this approach. = +1 if you agree, suggestions if you have other ideas that may work = better. =20 We=E2=80=99ll also need to worry about marking the indicators to prevent = forward sharing when not permitted. We may want to use these values or = something else. =20 =20 Thank you! Kathleen =20 =20 From: Harrington, Christopher=20 Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =20 I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related: =20 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise.=20 =20 Two or more indicators of the same type that relate to the same threat:=20 2 different registry values for the same registry key. If either value = is present it is a compromise indicator but both will not be present.=20 =20 The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that = logical groupings of Indicators are related as well. We can=E2=80=99t = send multiple IODEF messages for this from what I remember reading.=20 =20 The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=E2=80=99s not uncommon = to send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping.=20 =20 Thoughts? =20 Thanks, =20 --Chris =20 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =20 All =E2=80=93=20 =20 I=E2=80=99d like your input and will refocus the thread to get opinions = from the list on options to help solve the problems raised in my message = and additionally in Paul=E2=80=99s message. =20 Interesting point, C. Henry. Our objective here is to have machine = automated exchanges, so we rely on encryption rather than obfuscation to = achieve the necessary level of confidentiality. =20 Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators. The question I raised was on how to connect sets = of indicators in the same IODEF document, assuming the ability to have = watchlists that could have several sets of indicators included, as well = as to connect indicators that may be included in embedded schemas. =20 If we add an attribute on all of the relevant indicators, let=E2=80=99s = say =E2=80=98indicator-uid=E2=80=99 how do we mark the indicators? Do = we use this to mark who sent the indicator as well so that we can = prevent forward sharing when it is not permitted or handle that = separately? =20 =20 Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message). =20 Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =20 Temporal Dependency sounds interesting. I remember when I first ran = across this particular craft, an experienced colleague asked me a = peculiar question. He said, " How do you stop someone from tracking the = IP Address to your computer?" =20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off and the modem that it is = connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder = searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation. He /or She needs to = communication back to other Officials that he /or somehow is in Danger. = The device used to communicate has been captured by the great minds of = the enemy. It's only a matter of time before they utilize reverse = engineering to figure out how it functions. However, their pride comes = before a fall when seeking the location of other similar devices to = attack. Why? Perhaps the less thought of concepts that makes the device = function properly, saves the day by disguise or cutting it off = (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a = temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE = wrote: > Serialization of a particular Lists of XML Classes in a unique way was = closely related to what I attempted to express when I stated, "consider = to a degree what appears to be illogical in brilliant minds in some = instances." >=20 > However, I see Dr. Stoecker's point a little clearer. However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different = perspective=C5=A0let's > say I get an XML document that tells me about an incident. This = document > has source IP and destination IP that is being shared. However, what = I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing = to > tell me which IP is the one, even if the roles are set it still might = not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow = us > to easily identify indicators from contextual data. I do admit to = being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make = it > very clear what the indicators are in the XML document and the other = data > that may be important as I investigate activity that I have detected = off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more = flexibility > with the indicator_uid. One thing that I haven't considered is the = UID > portion of this=C5=A0how do we use that UID? How is the UID created? = Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once. However, could you = share a few advantages and disadvantages to the latter? >=20 > = -------------------------------------------------------------------------= ------------------------------------------------- > "we could continue to group items in logical places as is done now in = IODEF and then have the extension point for combined indicators via = SCI." >=20 > = -------------------------------------------------------------------------= ------------------------------------------------ >=20 > You pointed out what you consider to be logical places, but if I = wanted to protect information from parties capable of ascertaining it = from your logical places, perhaps we should also consider to a degree = what appears to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" = > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this. We have a few considerations in = this email thread I would like to hear thoughts on (and there may be = more once RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for = non-XML extensions. Where you place the extensions should be specific = to the logical grouping of the parent elements so you can understand = more about the included data in most cases. =20 >=20 > The Impact class can be used to provide context information on the = included data of the report and also can include a confidence rating on = the report as a whole. Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point. =20 >=20 > Take asked about including vulnerability information, I would think = that would fit under the Vulnerability extension point of the SCI draft = in the Method class. He did ask about non-XML. RecordItem or = AdditionalData do allow for non-XML extension points, we could either = have the SCI draft handle these as well or have the extensions that are = non-XML come directly off the AdditionalData or RecordItem classes = according to what makes sense from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the = various indicators they share. If we are extending to embed other = schemas that include such reference or GUID identifiers, do we want to = add an attribute to the various elements in IODEF that could be = indicators? Is this enough to make the connections or is something else = else needed? We could add something like an Indicator_ID in RFC5070-bis = which would then correlate to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not = in the base schema that may be related or have language with "and" "or" = to specify the relationships. In some cases, you will want to group = these indictors in one extension point, where they may fit logically in = multiple places if the relationships did not need to be shown in the = data format. If we have cases like this where you need more complex = representations, should we use one extension point via the SCI draft off = of the EventData class AdditionalData extension point? Opinions are = needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared = indictors into the base IODEF document. We could have a catch-all class = that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF = and then have the extension point for combined indicators via SCI. I = think I like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > = -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the = SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it = could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey = the > indicators. > We could for instance extend the list of indicators of the Impact = class, if > needed. > = -------------------------------------------------------------------------= ----------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > = -------------------------------------------------------------------------= ---------------------------- > For the discussion below, I was thinking more of combined set with = relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be = better locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > = -------------------------------------------------------------------------= --------------------------- >=20 > Kathleen thoughts related yet still with other indicators and the = EventData Class. >=20 > Is there a possible way to create a new XML class which encompass = combining the EventData, Detection and base IODEF classes to simplify = this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0025_01CE0231.85F0B1C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 

I agree, we have some work to do in the updated IODEF, = RFC5070-bis.

 

The list has already said they would like to see indicators added to = the definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to = =E2=80=98parts of an incident or the useful information on an incident = for sharing purposes.=C2=A0 It was written before we used terms like = indicators.=C2=A0 With that in mind, Rosella proposed a number of = changes back in July, both for guidance and for format updates.=C2=A0 It = may help to have the first draft try to address at least some of these = issues so people can understand the problems and at least a proposed = solution.

 

As you point out, we need to be able to show relationships between = sets of indicators, where we may have a few sets of indicators that = could have a relationship to each other within a document.=C2=A0 In the = July presentation, one of the questions was to see if we should add new = category attribute values for the System class that would connect the = list of included indicators.=C2=A0 I think we should still keep the = concept of a Node to a single node, but perhaps within System, list = multiple sets of Nodes that may be one type of attack.=C2=A0 Rosella had = suggested pulling forward the =E2=80=9CFraudType=E2=80=9D from RFC5901, = this would help solve the issue as NodeRole values would compliment an = AttackType (FraudType values could be included in AttackType or some = broader term).=C2=A0 It may be better to have the FraudTypes, plus = attribute values like =E2=80=9CC2-server=E2=80=9D, = =E2=80=9Csinkhole=E2=80=9D,=C2=A0 =E2=80=9CMalwareDistribution=E2=80=9D = for added context so you know what to do with the received set of = indicators.

 

I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method = to connect indicators and indicator sets within an IODEF using an = attribute of indicator_uid (or some other name) with a string value to = make the connection points, and add a few indicators that are commonly = shared into the base IODEF.

 

Back in July, we talked about adding Registry Key/Value pairs and = hashes to the main IODEF document (trying to see if this will help Chris = below).=C2=A0 What if we added the Registry Key/Value pairs as a class = off of RecordData, using a similar structure to what is in RFC5901, and = also added the ability to include hashes in RecordData?=C2=A0 I think if = we then had the indicator_uid at the RecordData level, we could connect = a set within that structure and repeat the structure for other sets in = the same way we would do with Node inside of the System class, using the = indicator_uid to tie the set together.=C2=A0 Then at the more specific = level for the hash, registry Key/value, IP, etc. use an indicator_uid if = we needed them marked at this level as well?=C2=A0 Maybe we want = indicator_set at the higher level?=C2=A0 I=E2=80=99d like some opinions = on this approach.=C2=A0 +1 if you agree, suggestions if you have other = ideas that may work better.

 

We=E2=80=99ll also need to worry about marking the indicators to = prevent forward sharing when not permitted.=C2=A0 We may want to use = these values or something else.=C2=A0

 

Thank you!
Kathleen=C2=A0

 

From:= = Harrington, Christopher
Sent: Friday, February 01, 2013 12:01 = PM
To: Moriarty, Kathleen; MILE IETF
Subject: RE: = [mile] IOCs

 

I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related:

 

Two or more indicators of different type that relate to the same = threat:

The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise. =

 

Two or more indicators of the same type that relate to the same = threat:

2 different registry values for the same registry key. If either = value is present it is a compromise indicator but both will not be = present.

 

The problem compounds itself very quickly. Consider the scenario = where both groupings above are part of the same threat. I need to show = that logical groupings of Indicators are related as well. We = can=E2=80=99t send multiple IODEF messages for this from what I remember = reading.

 

The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=E2=80=99s not uncommon = to send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping.

 

Thoughts?=

 

Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security Engineer

GSO - Critical Incident Response Center

EMC - Where Information Lives

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of Moriarty, Kathleen
Sent: Friday, February = 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] = IOCs

 

All =E2=80=93

 

I=E2=80=99d like your input and will refocus the thread to get = opinions from the list on options to help solve the problems raised in = my message and additionally in Paul=E2=80=99s = message.

 

Interesting point, C. Henry.  Our objective here is to have = machine automated exchanges, so we rely on encryption rather than = obfuscation to achieve the necessary level of = confidentiality.

 

Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators.  The question I raised was on how to connect = sets of indicators in the same IODEF document, assuming the ability to = have watchlists that could have several sets of indicators included, as = well as to connect indicators that may be included in embedded = schemas.

 

If we add an attribute on all of the relevant indicators, = let=E2=80=99s say =E2=80=98indicator-uid=E2=80=99 how do we mark the = indicators?  Do we use this to mark who sent the indicator as well = so that we can prevent forward sharing when it is not permitted or = handle that separately? 

 

Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message).

 

Comments and questions encouraged to figure out the right technical = solution to have this machine automatable.

 

Thank you,

Kathleen

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of C. Henry Adams & BIE
Sent: = Monday, January 28, 2013 11:25 PM
To: MILE = IETF
Subject: Re: [mile] IOCs

 

Temporal = Dependency sounds interesting.  I remember when I first ran across = this particular craft, an experienced colleague asked me a peculiar = question.  He said, " How do you stop someone from tracking = the IP Address to your computer?" 

I replied, "I = don't know, how?"

Then he said, "Cut the dog-gone = thing off  and the modem that it is connected- which is constantly = on!"   LOL

Here's my point (Hypothetical = Situation) :  There is a 1st Responder searching a Neighborhood for = Survivors which were hit by a Disaster or let's just say = "Live" Terrorist Situation.  He /or She needs to = communication back to other Officials that he /or somehow is in = Danger.  The device used to communicate has been captured by the = great minds of the enemy.  It's only a matter of time before they = utilize reverse engineering to figure out how it functions.  = However, their pride comes before a fall when seeking the location of = other similar devices to attack.  Why? Perhaps the less thought of = concepts that makes the device function properly, saves the day by = disguise or cutting it off (figuratively speaking).

Just a = visionary thought.

C. Henry Adams
chenryadams@biemediagroup.c= om
http://biemediagroup.com

The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is = prohibited.

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org>= wrote:


From: Dave Misell <david.misell@bcs.org>
Subj= ect: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Da= te: Monday, January 28, 2013, 9:25 PM

UID could be mirrored = with DNS SEC a pemanent and temporal key, with a temporal = Id?

Yours Faithfully,

Dave Misell MSc = CISSP
SilentCircle  dsm
07710 380044
david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:

> Serialization of a particular Lists of XML = Classes in a unique way was closely related to what I attempted to = express when I stated, "consider to a degree what appears to be = illogical in brilliant minds in some instances."
>
> = However, I see Dr. Stoecker's point a little clearer.  However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way.
>
> C. Henry = Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
>
> Re: [mile] = IOCs
>
> Sunday, January 27, 2013 8:52 PM
> = From:
> "Stoecker, Paul" <Paul.Stoecker@rsa.com= >
> To:
> "mile@ietf.org" <mile@ietf.org>
> I = would like to look at this from a slightly different = perspective=C5=A0let's
> say I get an XML document that tells me = about an incident.  This document
> has source IP and = destination IP that is being shared.  However, what I
> don't = know is which IP address is my indicator and which is just a
> = contextual piece of information.  This means that my detection = product
> isn't going to know which one to use either, because = there is nothing to
> tell me which IP is the one, even if the = roles are set it still might not
> be enough to tell my system = which one I should use as the indicator.
>
> If we had = something like indicator_id as an attribute, it would allow us
> = to easily identify indicators from contextual data.  I do admit to = being
> biased as I have spent much of my career working on the = monitoring and
> detection side of these things, so I am just = thinking of ways to make it
> very clear what the indicators are = in the XML document and the other data
> that may be important as = I investigate activity that I have detected off
> of those = indicators.
>
>
> I did suggest the detection class, = but I think we may get more flexibility
> with the = indicator_uid.  One thing that I haven't considered is the = UID
> portion of this=C5=A0how do we use that UID?  How is = the UID created?  Are
> there standards for UIDs?
> =
> Regards,
>
> Paul
>
>
> =
> Paul W. Stoecker, Ph.D.
> SMC Lead Content = Architect
> RSA, The Security Division of EMC
> cell: = 302.379.3375 | e: paul.stoecker@rsa.com=
>
> --- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:
>
> From: C. Henry Adams & BIE <chatlga2000@yahoo.com= >
> Subject: RE: [mile] IOCs
> To: = "KathleenMoriarty" <kathleen.moriarty@emc= .com>
> Cc: mile@ietf.org
> Date: = Saturday, January 26, 2013, 6:17 PM
>
> Greetings = Kathleen,
>
> Your logic stimulates my visionary brain = because I'm amazed at the many avenues you review with this approach at = once.  However,  could you share a few advantages and = disadvantages to the latter?
>
> = -------------------------------------------------------------------------= -------------------------------------------------
> "we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via = SCI."
>
> = -------------------------------------------------------------------------= ------------------------------------------------
>
> You = pointed out what you consider to be logical places, but if I wanted to = protect information from parties capable of ascertaining it from your = logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances.
>
> =
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
> The information contained herein is = for the exclusive use of the original recipient. This information is = granted for limited distribution within the recipient's place of = business for planning purposes only. Further dissemination, whether = private or public is prohibited.
>
> --- On Sat, 1/26/13, = Moriarty, Kathleen <kathleen.moriarty@emc= .com> wrote:
>
> From: Moriarty, Kathleen <kathleen.moriarty@emc= .com>
> Subject: RE: [mile] IOCs
> To: "C. Henry = Adams & BIE" <chatlga2000@yahoo.com= >, "mile@ietf.org" <mile@ietf.org>
> = Date: Saturday, January 26, 2013, 10:13 AM
>
> Hello C. = Henry & others,
>
> Thanks for taking a look at = this.  We have a few considerations in this email thread I would = like to hear thoughts on (and there may be more once RFC5070-bis is = actively edited).
>
> The AdditionalData class and the = RecordItem class both allow for non-XML extensions.  Where you = place the extensions should be specific to the logical grouping of the = parent elements so you can understand more about the included data in = most cases. 
>
> The Impact class can be used to = provide context information on the included data of the report and also = can include a confidence rating on the report as a whole.  = Extensions related to impact would be one level higher (at the moment) = in the Assessment class using the AdditionalData extension point.  =
>
> Take asked about including vulnerability information, = I would think that would fit under the Vulnerability extension point of = the SCI draft in the Method class.  He did ask about non-XML.  = RecordItem or AdditionalData do allow for non-XML extension points, we = could either have the SCI draft handle these as well or have the = extensions that are non-XML come directly off the AdditionalData or = RecordItem classes according to what makes sense from a logical = standpoint.
>
> As for my question, it was = two-fold.
>
> Indicator based schemas have a reference = number or a GUID for the various indicators they share.  If we are = extending to embed other schemas that include such reference or GUID = identifiers, do we want to add an attribute to the various elements in = IODEF that could be indicators?  Is this enough to make the = connections or is something else else needed?  We could add = something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers.
>
> Then the other = question was on how to include indicators that are not in the base = schema that may be related or have language with "and" = "or" to specify the relationships.  In some cases, you = will want to group these indictors in one extension point, where they = may fit logically in multiple places if the relationships did not need = to be shown in the data format.  If we have cases like this where = you need more complex representations, should we use one extension point = via the SCI draft off of the EventData class AdditionalData extension = point?  Opinions are needed here....
>
> A few people = have mentioned wanting to include some commonly shared indictors into = the base IODEF document.  We could have a catch-all class that does = this and has an extension point off of it in EventData or we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI.  I = think I like the latter approach.
>
> Thank you,
> = Kathleen
> ________________________________________
> From: = mile-bounces@ietf.org= [mile-bounces@ietf.org= ] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com= ]
> Sent: Saturday, January 26, 2013 3:05 AM
> To: mile@ietf.org
> Cc: C. = Henry Adams
> Subject: Re: [mile] IOCs
>
> Greetings = Everyone,
>
> Take mentioned two types of indicators based = on the :
> = -------------------------------------------------------------------------= -----------------------------
> 1) If the indicators are something = like an XML-based alert/warning of
> information leakage, it could = be an event that are conveyed in the SCI's
> EventReport class, = IMHO.
>
> 2) If the indicators are something like an = non-XML ones, I guess it could be
> conveyed without using SCI = draft.
> For instance, we could use Impact class of the base IODEF = to convey the
> indicators.
> We could for instance extend = the list of indicators of the Impact class, if
> needed.
> = -------------------------------------------------------------------------= -----------------------------
>
> In doing so he pointed = out the "Impact Class"
>
> Whereas, Kathleen = stated,
>
> = -------------------------------------------------------------------------= ----------------------------
> For the discussion below, I was = thinking more of combined set with relationships that may be included in = a single extension point, so that's why I was thinking about the = EventData class, but there may be better locations or a specific area = within the EventData.
>
> Paul Stoecker had suggested a = "Detection" class as a consideration.
> = -------------------------------------------------------------------------= ---------------------------
>
> Kathleen thoughts related = yet still with other indicators and the EventData Class.
> =
> Is there a possible way to create a new XML class which = encompass combining the EventData, Detection and base IODEF classes to = simplify this issue?
>
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
> = _______________________________________________
> mile mailing = list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile

 =

------=_NextPart_001_0025_01CE0231.85F0B1C0-- ------=_NextPart_000_0024_01CE0231.85F0B1C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYoDCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFqDCCBJCgAwIBAgIQYNecC3elyT7NQnxWXD4qHDANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEy MDQwMzE3MTA0NVoXDTE0MDQwMzE3MTA0NVowgdkxEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxETAPBgNVBAsTCENvbnN1bWVyMQ8wDQYDVQQFEwYwODQxNTMxFjAUBgoJkiaJk/IsZAEBEwZt b3JpYWsxGjAYBgNVBAMTEUthdGhsZWVuIE1vcmlhcnR5MSgwJgYJKoZIhvcNAQkBFhlrYXRobGVl bi5tb3JpYXJ0eUBlbWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv+TnbpOG gqBZF5MBRDiDNLy/TMUs61qdYCiNbyCpHKm4eONu8Bkjl+5BsQ04GP7yooZqZ53GN8wI4Xd2PbHi b6YVlujtTRaxQvjtTBzWrJL8oHgJf7zNPtRM3pu0BsdVhoxL28CCvuTqlNDEBuLDU8W8cX+3xYB1 tA3JCFmrHxxgQ0WNpFCFeoRcxJkHB3JfRIXfpXJw2NTwfpNyiYIXEY5TmUWq+xiVtZwEjKQ/kXSs Q7d6SXcMVHmKvndA9XYhjEzp7zhevhAJqBJuJwhC5MNQ/Ixyhi2Lb98EwJh5vOYV0XRu0WpdFNST wlhh7kyFB8ZIrhsTtz4WDEUBe4cXpwIDAQABo4IBozCCAZ8wHwYDVR0jBBgwFoAUFDDra/X0SbVo UnWm272uW8isfUwwgZEGA1UdIASBiTCBhjCBgwYJKoZIhvcNBQcFMHYwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5yc2FzZWN1cml0eS5jb20vQ1BTLmh0bWwwRAYIKwYBBQUHAgIwODAXFhBSU0EgU2Vj dXJpdHkgTExDMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCkGA1UdJQQiMCAG CisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgNVHREEPTA7gRlrYXRobGVlbi5tb3Jp YXJ0eUBlbWMuY29toB4GCisGAQQBgjcUAgOgEAwObW9yaWFrQGVtYy5jb20wDgYDVR0PAQH/BAQD AgeAMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNs YXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYEFEfJREQxfcvAOlqJ3jwY1/++6ktIMA0GCSqG SIb3DQEBBQUAA4IBAQBwuy2NnyUuHNb79RtlEU+nmBbPaGNUtELBtIXmmMHzmylw/SK1kkUH7+Eq 1M4lylKZnHtFb0W0EVsf3bU6RoTPNxQitgx6gQp9RXnu0UXD5L0PybdDD0ShKLPifUe5HIFfZ6rn sKZ+coYMAYxFMPRVbvZcchlR9aAhAtS9JIS49cp6F8L7BvSrGMRpODzDCGyD4+8a1M1pivDwEMd7 OrTNimQMrjfoDA8Hbqw3FUgavQTAmcwwx88GaCQnVguxYd59mwVpDh4NtGnsz2tIAJ/9cEieYLwW 06RgYpZtTE6GAAxd90uYqo94CK31azcUN2GjmnfLj/nsscSR66pBSn50MIIFuTCCBKGgAwIBAgIR AJMBY13rQIwiCFVvrbx5PZ4wDQYJKoZIhvcNAQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQI Ew1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkg TExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0Eg Q2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMjA0MDMxNzEwNDhaFw0xNDA0MDMxNzEwMzJaMIHd MRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMg Q29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2FzMREwDwYDVQQLEwhDb25zdW1lcjEPMA0GA1UE BRMGMDg0MTUzMRYwFAYKCZImiZPyLGQBARMGbW9yaWFrMR4wHAYDVQQDExVLYXRobGVlbiBNb3Jp YXJ0eS1FbmMxKDAmBgkqhkiG9w0BCQEWGWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcbesv4mh7Z07BKcyAeA9MgiHS5o78g4HjhdHyVYgw 6wg0TkfWhTKPKVlcHqkcTaAcvxKm3GBiMsiFz6Ys9GQrSiApXTJlJOVd946e26pGeQ6ZIQB1Mt2K BTxac2+zX5TcDhlvmLExBKTPiEbjsJR1f1azksUdDxSaAFBxYUsoqipvniwfRPOaqqXv4GTQsqOC 6Wl5exk7IJYTFxiautdPD/5a2TJF5ThC2gQrXWo9wL3yOJJ8/vbdh2AQMAXXmyfsMNtuhF1Ct+sK nhGjhG4jJQwLYbRG9dR0uMFtyxDILD9vz8ScuUkaypv771Z2VPZ6mS4Pn2vHluvvQhoEWU4FAgMB AAGjggGvMIIBqzA1BgNVHSUELjAsBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHwYDVR0jBBgwFoAUFDDra/X0SbVoUnWm272uW8isfUwwgZEGA1UdIASBiTCBhjCB gwYJKoZIhvcNBQcFMHYwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1cml0eS5jb20vQ1BT Lmh0bWwwRAYIKwYBBQUHAgIwODAXFhBSU0EgU2VjdXJpdHkgTExDMAMCAQEaHUNQUyBJbmNvcnBv cmF0ZWQgYnkgcmVmZXJlbmNlMEQGA1UdEQQ9MDuBGWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb22g HgYKKwYBBAGCNxQCA6AQDA5tb3JpYWtAZW1jLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBSramWspVPOGwyy09NkCwcziN1W5jAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQADggEB ACrOJZt/SlHcro3HWRYEznk3JyKMFLUakwsppH0NvAuX6pEc55bjNebanGUIxSXMKh6BtcZy2j84 2WUky6YQm4wvluSAvo8FvyjSD5C6Nvp5gl+NuPISVbxlePXImfbyxCWijqp1ecK2DQsNcb3IFAaa ymkDw7tz78C1ZqW+z2mC6xE9gwzD+1CzJHriFiVyv14Mnsb26dJKkGgJI9NrKP1jO0G+YY7kMDfN NReNxMBGraA+gashn3Bwe4pYxHh+moSAbAOxhMgbsiEE1TNdspDz8GLZ3FkDZjhRPghOpOnCDFpz agxioFquh9toWfUCKwLAgMHpLjjbsZKmtzl1+YkxggQ3MIIEMwIBATCBszCBnjELMAkGA1UEBhMC VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0JlZGZvcmQxGTAXBgNVBAoTEFJT QSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0eSBPcmdhbml6YXRpb24xIzAh BgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyAhBg15wLd6XJPs1CfFZcPiocMAkGBSsO AwIaBQCgggJYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIw MzIyMTEzNlowIwYJKoZIhvcNAQkEMRYEFMlX6/41FxuhTmnvGsOL74VYC4UhMGcGCSqGSIb3DQEJ DzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHFBgkrBgEEAYI3EAQxgbcwgbQw gZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3Jk MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3Jn YW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIRAJMBY13rQIwi CFVvrbx5PZ4wgccGCyqGSIb3DQEJEAILMYG3oIG0MIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMN TWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExM QzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENs YXNzIDIgUGVyc29uYWwgQ0EgdjICEQCTAWNd60CMIghVb628eT2eMA0GCSqGSIb3DQEBAQUABIIB AFcziAYIi/EHsNg01zshGcL7wqUY+2kLAc0xODAvvBcpZYnVN8rqmyfgVnM2TVo1UJO780Ash9wl d2rt5ZSE9LHUD624luTLnuDwXUp6386tGB98EoestTA3byS3f6Yx7gnBoFRqRCvstTlFYzYI+LTw aVCp/lZQ/8doo7Ea4d8V8xQyAQ+UaMiNYUM9S0UFjabIflJO9tgw3SYEY8zYMeXmeDXSNs0XzNmG 4zG2DVigsmFwetxWOgntp41VYW+s6ar7OfafBlfiAnjIg7vdQDrlOSSiWw9dl5HGXAZwpRAqALvx AeZcB7pUAX0XWJI49aOXsyUXHx0w3AZIOZOTytMAAAAAAAA= ------=_NextPart_000_0024_01CE0231.85F0B1C0-- From Paul.Stoecker@rsa.com Sun Feb 3 17:26:33 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EF821F88E5 for ; Sun, 3 Feb 2013 17:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.249 X-Spam-Level: *** X-Spam-Status: No, score=3.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnfSTgJ9bPGt for ; Sun, 3 Feb 2013 17:26:30 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E3F5621F88E3 for ; Sun, 3 Feb 2013 17:26:25 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r141QOPW014439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Feb 2013 20:26:25 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sun, 3 Feb 2013 20:26:06 -0500 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r141Q50f008479 for ; Sun, 3 Feb 2013 20:26:06 -0500 Received: from mx33a.corp.emc.com ([169.254.1.154]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Sun, 3 Feb 2013 20:26:05 -0500 From: "Stoecker, Paul" To: "Moriarty, Kathleen" , "Harrington, Christopher" , MILE IETF Date: Sun, 3 Feb 2013 20:26:02 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4Cdpmb1RU1c3enRUyj7UuiUQgqBQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD346D68D0F9paulstoeckerrsacom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 01:26:33 -0000 --_000_CD346D68D0F9paulstoeckerrsacom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable What if we added indicator group ID along with the indicator_uid? This wou= ld allow you to group indicators that are related into the same group ID. = Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) class= that will should be used to take all of the indicators put them into one p= lace and have the ability to group the ones that go together. I don't mean= a place to put indicators that are missing from IODEF=85I mean a place in = the IODEF document where you put the indicators that are used for detection= and prevention of the shared Incident. I don't know the answer here, but = there has got to be a good way for indicators to be identified and being ab= le to group them as Chris has suggested without basically recreating someth= ing complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs Hi Chris, I agree, we have some work to do in the updated IODEF, RFC5070-bis. The list has already said they would like to see indicators added to the de= finitions in RFC5070-bis, to be more explicit about including indicators an= d sets of indicators in IODE documents as opposed to =91parts of an inciden= t or the useful information on an incident for sharing purposes. It was wr= itten before we used terms like indicators. With that in mind, Rosella pro= posed a number of changes back in July, both for guidance and for format up= dates. It may help to have the first draft try to address at least some of= these issues so people can understand the problems and at least a proposed= solution. As you point out, we need to be able to show relationships between sets of = indicators, where we may have a few sets of indicators that could have a re= lationship to each other within a document. In the July presentation, one = of the questions was to see if we should add new category attribute values = for the System class that would connect the list of included indicators. I= think we should still keep the concept of a Node to a single node, but per= haps within System, list multiple sets of Nodes that may be one type of att= ack. Rosella had suggested pulling forward the =93FraudType=94 from RFC590= 1, this would help solve the issue as NodeRole values would compliment an A= ttackType (FraudType values could be included in AttackType or some broader= term). It may be better to have the FraudTypes, plus attribute values lik= e =93C2-server=94, =93sinkhole=94, =93MalwareDistribution=94 for added con= text so you know what to do with the received set of indicators. I am proposing that we change IODEF to include multiple sets of indicators,= add an AttackType attribute (or some other name), a method to connect indi= cators and indicator sets within an IODEF using an attribute of indicator_u= id (or some other name) with a string value to make the connection points, = and add a few indicators that are commonly shared into the base IODEF. Back in July, we talked about adding Registry Key/Value pairs and hashes to= the main IODEF document (trying to see if this will help Chris below). Wh= at if we added the Registry Key/Value pairs as a class off of RecordData, u= sing a similar structure to what is in RFC5901, and also added the ability = to include hashes in RecordData? I think if we then had the indicator_uid = at the RecordData level, we could connect a set within that structure and r= epeat the structure for other sets in the same way we would do with Node in= side of the System class, using the indicator_uid to tie the set together. = Then at the more specific level for the hash, registry Key/value, IP, etc.= use an indicator_uid if we needed them marked at this level as well? Mayb= e we want indicator_set at the higher level? I=92d like some opinions on t= his approach. +1 if you agree, suggestions if you have other ideas that ma= y work better. We=92ll also need to worry about marking the indicators to prevent forward = sharing when not permitted. We may want to use these values or something e= lse. Thank you! Kathleen From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs I think we have a bigger relationship issue to address. Let use the Watchli= st Use Case. A bunch of indicators are sent in one message. In that message= we could have groupings of indicators that we need to show are related: Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses.= Either or both may be present to indicate a compromise. Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is p= resent it is a compromise indicator but both will not be present. The problem compounds itself very quickly. Consider the scenario where both= groupings above are part of the same threat. I need to show that logical g= roupings of Indicators are related as well. We can=92t send multiple IODEF = messages for this from what I remember reading. The last one I can think of would be when you have 2 different indicators t= hat represent the same indicator. It=92s not uncommon to send both the MD5 = and SHA1 hash of a malicious file. The indicator is the file but the IOCs a= re the 2 hash values. How do we show they are related? If we use a unique I= nidcator ID for each hash value there needs to be a higher level grouping. Thoughts? Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs All =96 I=92d like your input and will refocus the thread to get opinions from the = list on options to help solve the problems raised in my message and additio= nally in Paul=92s message. Interesting point, C. Henry. Our objective here is to have machine automat= ed exchanges, so we rely on encryption rather than obfuscation to achieve t= he necessary level of confidentiality. Paul mentioned the need to distinguish indicators of compromise from contex= t information that may also include IP address or other data that could be = indicators. The question I raised was on how to connect sets of indicators= in the same IODEF document, assuming the ability to have watchlists that c= ould have several sets of indicators included, as well as to connect indica= tors that may be included in embedded schemas. If we add an attribute on all of the relevant indicators, let=92s say =91in= dicator-uid=92 how do we mark the indicators? Do we use this to mark who s= ent the indicator as well so that we can prevent forward sharing when it is= not permitted or handle that separately? Then for indicators not included in the base schema that may not fit into a= category in the SCI draft, do we create a place for these off of SCI or ri= ght off of the IODE schema in EventData? (more details on this in my first = message). Comments and questions encouraged to figure out the right technical solutio= n to have this machine automatable. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of C. Henry = Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs Temporal Dependency sounds interesting. I remember when I first ran across= this particular craft, an experienced colleague asked me a peculiar questi= on. He said, " How do you stop someone from tracking the IP Address to you= r computer?" I replied, "I don't know, how?" Then he said, "Cut the dog-gone thing off and the modem that it is connect= ed- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder search= ing a Neighborhood for Survivors which were hit by a Disaster or let's just= say "Live" Terrorist Situation. He /or She needs to communication back to= other Officials that he /or somehow is in Danger. The device used to comm= unicate has been captured by the great minds of the enemy. It's only a mat= ter of time before they utilize reverse engineering to figure out how it fu= nctions. However, their pride comes before a fall when seeking the locatio= n of other similar devices to attack. Why? Perhaps the less thought of con= cepts that makes the device function properly, saves the day by disguise or= cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell > wrote: From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temp= oral Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: > Serialization of a particular Lists of XML Classes in a unique way was cl= osely related to what I attempted to express when I stated, "consider to a = degree what appears to be illogical in brilliant minds in some instances." > > However, I see Dr. Stoecker's point a little clearer. However, it would = be nice if the UID was in some way disguised from those who study this Secu= rity Art Form in a negative way. > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > > Re: [mile] IOCs > > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > > To: > "mile@ietf.org" > > I would like to look at this from a slightly different perspective=8Alet'= s > say I get an XML document that tells me about an incident. This document > has source IP and destination IP that is being shared. However, what I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing to > tell me which IP is the one, even if the roles are set it still might not > be enough to tell my system which one I should use as the indicator. > > If we had something like indicator_id as an attribute, it would allow us > to easily identify indicators from contextual data. I do admit to being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make it > very clear what the indicators are in the XML document and the other data > that may be important as I investigate activity that I have detected off > of those indicators. > > > I did suggest the detection class, but I think we may get more flexibilit= y > with the indicator_uid. One thing that I haven't considered is the UID > portion of this=8Ahow do we use that UID? How is the UID created? Are > there standards for UIDs? > > Regards, > > Paul > > > > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM > > Greetings Kathleen, > > Your logic stimulates my visionary brain because I'm amazed at the many a= venues you review with this approach at once. However, could you share a = few advantages and disadvantages to the latter? > > -------------------------------------------------------------------------= ------------------------------------------------- > "we could continue to group items in logical places as is done now in IOD= EF and then have the extension point for combined indicators via SCI." > > -------------------------------------------------------------------------= ------------------------------------------------ > > You pointed out what you consider to be logical places, but if I wanted t= o protect information from parties capable of ascertaining it from your log= ical places, perhaps we should also consider to a degree what appears to be= illogical in brilliant minds in some instances. > > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" >, "mile@ietf.org" > > Date: Saturday, January 26, 2013, 10:13 AM > > Hello C. Henry & others, > > Thanks for taking a look at this. We have a few considerations in this e= mail thread I would like to hear thoughts on (and there may be more once RF= C5070-bis is actively edited). > > The AdditionalData class and the RecordItem class both allow for non-XML = extensions. Where you place the extensions should be specific to the logic= al grouping of the parent elements so you can understand more about the inc= luded data in most cases. > > The Impact class can be used to provide context information on the includ= ed data of the report and also can include a confidence rating on the repor= t as a whole. Extensions related to impact would be one level higher (at t= he moment) in the Assessment class using the AdditionalData extension point= . > > Take asked about including vulnerability information, I would think that = would fit under the Vulnerability extension point of the SCI draft in the M= ethod class. He did ask about non-XML. RecordItem or AdditionalData do al= low for non-XML extension points, we could either have the SCI draft handle= these as well or have the extensions that are non-XML come directly off th= e AdditionalData or RecordItem classes according to what makes sense from a= logical standpoint. > > As for my question, it was two-fold. > > Indicator based schemas have a reference number or a GUID for the various= indicators they share. If we are extending to embed other schemas that in= clude such reference or GUID identifiers, do we want to add an attribute to= the various elements in IODEF that could be indicators? Is this enough to= make the connections or is something else else needed? We could add somet= hing like an Indicator_ID in RFC5070-bis which would then correlate to the = reference or GUID identifiers. > > Then the other question was on how to include indicators that are not in = the base schema that may be related or have language with "and" "or" to spe= cify the relationships. In some cases, you will want to group these indict= ors in one extension point, where they may fit logically in multiple places= if the relationships did not need to be shown in the data format. If we h= ave cases like this where you need more complex representations, should we = use one extension point via the SCI draft off of the EventData class Additi= onalData extension point? Opinions are needed here.... > > A few people have mentioned wanting to include some commonly shared indic= tors into the base IODEF document. We could have a catch-all class that do= es this and has an extension point off of it in EventData or we could conti= nue to group items in logical places as is done now in IODEF and then have = the extension point for combined indicators via SCI. I think I like the la= tter approach. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile= -bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs > > Greetings Everyone, > > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the SCI's > EventReport class, IMHO. > > 2) If the indicators are something like an non-XML ones, I guess it could= be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey the > indicators. > We could for instance extend the list of indicators of the Impact class, = if > needed. > -------------------------------------------------------------------------= ----------------------------- > > In doing so he pointed out the "Impact Class" > > Whereas, Kathleen stated, > > -------------------------------------------------------------------------= ---------------------------- > For the discussion below, I was thinking more of combined set with relati= onships that may be included in a single extension point, so that's why I w= as thinking about the EventData class, but there may be better locations or= a specific area within the EventData. > > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --------------------------- > > Kathleen thoughts related yet still with other indicators and the EventDa= ta Class. > > Is there a possible way to create a new XML class which encompass combini= ng the EventData, Detection and base IODEF classes to simplify this issue? > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --_000_CD346D68D0F9paulstoeckerrsacom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
What if we added indicator= group ID along with the indicator_uid?  This would allow you to group= indicators that are related into the same group ID.  Would this resol= ve the issue?

It is either that or going back to a= dding a Detection (or Indicators) class that will should be used to take al= l of the indicators put them into one place and have the ability to group t= he ones that go together.  I don't mean a place to put indicators that= are missing from IODEF=85I mean a place in the IODEF document where you pu= t the indicators that are used for detection and prevention of the shared I= ncident.  I don't know the answer here, but there has got to be a good= way for indicators to be identified and being able to group them as Chris = has suggested without basically recreating something complicated like STIX.=

Paul


Paul W. Stoecker, Ph.D.

<= span style=3D"font-size: 10pt; font-family: Verdana, sans-serif; color: nav= y; ">SMC Lead Content Architect

= RSA, The Security Division of EMC

cell: 302.379.3375 | e: p= aul.stoecker@rsa.com


From: <Moriarty>= ;, Kathleen <kathleen.moria= rty@emc.com>
Date: Sunda= y, February 3, 2013 5:11 PM
To: = "Harrington, Christopher" <Christopher.Harrington@emc.com>, MILE IETF <mile@ietf.org>
Subject: Re: [mile] IOCs

Hi Chris,

 

I = agree, we have some work to do in the updated IODEF, RFC5070-bis.

 

The list has already said th= ey would like to see indicators added to the definitions in RFC5070-bis, to= be more explicit about including indicators and sets of indicators in IODE= documents as opposed to =91parts of an incident or the useful information = on an incident for sharing purposes.  It was written before we used te= rms like indicators.  With that in mind, Rosella proposed a number of = changes back in July, both for guidance and for format updates.  It ma= y help to have the first draft try to address at least some of these issues= so people can understand the problems and at least a proposed solution.

 

As you point out, we = need to be able to show relationships between sets of indicators, where we = may have a few sets of indicators that could have a relationship to each ot= her within a document.  In the July presentation, one of the questions= was to see if we should add new category attribute values for the System c= lass that would connect the list of included indicators.  I think we s= hould still keep the concept of a Node to a single node, but perhaps within= System, list multiple sets of Nodes that may be one type of attack.  = Rosella had suggested pulling forward the =93FraudType=94 from RFC5901, thi= s would help solve the issue as NodeRole values would compliment an AttackT= ype (FraudType values could be included in AttackType or some broader term)= .  It may be better to have the FraudTypes, plus attribute values like= =93C2-server=94, =93sinkhole=94,  =93MalwareDistribution=94 for added= context so you know what to do with the received set of indicators.

 

I am proposing that we ch= ange IODEF to include multiple sets of indicators, add an AttackType attrib= ute (or some other name), a method to connect indicators and indicator sets= within an IODEF using an attribute of indicator_uid (or some other name) w= ith a string value to make the connection points, and add a few indicators = that are commonly shared into the base IODEF.

 

Back in July, we talked about adding Registry Ke= y/Value pairs and hashes to the main IODEF document (trying to see if this = will help Chris below).  What if we added the Registry Key/Value pairs= as a class off of RecordData, using a similar structure to what is in RFC5= 901, and also added the ability to include hashes in RecordData?  I th= ink if we then had the indicator_uid at the RecordData level, we could conn= ect a set within that structure and repeat the structure for other sets in = the same way we would do with Node inside of the System class, using the in= dicator_uid to tie the set together.  Then at the more specific level = for the hash, registry Key/value, IP, etc. use an indicator_uid if we neede= d them marked at this level as well?  Maybe we want indicator_set at t= he higher level?  I=92d like some opinions on this approach.  = 3;1 if you agree, suggestions if you have other ideas that may work better.=

 <= /o:p>

We=92ll also need = to worry about marking the indicators to prevent forward sharing when not p= ermitted.  We may want to use these values or something else. 

 

Thank you!
Kathle= en 

 

From: Harringto= n, Christopher
Sent: Friday, February 01, 2013 12:01 PM
To= : Moriarty, Kathleen; MILE IETF
Subject: RE: [mile] IOCs=

 

I think we have a bigger relationshi= p issue to address. Let use the Watchlist Use Case. A bunch of indicators a= re sent in one message. In that message we could have groupings of indicato= rs that we need to show are related:

 

= Two or more indicators of different type that relate to t= he same threat:

The file hash of a malicious file and the URL= of the C2 that the file uses. Either or both may be present to indicate a = compromise.

=  

Two or= more indicators of the same type that relate to the same threat:

2 different registry values for the same registry key. If either val= ue is present it is a compromise indicator but both will not be present.

 

The problem compound= s itself very quickly. Consider the scenario where both groupings above are= part of the same threat. I need to show that logical groupings of Indicato= rs are related as well. We can=92t send multiple IODEF messages for this fr= om what I remember reading.

 

The last one I can think of would be when you have 2 different in= dicators that represent the same indicator. It=92s not uncommon to send bot= h the MD5 and SHA1 hash of a malicious file. The indicator is the file but = the IOCs are the 2 hash values. How do we show they are related? If we use = a unique Inidcator ID for each hash value there needs to be a higher level = grouping.

 

Thoughts?=

 

Thanks,

 

= --Chris

 

Christopher Harrington

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">Consulting Security Engineer

GSO - Critical Incident Response Center

EMC - Where Inf= ormation Lives

Bedford, MA 01730

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">781-515-5862 (work)

603-583-1585 (cell)

 

From: mil= e-bounces@ietf.org [mailto:mil= e-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent:<= /b> Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subjec= t: Re: [mile] IOCs

 

All =96 <= o:p>

 

I=92d like your inp= ut and will refocus the thread to get opinions from the list on options to = help solve the problems raised in my message and additionally in Paul=92s m= essage.

=  

Interesting= point, C. Henry.  Our objective here is to have machine automated exc= hanges, so we rely on encryption rather than obfuscation to achieve the nec= essary level of confidentiality.

 

Paul mentioned the need to distinguish indicators of compromi= se from context information that may also include IP address or other data = that could be indicators.  The question I raised was on how to connect= sets of indicators in the same IODEF document, assuming the ability to hav= e watchlists that could have several sets of indicators included, as well a= s to connect indicators that may be included in embedded schemas.

 

If we add an attribute on al= l of the relevant indicators, let=92s say =91indicator-uid=92 how do we mar= k the indicators?  Do we use this to mark who sent the indicator as we= ll so that we can prevent forward sharing when it is not permitted or handl= e that separately? 

 

Then for indicators not included in the base schema that may not fit= into a category in the SCI draft, do we create a place for these off of SC= I or right off of the IODE schema in EventData? (more details on this in my= first message).

 

Co= mments and questions encouraged to figure out the right technical solution = to have this machine automatable.

 

Thank you,

Kathleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of C. Henry Adams & BIE
Sent: Monday, Januar= y 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] I= OCs

 

=

Temporal Dependency sounds interesting.  I remember= when I first ran across this particular craft, an experienced colleague as= ked me a peculiar question.  He said, " How do you stop someone f= rom tracking the IP Address to your computer?" 

I replied= , "I don't know, how?"

Then he said, "Cut the dog-go= ne thing off  and the modem that it is connected- which is constantly = on!"   LOL

Here's my point (Hypothetical Situation) :=   There is a 1st Responder searching a Neighborhood for Survivors whic= h were hit by a Disaster or let's just say "Live" Terrorist Situa= tion.  He /or She needs to communication back to other Officials that = he /or somehow is in Danger.  The device used to communicate has been = captured by the great minds of the enemy.  It's only a matter of time = before they utilize reverse engineering to figure out how it functions.&nbs= p; However, their pride comes before a fall when seeking the location of ot= her similar devices to attack.  Why? Perhaps the less thought of conce= pts that makes the device function properly, saves the day by disguise or c= utting it off (figuratively speaking).

Just a visionary thought.
=
C. Henry Adams
chen= ryadams@biemediagroup.com
http:= //biemediagroup.com


The information contained herein is for = the exclusive use of the original recipient. This information is granted fo= r limited distribution within the recipient's place of business for plannin= g purposes only. Further dissemination, whether private or public is prohib= ited.

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> wrote:=


From: Dave Mi= sell <david.misell@bcs.org&g= t;
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" = <chatlga2000@yahoo.com><= br>Date: Monday, January 28, 2013, 9:25 PM

UID could be mirrored with DNS SEC= a pemanent and temporal key, with a temporal Id?

Yours Faithfully,<= br>
Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
<= a href=3D"/mc/compose?to=3Ddavid.misell@bcs.org">david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrot= e:

> Serialization of a particular Lists of XML Classes in a uniq= ue way was closely related to what I attempted to express when I stated, &q= uot;consider to a degree what appears to be illogical in brilliant minds in= some instances."
>
> However, I see Dr. Stoecker's point= a little clearer.  However, it would be nice if the UID was in some w= ay disguised from those who study this Security Art Form in a negative way.=
>
> C. Henry Adams
> chatlga2000@yahoo.com (Direct Email)
> chenryadams@biemediagro= up.com
>
>
> The information contained herein is fo= r the exclusive use of the original recipient. This information is granted = for limited distribution within the recipient's place of business for plann= ing purposes only. Further dissemination, whether private or public is proh= ibited.
>
> Re: [mile] IOCs
>
> Sunday, January 2= 7, 2013 8:52 PM
> From:
> "Stoecker, Paul" <Paul.Stoecker@rsa.com><= br>> To:
> "mile@i= etf.org" <mile@ietf.= org>
> I would like to look at this from a slightly different = perspective=8Alet's
> say I get an XML document that tells me about a= n incident.  This document
> has source IP and destination IP th= at is being shared.  However, what I
> don't know is which IP ad= dress is my indicator and which is just a
> contextual piece of infor= mation.  This means that my detection product
> isn't going to k= now which one to use either, because there is nothing to
> tell me wh= ich IP is the one, even if the roles are set it still might not
> be = enough to tell my system which one I should use as the indicator.
> <= br>> If we had something like indicator_id as an attribute, it would all= ow us
> to easily identify indicators from contextual data.  I d= o admit to being
> biased as I have spent much of my career working o= n the monitoring and
> detection side of these things, so I am just t= hinking of ways to make it
> very clear what the indicators are in th= e XML document and the other data
> that may be important as I invest= igate activity that I have detected off
> of those indicators.
>= ;
>
> I did suggest the detection class, but I think we may g= et more flexibility
> with the indicator_uid.  One thing that I = haven't considered is the UID
> portion of this=8Ahow do we use that = UID?  How is the UID created?  Are
> there standards for UI= Ds?
>
> Regards,
>
> Paul
>
>
&g= t;
> Paul W. Stoecker, Ph.D.
> SMC Lead Content Architect
&= gt; RSA, The Security Division of EMC
> cell: 302.379.3375 | e: paul.stoecker@rsa.com
= >
> --- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote= :
>
> From: C. Henry Adams & BIE <chatlga2000@yahoo.com>
> Subject= : RE: [mile] IOCs
> To: "KathleenMoriarty" <kathleen.moriarty@emc.com>= ;
> Cc: mile@ietf.org<= br>> Date: Saturday, January 26, 2013, 6:17 PM
>
> Greeting= s Kathleen,
>
> Your logic stimulates my visionary brain becau= se I'm amazed at the many avenues you review with this approach at once.&nb= sp; However,  could you share a few advantages and disadvantages to th= e latter?
>
> ------------------------------------------------= --------------------------------------------------------------------------<= br>> "we could continue to group items in logical places as is done= now in IODEF and then have the extension point for combined indicators via= SCI."
>
> ----------------------------------------------= ---------------------------------------------------------------------------=
>
> You pointed out what you consider to be logical places, b= ut if I wanted to protect information from parties capable of ascertaining = it from your logical places, perhaps we should also consider to a degree wh= at appears to be illogical in brilliant minds in some instances.
> >
>
> C. Henry Adams
> chatlga2000@yahoo.com (Direct Email)
> = chenryadams@biem= ediagroup.com
>
> The information contained herein is for = the exclusive use of the original recipient. This information is granted fo= r limited distribution within the recipient's place of business for plannin= g purposes only. Further dissemination, whether private or public is prohib= ited.
>
> --- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:
>
> From: Moriarty, Kathleen <kathleen.moriarty@emc.com>> Subject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE&= quot; <chatlga2000@ya= hoo.com>, "mile@ietf= .org" <mile@ietf.org= >
> Date: Saturday, January 26, 2013, 10:13 AM
>
>= ; Hello C. Henry & others,
>
> Thanks for taking a look at= this.  We have a few considerations in this email thread I would like= to hear thoughts on (and there may be more once RFC5070-bis is actively ed= ited).
>
> The AdditionalData class and the RecordItem class b= oth allow for non-XML extensions.  Where you place the extensions shou= ld be specific to the logical grouping of the parent elements so you can un= derstand more about the included data in most cases. 
>
>= ; The Impact class can be used to provide context information on the includ= ed data of the report and also can include a confidence rating on the repor= t as a whole.  Extensions related to impact would be one level higher = (at the moment) in the Assessment class using the AdditionalData extension = point. 
>
> Take asked about including vulnerability inf= ormation, I would think that would fit under the Vulnerability extension po= int of the SCI draft in the Method class.  He did ask about non-XML.&n= bsp; RecordItem or AdditionalData do allow for non-XML extension points, we= could either have the SCI draft handle these as well or have the extension= s that are non-XML come directly off the AdditionalData or RecordItem class= es according to what makes sense from a logical standpoint.
>
>= ; As for my question, it was two-fold.
>
> Indicator based sch= emas have a reference number or a GUID for the various indicators they shar= e.  If we are extending to embed other schemas that include such refer= ence or GUID identifiers, do we want to add an attribute to the various ele= ments in IODEF that could be indicators?  Is this enough to make the c= onnections or is something else else needed?  We could add something l= ike an Indicator_ID in RFC5070-bis which would then correlate to the refere= nce or GUID identifiers.
>
> Then the other question was on ho= w to include indicators that are not in the base schema that may be related= or have language with "and" "or" to specify the relati= onships.  In some cases, you will want to group these indictors in one= extension point, where they may fit logically in multiple places if the re= lationships did not need to be shown in the data format.  If we have c= ases like this where you need more complex representations, should we use o= ne extension point via the SCI draft off of the EventData class AdditionalD= ata extension point?  Opinions are needed here....
>
> A= few people have mentioned wanting to include some commonly shared indictor= s into the base IODEF document.  We could have a catch-all class that = does this and has an extension point off of it in EventData or we could con= tinue to group items in logical places as is done now in IODEF and then hav= e the extension point for combined indicators via SCI.  I think I like= the latter approach.
>
> Thank you,
> Kathleen
> = ________________________________________
> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C= . Henry Adams & BIE [chatlga2000@yahoo.com]
> Sent: Saturday, January 26, 2013 3:05 A= M
> To: mile@ietf.org<= br>> Cc: C. Henry Adams
> Subject: Re: [mile] IOCs
>
>= ; Greetings Everyone,
>
> Take mentioned two types of indicato= rs based on the :
> -------------------------------------------------= -----------------------------------------------------
> 1) If the ind= icators are something like an XML-based alert/warning of
> informatio= n leakage, it could be an event that are conveyed in the SCI's
> Even= tReport class, IMHO.
>
> 2) If the indicators are something li= ke an non-XML ones, I guess it could be
> conveyed without using SCI = draft.
> For instance, we could use Impact class of the base IODEF to= convey the
> indicators.
> We could for instance extend the li= st of indicators of the Impact class, if
> needed.
> ----------= ---------------------------------------------------------------------------= -----------------
>
> In doing so he pointed out the "Imp= act Class"
>
> Whereas, Kathleen stated,
>
>= --------------------------------------------------------------------------= ---------------------------
> For the discussion below, I was thinkin= g more of combined set with relationships that may be included in a single = extension point, so that's why I was thinking about the EventData class, bu= t there may be better locations or a specific area within the EventData.>
> Paul Stoecker had suggested a "Detection" class as= a consideration.
> -------------------------------------------------= ---------------------------------------------------
>
> Kathle= en thoughts related yet still with other indicators and the EventData Class= .
>
> Is there a possible way to create a new XML class which = encompass combining the EventData, Detection and base IODEF classes to simp= lify this issue?
>
>
> C. Henry Adams
> chatlga2000@yahoo.com (Dire= ct Email)
> chenryadams@biemediagroup.com
>
>
> The informati= on contained herein is for the exclusive use of the original recipient. Thi= s information is granted for limited distribution within the recipient's pl= ace of business for planning purposes only. Further dissemination, whether = private or public is prohibited.
> __________________________________= _____________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/list= info/mile

 

 --_000_CD346D68D0F9paulstoeckerrsacom_-- From eburger-l@standardstrack.com Mon Feb 4 03:18:33 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10D21F8620 for ; Mon, 4 Feb 2013 03:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.878 X-Spam-Level: ** X-Spam-Status: No, score=2.878 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahaFvOigmHIs for ; Mon, 4 Feb 2013 03:18:31 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id C937A21F861F for ; Mon, 4 Feb 2013 03:18:31 -0800 (PST) Received: from 208.177.47.110.ptr.us.xo.net ([208.177.47.110]:60011 helo=[10.166.71.157]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U2K3t-00039z-F7; Mon, 04 Feb 2013 03:18:09 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <1359746662.67639.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Mon, 4 Feb 2013 06:18:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D595815-C27D-4F93-BEA2-F0FE30550C31@standardstrack.com> References: <1359746662.67639.YahooMailClassic@web121601.mail.ne1.yahoo.com> To: C. Henry Adams & BIE X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: MILE IETF Subject: [mile] C. Henry's Analytical Attack X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:18:33 -0000 I am not quite sure this attack is relevant in the MILE use case. I = would be curious if you could explain in further detail how you would = disrupt MILE communications. If there is a fatal flaw (beyond the known = flaws in TCP), it would be good to get them out in the open. Considering the Computer Science perspective, if we are modeling a = complex world, our model will be complex. Check out McCabe. However, = one can add more complexity than necessary to model our domain. That is = what we seek to avoid here. Note that I changed the subject of the thread, as this has nothing to do = with indicator correlation. On Feb 1, 2013, at 2:24 PM, C. Henry Adams & BIE = wrote: > Greetings, >=20 > It is truly a privileged to be in the midst of so many Intelligent = Cyber Security Minds. Each time I read the threads on Mile, I find = myself referencing terminology, acronyms related to computer science and = RFCs. >=20 > Furthermore, it is my desire to understand and share the Vision of the = Author(s) which I'm assuming consist of Kathleen, as well as, others. = So, please forgive me if you completely blow over my head with your = logic, fore, I'm not that far behind you in thought. =20 >=20 > Kathleen, I understood your following statement: "Our objective here = is to have machine automated exchanges, so we rely on encryption rather = than obfuscation to achieve the necessary level of confidentiality." >=20 > Forgive me, but is not Encryption and Obfuscation one in the same = depending on how you look at it. >=20 > Furthermore, if I was to tell you that a "Simple Minded Computer = Technician" like myself could figure out analytically how to attack your = indicators to set up a simple plan to disable your automated machine's = communications, would you not believe me? Oh, one more thing, the fact = of the matter that the capabilities would be there- would be based on = say the protocol you put into place by complexity rather than = simplicity. >=20 > Paul has great points. Chris and Dave are on point as well. I'm = clearly not a technical writer, but I'm a visionary that enjoys putting = things into action. No offense or disrespect, just being counter = intuitive when comes to a train wreck. >=20 >=20 >=20 >=20 > From: > "Harrington, Christopher" > To: > "Moriarty, Kathleen" , "MILE IETF" = > Message contains attachments > 1 File (7KB) > =95 smime.p7s > I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related: >=20 > =20 > Two or more indicators of different type that relate to the same = threat: >=20 > The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise. >=20 > =20 > Two or more indicators of the same type that relate to the same = threat: >=20 > 2 different registry values for the same registry key. If either value = is present it is a compromise indicator but both will not be present. >=20 > =20 > The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that = logical groupings of Indicators are related as well. We can=92t send = multiple IODEF messages for this from what I remember reading. >=20 > =20 > The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=92s not uncommon to = send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping. >=20 > =20 > Thoughts? >=20 > =20 > Thanks, >=20 > =20 > --Chris >=20 > =20 > Christopher Harrington >=20 > Consulting Security Engineer >=20 > GSO - Critical Incident Response Center >=20 > EMC - Where Information Lives >=20 > 174 Middlesex Turnpike >=20 > Bedford, MA 01730 >=20 > 781-515-5862 (work) >=20 > 603-583-1585 (cell) >=20 > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > =20 > All =96 >=20 > =20 > I=92d like your input and will refocus the thread to get opinions from = the list on options to help solve the problems raised in my message and = additionally in Paul=92s message. >=20 > =20 > Interesting point, C. Henry. Our objective here is to have machine = automated exchanges, so we rely on encryption rather than obfuscation to = achieve the necessary level of confidentiality. >=20 > =20 > Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators. The question I raised was on how to connect sets = of indicators in the same IODEF document, assuming the ability to have = watchlists that could have several sets of indicators included, as well = as to connect indicators that may be included in embedded schemas. >=20 > =20 > If we add an attribute on all of the relevant indicators, let=92s say = =91indicator-uid=92 how do we mark the indicators? Do we use this to = mark who sent the indicator as well so that we can prevent forward = sharing when it is not permitted or handle that separately?=20 >=20 > =20 > Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message). >=20 > =20 > Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. >=20 > =20 > Thank you, >=20 > Kathleen >=20 > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of C. Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > =20 > Temporal Dependency sounds interesting. I remember when I first ran = across this particular craft, an experienced colleague asked me a = peculiar question. He said, " How do you stop someone from tracking the = IP Address to your computer?" =20 >=20 > I replied, "I don't know, how?"=20 >=20 > Then he said, "Cut the dog-gone thing off and the modem that it is = connected- which is constantly on!" LOL >=20 > Here's my point (Hypothetical Situation) : There is a 1st Responder = searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation. He /or She needs to = communication back to other Officials that he /or somehow is in Danger. = The device used to communicate has been captured by the great minds of = the enemy. It's only a matter of time before they utilize reverse = engineering to figure out how it functions. However, their pride comes = before a fall when seeking the location of other similar devices to = attack. Why? Perhaps the less thought of concepts that makes the device = function properly, saves the day by disguise or cutting it off = (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM >=20 > UID could be mirrored with DNS SEC a pemanent and temporal key, with a = temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE = wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way = was closely related to what I attempted to express when I stated, = "consider to a degree what appears to be illogical in brilliant minds in = some instances." > >=20 > > However, I see Dr. Stoecker's point a little clearer. However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way. > >=20 > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > >=20 > >=20 > > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > >=20 > > Re: [mile] IOCs > >=20 > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different = perspective=8Alet's > > say I get an XML document that tells me about an incident. This = document > > has source IP and destination IP that is being shared. However, = what I > > don't know is which IP address is my indicator and which is just a > > contextual piece of information. This means that my detection = product > > isn't going to know which one to use either, because there is = nothing to > > tell me which IP is the one, even if the roles are set it still = might not > > be enough to tell my system which one I should use as the indicator. > >=20 > > If we had something like indicator_id as an attribute, it would = allow us > > to easily identify indicators from contextual data. I do admit to = being > > biased as I have spent much of my career working on the monitoring = and > > detection side of these things, so I am just thinking of ways to = make it > > very clear what the indicators are in the XML document and the other = data > > that may be important as I investigate activity that I have detected = off > > of those indicators. > >=20 > >=20 > > I did suggest the detection class, but I think we may get more = flexibility > > with the indicator_uid. One thing that I haven't considered is the = UID > > portion of this=8Ahow do we use that UID? How is the UID created? = Are > > there standards for UIDs? > >=20 > > Regards, > >=20 > > Paul > >=20 > >=20 > >=20 > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > >=20 > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > >=20 > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > >=20 > > Greetings Kathleen, > >=20 > > Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once. However, could you = share a few advantages and disadvantages to the latter? > >=20 > > = --------------------------------------------------------------------------= ------------------------------------------------ > > "we could continue to group items in logical places as is done now = in IODEF and then have the extension point for combined indicators via = SCI." > >=20 > > = --------------------------------------------------------------------------= ----------------------------------------------- > >=20 > > You pointed out what you consider to be logical places, but if I = wanted to protect information from parties capable of ascertaining it = from your logical places, perhaps we should also consider to a degree = what appears to be illogical in brilliant minds in some instances. > >=20 > >=20 > >=20 > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > >=20 > > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > >=20 > > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: > >=20 > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" = > > Date: Saturday, January 26, 2013, 10:13 AM > >=20 > > Hello C. Henry & others, > >=20 > > Thanks for taking a look at this. We have a few considerations in = this email thread I would like to hear thoughts on (and there may be = more once RFC5070-bis is actively edited). > >=20 > > The AdditionalData class and the RecordItem class both allow for = non-XML extensions. Where you place the extensions should be specific = to the logical grouping of the parent elements so you can understand = more about the included data in most cases. =20 > >=20 > > The Impact class can be used to provide context information on the = included data of the report and also can include a confidence rating on = the report as a whole. Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point. =20 > >=20 > > Take asked about including vulnerability information, I would think = that would fit under the Vulnerability extension point of the SCI draft = in the Method class. He did ask about non-XML. RecordItem or = AdditionalData do allow for non-XML extension points, we could either = have the SCI draft handle these as well or have the extensions that are = non-XML come directly off the AdditionalData or RecordItem classes = according to what makes sense from a logical standpoint. > >=20 > > As for my question, it was two-fold. > >=20 > > Indicator based schemas have a reference number or a GUID for the = various indicators they share. If we are extending to embed other = schemas that include such reference or GUID identifiers, do we want to = add an attribute to the various elements in IODEF that could be = indicators? Is this enough to make the connections or is something else = else needed? We could add something like an Indicator_ID in RFC5070-bis = which would then correlate to the reference or GUID identifiers. > >=20 > > Then the other question was on how to include indicators that are = not in the base schema that may be related or have language with "and" = "or" to specify the relationships. In some cases, you will want to = group these indictors in one extension point, where they may fit = logically in multiple places if the relationships did not need to be = shown in the data format. If we have cases like this where you need = more complex representations, should we use one extension point via the = SCI draft off of the EventData class AdditionalData extension point? = Opinions are needed here....=20 > >=20 > > A few people have mentioned wanting to include some commonly shared = indictors into the base IODEF document. We could have a catch-all class = that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF = and then have the extension point for combined indicators via SCI. I = think I like the latter approach. > >=20 > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > >=20 > > Greetings Everyone, > >=20 > > Take mentioned two types of indicators based on the : > > = --------------------------------------------------------------------------= ---------------------------- > > 1) If the indicators are something like an XML-based alert/warning = of > > information leakage, it could be an event that are conveyed in the = SCI's > > EventReport class, IMHO. > >=20 > > 2) If the indicators are something like an non-XML ones, I guess it = could be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey = the > > indicators. > > We could for instance extend the list of indicators of the Impact = class, if > > needed. > > = --------------------------------------------------------------------------= ---------------------------- > >=20 > > In doing so he pointed out the "Impact Class" > >=20 > > Whereas, Kathleen stated, > >=20 > > = --------------------------------------------------------------------------= --------------------------- > > For the discussion below, I was thinking more of combined set with = relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be = better locations or a specific area within the EventData. > >=20 > > Paul Stoecker had suggested a "Detection" class as a consideration. > > = --------------------------------------------------------------------------= -------------------------- > >=20 > > Kathleen thoughts related yet still with other indicators and the = EventData Class. > >=20 > > Is there a possible way to create a new XML class which encompass = combining the EventData, Detection and base IODEF classes to simplify = this issue? > >=20 > >=20 > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > >=20 > >=20 > > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Feb 4 10:35:30 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BC21F8A8F for ; Mon, 4 Feb 2013 10:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[AWL=-2.625, BAYES_20=-0.74, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzNPp2vTSkKF for ; Mon, 4 Feb 2013 10:35:19 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8A21F8A8E for ; Mon, 4 Feb 2013 10:35:17 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14IZGSx017106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2013 13:35:17 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Mon, 4 Feb 2013 13:34:54 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14IYrxJ018564 for ; Mon, 4 Feb 2013 13:34:53 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Mon, 4 Feb 2013 13:34:53 -0500 From: "Moriarty, Kathleen" To: MILE IETF Date: Mon, 4 Feb 2013 13:34:51 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4Cdpmb1RU1c3enRUyj7UuiUQgqBQAit5aA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE9E2A3FMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:35:30 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A3FMX15Acorpemccom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Others on the list, please chime in to help on this issue and the possible = solutions (agreement or disagreement on approaches). Paul & others, if we have an indicator group id, (let's say indicator_set_i= d) and an indicator unique id (indicator_uid), we might use the indicator_= set_id to mark a set and connect a set within an IODEF document as well as = between other XML documents. If we do that, then is the indicator_uid help= ful? I think it could be if we use that to mark where the indicator origin= ated in some way that we also know how it can be used and if it can be shar= ed forward marked at an indicator level (in addition to the sharing group i= n RID for the whole document or set of documents shared). What would this look like? How about the following where you use the set marker at class level for eac= h of the classes that includes indicators or important context on those ind= icators: +------------------+ | EventData | +------------------+ | ENUM restriction |<>--{0..*}--[ Description ] | |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>--{0..*}--[ Contact ] | |<>--{0..1}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{0..*}--[ Flow ] | |<>--{0..*}--[ Expectation ] | |<>--{0..1}--[ Record ] | |<>--{0..*}--[ EventData ] | |<>--{0..*}--[ AdditionalData ] +------------------+ Since you could use the nested EventData instance to include the full set, = you would need indicator_set_id as an attribute to the EventData class. Th= en Since you can have many of the classes from the above directly in the In= cident class, the ones that contain indicators would also need the capabili= ty to mark or connect a set of indicators. That includes: Method -> Reference (Set at the Reference class so you can tie References t= o specific indicator sets if there are multiple). Flow -> System ( I think the set should start at the System class level, m= aybe at the Flow too), the node should be kept to a single Node that may be repres= ented in many ways, but I think we should add categories to System so we can have = a watchlist at that level without needing many instances of EventData (thoughts)? Th= is would just work when the Service and OperatingSystem information matched ac= ross the watchlist or when that data was omitted. Record -> RecordData (at the RecordData class, where we may add Registry Ke= y/value pairs and file hashes) Context: Contact, Expectation, DetectTime, StartTime, and EndTime By having this at the Assessment and Expectation classes, you can set the r= ecommended actions and confidence levels at the indicator set level. You c= ould alternatively do this by adding more attributes to the individual indi= cator element/classes. Then the Node, Address, NodeName, Application, other added indicators (regi= stry key/value pairs, hashes, etc.) would need the indicator_uid (if this = is helpful). As Paul mentioned, you could have groupings in a new class, but we would ne= ed to be able to include all the types of indicators, so it may be complex = to have more representation options for the same types of indicators. Woul= d the above build in the additional flexibility that is needed or what woul= d the proposed Detection class look like in case it is a better option? Thanks! Kathleen From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? This wou= ld allow you to group indicators that are related into the same group ID. = Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) class= that will should be used to take all of the indicators put them into one p= lace and have the ability to group the ones that go together. I don't mean= a place to put indicators that are missing from IODEF...I mean a place in = the IODEF document where you put the indicators that are used for detection= and prevention of the shared Incident. I don't know the answer here, but = there has got to be a good way for indicators to be identified and being ab= le to group them as Chris has suggested without basically recreating someth= ing complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs Hi Chris, I agree, we have some work to do in the updated IODEF, RFC5070-bis. The list has already said they would like to see indicators added to the de= finitions in RFC5070-bis, to be more explicit about including indicators an= d sets of indicators in IODE documents as opposed to 'parts of an incident = or the useful information on an incident for sharing purposes. It was writ= ten before we used terms like indicators. With that in mind, Rosella propo= sed a number of changes back in July, both for guidance and for format upda= tes. It may help to have the first draft try to address at least some of t= hese issues so people can understand the problems and at least a proposed s= olution. As you point out, we need to be able to show relationships between sets of = indicators, where we may have a few sets of indicators that could have a re= lationship to each other within a document. In the July presentation, one = of the questions was to see if we should add new category attribute values = for the System class that would connect the list of included indicators. I= think we should still keep the concept of a Node to a single node, but per= haps within System, list multiple sets of Nodes that may be one type of att= ack. Rosella had suggested pulling forward the "FraudType" from RFC5901, t= his would help solve the issue as NodeRole values would compliment an Attac= kType (FraudType values could be included in AttackType or some broader ter= m). It may be better to have the FraudTypes, plus attribute values like "C= 2-server", "sinkhole", "MalwareDistribution" for added context so you know= what to do with the received set of indicators. I am proposing that we change IODEF to include multiple sets of indicators,= add an AttackType attribute (or some other name), a method to connect indi= cators and indicator sets within an IODEF using an attribute of indicator_u= id (or some other name) with a string value to make the connection points, = and add a few indicators that are commonly shared into the base IODEF. Back in July, we talked about adding Registry Key/Value pairs and hashes to= the main IODEF document (trying to see if this will help Chris below). Wh= at if we added the Registry Key/Value pairs as a class off of RecordData, u= sing a similar structure to what is in RFC5901, and also added the ability = to include hashes in RecordData? I think if we then had the indicator_uid = at the RecordData level, we could connect a set within that structure and r= epeat the structure for other sets in the same way we would do with Node in= side of the System class, using the indicator_uid to tie the set together. = Then at the more specific level for the hash, registry Key/value, IP, etc.= use an indicator_uid if we needed them marked at this level as well? Mayb= e we want indicator_set at the higher level? I'd like some opinions on thi= s approach. +1 if you agree, suggestions if you have other ideas that may = work better. We'll also need to worry about marking the indicators to prevent forward sh= aring when not permitted. We may want to use these values or something els= e. Thank you! Kathleen From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs I think we have a bigger relationship issue to address. Let use the Watchli= st Use Case. A bunch of indicators are sent in one message. In that message= we could have groupings of indicators that we need to show are related: Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses.= Either or both may be present to indicate a compromise. Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is p= resent it is a compromise indicator but both will not be present. The problem compounds itself very quickly. Consider the scenario where both= groupings above are part of the same threat. I need to show that logical g= roupings of Indicators are related as well. We can't send multiple IODEF me= ssages for this from what I remember reading. The last one I can think of would be when you have 2 different indicators t= hat represent the same indicator. It's not uncommon to send both the MD5 an= d SHA1 hash of a malicious file. The indicator is the file but the IOCs are= the 2 hash values. How do we show they are related? If we use a unique Ini= dcator ID for each hash value there needs to be a higher level grouping. Thoughts? Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs All - I'd like your input and will refocus the thread to get opinions from the li= st on options to help solve the problems raised in my message and additiona= lly in Paul's message. Interesting point, C. Henry. Our objective here is to have machine automat= ed exchanges, so we rely on encryption rather than obfuscation to achieve t= he necessary level of confidentiality. Paul mentioned the need to distinguish indicators of compromise from contex= t information that may also include IP address or other data that could be = indicators. The question I raised was on how to connect sets of indicators= in the same IODEF document, assuming the ability to have watchlists that c= ould have several sets of indicators included, as well as to connect indica= tors that may be included in embedded schemas. If we add an attribute on all of the relevant indicators, let's say 'indica= tor-uid' how do we mark the indicators? Do we use this to mark who sent th= e indicator as well so that we can prevent forward sharing when it is not p= ermitted or handle that separately? Then for indicators not included in the base schema that may not fit into a= category in the SCI draft, do we create a place for these off of SCI or ri= ght off of the IODE schema in EventData? (more details on this in my first = message). Comments and questions encouraged to figure out the right technical solutio= n to have this machine automatable. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of C. Henry = Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs Temporal Dependency sounds interesting. I remember when I first ran across= this particular craft, an experienced colleague asked me a peculiar questi= on. He said, " How do you stop someone from tracking the IP Address to you= r computer?" I replied, "I don't know, how?" Then he said, "Cut the dog-gone thing off and the modem that it is connect= ed- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder search= ing a Neighborhood for Survivors which were hit by a Disaster or let's just= say "Live" Terrorist Situation. He /or She needs to communication back to= other Officials that he /or somehow is in Danger. The device used to comm= unicate has been captured by the great minds of the enemy. It's only a mat= ter of time before they utilize reverse engineering to figure out how it fu= nctions. However, their pride comes before a fall when seeking the locatio= n of other similar devices to attack. Why? Perhaps the less thought of con= cepts that makes the device function properly, saves the day by disguise or= cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell > wrote: From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temp= oral Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: > Serialization of a particular Lists of XML Classes in a unique way was cl= osely related to what I attempted to express when I stated, "consider to a = degree what appears to be illogical in brilliant minds in some instances." > > However, I see Dr. Stoecker's point a little clearer. However, it would = be nice if the UID was in some way disguised from those who study this Secu= rity Art Form in a negative way. > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > > Re: [mile] IOCs > > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > > To: > "mile@ietf.org" > > I would like to look at this from a slightly different perspective=A9let'= s > say I get an XML document that tells me about an incident. This document > has source IP and destination IP that is being shared. However, what I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing to > tell me which IP is the one, even if the roles are set it still might not > be enough to tell my system which one I should use as the indicator. > > If we had something like indicator_id as an attribute, it would allow us > to easily identify indicators from contextual data. I do admit to being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make it > very clear what the indicators are in the XML document and the other data > that may be important as I investigate activity that I have detected off > of those indicators. > > > I did suggest the detection class, but I think we may get more flexibilit= y > with the indicator_uid. One thing that I haven't considered is the UID > portion of this=A9how do we use that UID? How is the UID created? Are > there standards for UIDs? > > Regards, > > Paul > > > > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM > > Greetings Kathleen, > > Your logic stimulates my visionary brain because I'm amazed at the many a= venues you review with this approach at once. However, could you share a = few advantages and disadvantages to the latter? > > -------------------------------------------------------------------------= ------------------------------------------------- > "we could continue to group items in logical places as is done now in IOD= EF and then have the extension point for combined indicators via SCI." > > -------------------------------------------------------------------------= ------------------------------------------------ > > You pointed out what you consider to be logical places, but if I wanted t= o protect information from parties capable of ascertaining it from your log= ical places, perhaps we should also consider to a degree what appears to be= illogical in brilliant minds in some instances. > > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" >, "mile@ietf.org" > > Date: Saturday, January 26, 2013, 10:13 AM > > Hello C. Henry & others, > > Thanks for taking a look at this. We have a few considerations in this e= mail thread I would like to hear thoughts on (and there may be more once RF= C5070-bis is actively edited). > > The AdditionalData class and the RecordItem class both allow for non-XML = extensions. Where you place the extensions should be specific to the logic= al grouping of the parent elements so you can understand more about the inc= luded data in most cases. > > The Impact class can be used to provide context information on the includ= ed data of the report and also can include a confidence rating on the repor= t as a whole. Extensions related to impact would be one level higher (at t= he moment) in the Assessment class using the AdditionalData extension point= . > > Take asked about including vulnerability information, I would think that = would fit under the Vulnerability extension point of the SCI draft in the M= ethod class. He did ask about non-XML. RecordItem or AdditionalData do al= low for non-XML extension points, we could either have the SCI draft handle= these as well or have the extensions that are non-XML come directly off th= e AdditionalData or RecordItem classes according to what makes sense from a= logical standpoint. > > As for my question, it was two-fold. > > Indicator based schemas have a reference number or a GUID for the various= indicators they share. If we are extending to embed other schemas that in= clude such reference or GUID identifiers, do we want to add an attribute to= the various elements in IODEF that could be indicators? Is this enough to= make the connections or is something else else needed? We could add somet= hing like an Indicator_ID in RFC5070-bis which would then correlate to the = reference or GUID identifiers. > > Then the other question was on how to include indicators that are not in = the base schema that may be related or have language with "and" "or" to spe= cify the relationships. In some cases, you will want to group these indict= ors in one extension point, where they may fit logically in multiple places= if the relationships did not need to be shown in the data format. If we h= ave cases like this where you need more complex representations, should we = use one extension point via the SCI draft off of the EventData class Additi= onalData extension point? Opinions are needed here.... > > A few people have mentioned wanting to include some commonly shared indic= tors into the base IODEF document. We could have a catch-all class that do= es this and has an extension point off of it in EventData or we could conti= nue to group items in logical places as is done now in IODEF and then have = the extension point for combined indicators via SCI. I think I like the la= tter approach. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile= -bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs > > Greetings Everyone, > > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the SCI's > EventReport class, IMHO. > > 2) If the indicators are something like an non-XML ones, I guess it could= be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey the > indicators. > We could for instance extend the list of indicators of the Impact class, = if > needed. > -------------------------------------------------------------------------= ----------------------------- > > In doing so he pointed out the "Impact Class" > > Whereas, Kathleen stated, > > -------------------------------------------------------------------------= ---------------------------- > For the discussion below, I was thinking more of combined set with relati= onships that may be included in a single extension point, so that's why I w= as thinking about the EventData class, but there may be better locations or= a specific area within the EventData. > > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --------------------------- > > Kathleen thoughts related yet still with other indicators and the EventDa= ta Class. > > Is there a possible way to create a new XML class which encompass combini= ng the EventData, Detection and base IODEF classes to simplify this issue? > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Ema= il) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A3FMX15Acorpemccom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Others on= the list, please chime in to help on this issue and the possible solutions= (agreement or disagreement on approaches).

 

Paul & others, if we have an indicator group id, (let’s say indi= cator_set_id) =A0and an indicator unique id (indicator_uid), we might use t= he indicator_set_id to mark a set and connect a set within an IODEF documen= t as well as between other XML documents.=A0 If we do that, then is the ind= icator_uid helpful?=A0 I think it could be if we use that to mark where the= indicator originated in some way that we also know how it can be used and = if it can be shared forward marked at an indicator level (in addition to th= e sharing group in RID for the whole document or set of documents shared).<= o:p>

 

What would this look like?<= /p>

 

How about the following where you use the set marker at class l= evel for each of the classes that includes indicators or important context = on those indicators:

 

=A0=A0 +------------------+<= /p>

=A0=A0 | EventData=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0 +------------------+

=A0=A0 | ENUM restri= ction |<>--{0..*}--[ Description=A0=A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0.= .1}--[ DetectTime=A0=A0=A0=A0 ]

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0 |=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..1}--[ StartTime= =A0=A0=A0=A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..1}--[ EndTime=A0=A0=A0=A0=A0= =A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0=A0=A0|<>--{0..*}--[ Contact=A0=A0=A0=A0=A0=A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |<>--{0..1}--[ Assessment=A0=A0=A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>= ;--{0..*}--[ Method=A0=A0=A0=A0=A0=A0=A0=A0 ]

=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..*}-= -[ Flow=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ]

=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..*}--[ Ex= pectation=A0=A0=A0 ]

=A0 =A0|=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..1}--[ Record=A0=A0=A0=A0= =A0=A0=A0=A0 ]

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 |<>--{0..*}--[ EventData=A0=A0=A0=A0=A0 ]=

=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |<>--{0..*}--[ AdditionalData ]

 

Since you could= use the nested EventData instance to include the full set, you would need = indicator_set_id as an attribute to the EventData class.=A0 Then Since you = can have many of the classes from the above directly in the Incident class,= the ones that contain indicators would also need the capability to mark or= connect a set of indicators.=A0 That includes:

 

Method -> Reference (Set at the Reference class so you can tie Refere= nces to specific indicator sets if there are multiple).

Flow -> System=A0 ( I think the set should= start at the System class level, maybe at the Flow too),

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0the node should be kept to a single Node that may be represented in m= any ways, but

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0I think we should add categories to Sy= stem so we can have a watchlist at that level

=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0without n= eeding many instances of EventData (thoughts)?=A0 This would just work=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 when the Service and OperatingSystem information matched ac= ross the watchlist

=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 or when that data was omitted.=

Record -> RecordData (at th= e RecordData class, where we may add Registry Key/value pairs and file hash= es)

 

Context: Contact, Expectation, DetectTime= , StartTime, and EndTime

<= o:p> 

By having this at th= e Assessment and Expectation classes, you can set the recommended actions a= nd confidence levels at the indicator set level.=A0 You could alternatively= do this by adding more attributes to the individual indicator element/clas= ses.

 

Then the Node, Address, NodeName, Applic= ation, other added indicators (registry key/value pairs, hashes, etc.) =A0w= ould need the indicator_uid (if this is helpful).

 

 

As Paul mentio= ned, you could have groupings in a new class, but we would need to be able = to include all the types of indicators, so it may be complex to have more r= epresentation options for the same types of indicators.=A0 Would the above = build in the additional flexibility that is needed or what would the propos= ed Detection class look like in case it is a better option?

 

Thanks!
Kathleen

 

= From:= Stoecker, Paul
Sent: Sunday, February 03, 2013 8:26 PM
To= : Moriarty, Kathleen; Harrington, Christopher; MILE IETF
Subject:= Re: [mile] IOCs

=  

What if we added i= ndicator group ID along with the indicator_uid?  This would allow you = to group indicators that are related into the same group ID.  Would th= is resolve the issue?

=  

It is= either that or going back to adding a Detection (or Indicators) class that= will should be used to take all of the indicators put them into one place = and have the ability to group the ones that go together.  I don't mean= a place to put indicators that are missing from IODEF…I mean a place= in the IODEF document where you put the indicators that are used for detec= tion and prevention of the shared Incident.  I don't know the answer h= ere, but there has got to be a good way for indicators to be identified and= being able to group them as Chris has suggested without basically recreati= ng something complicated like STIX.

 

Paul

 

 

Paul W. Stoe= cker, Ph.D.

SMC Lead Content Architect=

RSA, The Security Division of EMC

cell: 302.379.3375 | e: paul.stoecker@rsa.com

&= nbsp;

 

From: = <Moriarty>, Kathleen <kathleen.moriarty@emc.com>
Date: Sunday, = February 3, 2013 5:11 PM
To: "Harrington, Christopher" = <Christopher.Harringto= n@emc.com>, MILE IETF <mile@ietf= .org>
Subject: Re: [mile] IOCs

=

 

=

Hi Chris,

 

I agree, we = have some work to do in the updated IODEF, RFC5070-bis.

 

The list has already said they would like to see indicators added t= o the definitions in RFC5070-bis, to be more explicit about including indic= ators and sets of indicators in IODE documents as opposed to ‘parts o= f an incident or the useful information on an incident for sharing purposes= .  It was written before we used terms like indicators.  With tha= t in mind, Rosella proposed a number of changes back in July, both for guid= ance and for format updates.  It may help to have the first draft try = to address at least some of these issues so people can understand the probl= ems and at least a proposed solution.

 

As you point= out, we need to be able to show relationships between sets of indicators, = where we may have a few sets of indicators that could have a relationship t= o each other within a document.  In the July presentation, one of the = questions was to see if we should add new category attribute values for the= System class that would connect the list of included indicators.  I t= hink we should still keep the concept of a Node to a single node, but perha= ps within System, list multiple sets of Nodes that may be one type of attac= k.  Rosella had suggested pulling forward the “FraudType” = from RFC5901, this would help solve the issue as NodeRole values would comp= liment an AttackType (FraudType values could be included in AttackType or s= ome broader term).  It may be better to have the FraudTypes, plus attr= ibute values like “C2-server”, “sinkhole”,  &#= 8220;MalwareDistribution” for added context so you know what to do wi= th the received set of indicators.<= /o:p>

 

I am proposing = that we change IODEF to include multiple sets of indicators, add an AttackT= ype attribute (or some other name), a method to connect indicators and indi= cator sets within an IODEF using an attribute of indicator_uid (or some oth= er name) with a string value to make the connection points, and add a few i= ndicators that are commonly shared into the base IODEF.

 

Back in July, we talked about adding Registry Key/Value pairs and h= ashes to the main IODEF document (trying to see if this will help Chris bel= ow).  What if we added the Registry Key/Value pairs as a class off of = RecordData, using a similar structure to what is in RFC5901, and also added= the ability to include hashes in RecordData?  I think if we then had = the indicator_uid at the RecordData level, we could connect a set within th= at structure and repeat the structure for other sets in the same way we wou= ld do with Node inside of the System class, using the indicator_uid to tie = the set together.  Then at the more specific level for the hash, regis= try Key/value, IP, etc. use an indicator_uid if we needed them marked at th= is level as well?  Maybe we want indicator_set at the higher level?&nb= sp; I’d like some opinions on this approach.  +1 if you agree, s= uggestions if you have other ideas that may work better.

 

We’ll also need to worry about marking the indicators to prev= ent forward sharing when not permitted.  We may want to use these valu= es or something else.  <= /span>

 

Thank you!
Kathlee= n 

 

From: Harr= ington, Christopher
Sent: Friday, February 01, 2013 12:01 PM
= To: Moriarty, Kathleen; MILE IETF
Subject: RE: [mile] IOCs=

 

I think we have a bigger relationship issue to addr= ess. Let use the Watchlist Use Case. A bunch of indicators are sent in one = message. In that message we could have groupings of indicators that we need= to show are related:<= /p>

 

Two or more indicators of di= fferent type that relate to the same threat:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>The file hash of a malicious file and the URL of the C2 that the file= uses. Either or both may be present to indicate a compromise.

&n= bsp;

Two or more indicators of the same type that relate to the sa= me threat:

2 different registry values= for the same registry key. If either value is present it is a compromise i= ndicator but both will not be present. <= o:p>

 

The prob= lem compounds itself very quickly. Consider the scenario where both groupin= gs above are part of the same threat. I need to show that logical groupings= of Indicators are related as well. We can’t send multiple IODEF mess= ages for this from what I remember reading.

 

The = last one I can think of would be when you have 2 different indicators that = represent the same indicator. It’s not uncommon to send both the MD5 = and SHA1 hash of a malicious file. The indicator is the file but the IOCs a= re the 2 hash values. How do we show they are related? If we use a unique I= nidcator ID for each hash value there needs to be a higher level grouping. =

 

Thoughts?

 =

Thanks,<= o:p>

 

--Chris<= /span>

 

Christopher Harrington

Consulting Securit= y Engineer

GSO - Critical Incident Response Center

EMC = - Where Information Lives

174 Middlesex Turnpike

Bedford,= MA 01730

781-515-5862 (work)<= o:p>

603-583-1585 (cell)=

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mo= riarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
T= o: MILE IETF
Subject: Re: [mile] IOCs

 

= All –

 <= /span>

I’d like your input and will re= focus the thread to get opinions from the list on options to help solve the= problems raised in my message and additionally in Paul’s message.

=  

Interesting point, C. Henry.  Our objective her= e is to have machine automated exchanges, so we rely on encryption rather t= han obfuscation to achieve the necessary level of confidentiality.

 

Paul mentioned the need to distinguish indicators of compr= omise from context information that may also include IP address or other da= ta that could be indicators.  The question I raised was on how to conn= ect sets of indicators in the same IODEF document, assuming the ability to = have watchlists that could have several sets of indicators included, as wel= l as to connect indicators that may be included in embedded schemas.=

 

If we add an attribute on all of the relevant indicator= s, let’s say ‘indicator-uid’ how do we mark the indicator= s?  Do we use this to mark who sent the indicator as well so that we c= an prevent forward sharing when it is not permitted or handle that separate= ly? 

 

Then for indicators not included in the= base schema that may not fit into a category in the SCI draft, do we creat= e a place for these off of SCI or right off of the IODE schema in EventData= ? (more details on this in my first message).

 

Comm= ents and questions encouraged to figure out the right technical solution to= have this machine automatable.

 

Thank you,<= span style=3D'color:black'>

Kathleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On= Behalf Of C. Henry Adams & BIE
Sent: Monday, January 28,= 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

 

Temporal Depe= ndency sounds interesting.  I remember when I first ran across this pa= rticular craft, an experienced colleague asked me a peculiar question. = ; He said, " How do you stop someone from tracking the IP Address to y= our computer?" 

I replied, "I don't know, how?"=

Then he said, "Cut the dog-gone thing off  and the modem= that it is connected- which is constantly on!"   LOL
Here's my point (Hypothetical Situation) :  There is a 1st Responder = searching a Neighborhood for Survivors which were hit by a Disaster or let'= s just say "Live" Terrorist Situation.  He /or She needs to = communication back to other Officials that he /or somehow is in Danger.&nbs= p; The device used to communicate has been captured by the great minds of t= he enemy.  It's only a matter of time before they utilize reverse engi= neering to figure out how it functions.  However, their pride comes be= fore a fall when seeking the location of other similar devices to attack.&n= bsp; Why? Perhaps the less thought of concepts that makes the device functi= on properly, saves the day by disguise or cutting it off (figuratively spea= king).

Just a visionary thought.

C. Henry Adams
chenryadams@biemediagroup.comhttp://biemediagroup.com

<= br>The information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited.

--- On Mon, 1/28= /13, Dave Misell <david.misel= l@bcs.org> wrote:


From: Dave Misell <david.misell@bcs.org>
Subject: Re: [mile] IOCsTo: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Date: Monday, January 28, 201= 3, 9:25 PM

UID could be mirrored with DNS SEC a pemanent and temporal key, with= a temporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
Si= lentCircle  dsm
07710 380044
david.misell@bcs.org


On 29 Jan 2013, at 00:39= , C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote:

> Serialization of a = particular Lists of XML Classes in a unique way was closely related to what= I attempted to express when I stated, "consider to a degree what appe= ars to be illogical in brilliant minds in some instances."
> > However, I see Dr. Stoecker's point a little clearer.  However, = it would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way.
>
> C. Henry Adams> chatlga2000@yahoo= .com (Direct Email)
> chenryadams@biemediagroup.com
>
>
>= The information contained herein is for the exclusive use of the original = recipient. This information is granted for limited distribution within the = recipient's place of business for planning purposes only. Further dissemina= tion, whether private or public is prohibited.
>
> Re: [mile] = IOCs
>
> Sunday, January 27, 2013 8:52 PM
> From:
>= ; "Stoecker, Paul" <Paul.Stoecker@rsa.com>
> To:
> "mile@ietf.org" <mile@ietf.org>
> I would like to = look at this from a slightly different perspective=A9let's
> say I ge= t an XML document that tells me about an incident.  This document
&= gt; has source IP and destination IP that is being shared.  However, w= hat I
> don't know is which IP address is my indicator and which is j= ust a
> contextual piece of information.  This means that my det= ection product
> isn't going to know which one to use either, because= there is nothing to
> tell me which IP is the one, even if the roles= are set it still might not
> be enough to tell my system which one I= should use as the indicator.
>
> If we had something like ind= icator_id as an attribute, it would allow us
> to easily identify ind= icators from contextual data.  I do admit to being
> biased as I= have spent much of my career working on the monitoring and
> detecti= on side of these things, so I am just thinking of ways to make it
> v= ery clear what the indicators are in the XML document and the other data> that may be important as I investigate activity that I have detected = off
> of those indicators.
>
>
> I did suggest th= e detection class, but I think we may get more flexibility
> with the= indicator_uid.  One thing that I haven't considered is the UID
>= ; portion of this=A9how do we use that UID?  How is the UID created?&n= bsp; Are
> there standards for UIDs?
>
> Regards,
>= ;
> Paul
>
>
>
> Paul W. Stoecker, Ph.D.<= br>> SMC Lead Content Architect
> RSA, The Security Division of EM= C
> cell: 302.379.3375 | e: paul.stoecker@rsa.com
>
> --- On Sat, 1/26/13, C= . Henry Adams & BIE <chatlga2000@yahoo.com> wrote:
>
> From: C. Henry Ad= ams & BIE <chatlg= a2000@yahoo.com>
> Subject: RE: [mile] IOCs
> To: "= KathleenMoriarty" <kathleen.moriarty@emc.com>
> Cc: mile@ietf.org
> Date: Saturday, January 26, = 2013, 6:17 PM
>
> Greetings Kathleen,
>
> Your lo= gic stimulates my visionary brain because I'm amazed at the many avenues yo= u review with this approach at once.  However,  could you share a= few advantages and disadvantages to the latter?
>
> ---------= ---------------------------------------------------------------------------= --------------------------------------
> "we could continue to g= roup items in logical places as is done now in IODEF and then have the exte= nsion point for combined indicators via SCI."
>
> -------= ---------------------------------------------------------------------------= ---------------------------------------
>
> You pointed out wh= at you consider to be logical places, but if I wanted to protect informatio= n from parties capable of ascertaining it from your logical places, perhaps= we should also consider to a degree what appears to be illogical in brilli= ant minds in some instances.
>
>
>
> C. Henry Ad= ams
> chatlga2000@= yahoo.com (Direct Email)
> chenryadams@biemediagroup.com
>
> The= information contained herein is for the exclusive use of the original reci= pient. This information is granted for limited distribution within the reci= pient's place of business for planning purposes only. Further dissemination= , whether private or public is prohibited.
>
> --- On Sat, 1/2= 6/13, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:
>
> From: Mo= riarty, Kathleen <kathleen.moriarty@emc.com>
> Subject: RE: [mile] IOCs
>= To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org" <mile@ietf.org>
> Date: Saturday, Januar= y 26, 2013, 10:13 AM
>
> Hello C. Henry & others,
> =
> Thanks for taking a look at this.  We have a few consideratio= ns in this email thread I would like to hear thoughts on (and there may be = more once RFC5070-bis is actively edited).
>
> The AdditionalD= ata class and the RecordItem class both allow for non-XML extensions. = Where you place the extensions should be specific to the logical grouping = of the parent elements so you can understand more about the included data i= n most cases. 
>
> The Impact class can be used to provi= de context information on the included data of the report and also can incl= ude a confidence rating on the report as a whole.  Extensions related = to impact would be one level higher (at the moment) in the Assessment class= using the AdditionalData extension point. 
>
> Take ask= ed about including vulnerability information, I would think that would fit = under the Vulnerability extension point of the SCI draft in the Method clas= s.  He did ask about non-XML.  RecordItem or AdditionalData do al= low for non-XML extension points, we could either have the SCI draft handle= these as well or have the extensions that are non-XML come directly off th= e AdditionalData or RecordItem classes according to what makes sense from a= logical standpoint.
>
> As for my question, it was two-fold.<= br>>
> Indicator based schemas have a reference number or a GUID = for the various indicators they share.  If we are extending to embed o= ther schemas that include such reference or GUID identifiers, do we want to= add an attribute to the various elements in IODEF that could be indicators= ?  Is this enough to make the connections or is something else else ne= eded?  We could add something like an Indicator_ID in RFC5070-bis whic= h would then correlate to the reference or GUID identifiers.
>
&g= t; Then the other question was on how to include indicators that are not in= the base schema that may be related or have language with "and" = "or" to specify the relationships.  In some cases, you will = want to group these indictors in one extension point, where they may fit lo= gically in multiple places if the relationships did not need to be shown in= the data format.  If we have cases like this where you need more comp= lex representations, should we use one extension point via the SCI draft of= f of the EventData class AdditionalData extension point?  Opinions are= needed here....
>
> A few people have mentioned wanting to i= nclude some commonly shared indictors into the base IODEF document.  W= e could have a catch-all class that does this and has an extension point of= f of it in EventData or we could continue to group items in logical places = as is done now in IODEF and then have the extension point for combined indi= cators via SCI.  I think I like the latter approach.
>
> = Thank you,
> Kathleen
> _______________________________________= _
> From: mile-bou= nces@ietf.org [mile-= bounces@ietf.org] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com]
> Sen= t: Saturday, January 26, 2013 3:05 AM
> To: mile@ietf.org
> Cc: C. Henry Adams
> Subj= ect: Re: [mile] IOCs
>
> Greetings Everyone,
>
> = Take mentioned two types of indicators based on the :
> -------------= ---------------------------------------------------------------------------= --------------
> 1) If the indicators are something like an XML-based= alert/warning of
> information leakage, it could be an event that ar= e conveyed in the SCI's
> EventReport class, IMHO.
>
> 2= ) If the indicators are something like an non-XML ones, I guess it could be=
> conveyed without using SCI draft.
> For instance, we could u= se Impact class of the base IODEF to convey the
> indicators.
>= We could for instance extend the list of indicators of the Impact class, i= f
> needed.
> -------------------------------------------------= -----------------------------------------------------
>
> In d= oing so he pointed out the "Impact Class"
>
> Wherea= s, Kathleen stated,
>
> --------------------------------------= ---------------------------------------------------------------
> For= the discussion below, I was thinking more of combined set with relationshi= ps that may be included in a single extension point, so that's why I was th= inking about the EventData class, but there may be better locations or a sp= ecific area within the EventData.
>
> Paul Stoecker had sugges= ted a "Detection" class as a consideration.
> -------------= ---------------------------------------------------------------------------= ------------
>
> Kathleen thoughts related yet still with othe= r indicators and the EventData Class.
>
> Is there a possible = way to create a new XML class which encompass combining the EventData, Dete= ction and base IODEF classes to simplify this issue?
>
>
&= gt; C. Henry Adams
> chatlga2000@yahoo.com (Direct Email)
> chenryadams@biemediagroup.com
&g= t;
>
> The information contained herein is for the exclusive = use of the original recipient. This information is granted for limited dist= ribution within the recipient's place of business for planning purposes onl= y. Further dissemination, whether private or public is prohibited.
> = _______________________________________________
> mile mailing list> mile@ietf.org
>= h= ttps://www.ietf.org/mailman/listinfo/mile

 

= --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A3FMX15Acorpemccom_-- From chatlga2000@yahoo.com Mon Feb 4 11:04:34 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB70521F89A4 for ; Mon, 4 Feb 2013 11:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[AWL=1.796, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZkBcwGOTl15 for ; Mon, 4 Feb 2013 11:04:34 -0800 (PST) Received: from nm11-vm3.bullet.mail.ne1.yahoo.com (nm11-vm3.bullet.mail.ne1.yahoo.com [98.138.91.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1003621F899E for ; Mon, 4 Feb 2013 11:04:34 -0800 (PST) Received: from [98.138.226.178] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 19:04:33 -0000 Received: from [98.138.226.164] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 19:04:33 -0000 Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 19:04:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 524592.62172.bm@omp1065.mail.ne1.yahoo.com Received: (qmail 4059 invoked by uid 60001); 4 Feb 2013 19:04:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360004673; bh=YG7eK2kNBZla/ERRGxthhcf6PidQ7Pbr8PHHLLQkNFE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=k5oBCvGH6Hx2RyzocFIO/1tTH9LKGXOhjtBAowczDhQnryZbvcQfbLsNJ3XBG6WIJwXJ05f627p4BiXeGkK4hPHkdRjyOColy/gS3hrKT3lhEeVP9HZzWVsQz9cpXUmk9C2PYHFXFAx63G16kFG6KUNm+dKpYOfp4Ak35SolwUY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=u3zXcEQ1fVuDmOE/Itv5egfJlyL7RbB67MJisFcZMYVZ384a7DWTExxdBaD/E6sQYobY7yUBMFXJD/MIcsHBs1vr+P0yzGGS6Ze23SfXbEFL2Z9MDCmRGBgTCrd57aDzsgktsO+u/TiqazDHXjq1LTcDqgxJ2ixGwbv2Zc8TLr8=; X-YMail-OSG: gZT3R5AVM1lpY07acroKFIqBWSX.0vKc0bez61yXs.4KyQ2 jzdsgdoXOWXJq03Li.wIHFISNO7WUkj4e0yZ2bgrPz4eOWeaBq9sAqCBJb0T e60HbqF1MP_4OrMSL_qPZNtNx8FAbFxEdGtc1IC4a9euUKfnJwCkSuR7FBv3 Mol.mCyBwAe2UfKPQPQpt1NvXnpxXy2xB6537EoZYOaxIiV7gn_tbofShYTQ ftsP5F_3kvh7NezNC6lMQM49.sSYg5CZ59anF.kbn2CloFoQByaFKHNqxlkd nLT0nIU1kSMOQSDrTCcnwB3EuNI3B4rxk7ny3zgYnHG4CFPw.smsYYtMM2Mq AdCK1A9hKB.ch6Nsk_.ZZ2tgHGRSV2zvYJu81i35MfTvH7Z0u8lYgT3tQlYv G3.DNUjh9Hq7nB8euFHox0opiO16fM_lMTVROcHmQsnd3E13IaslxmdTwRtz NkB2TJ995d.8pDaoqFJFRdK6EzyO1WgQT2YO4j_us_4YfDMlrMLjaaWLEi2q k84GeLPH_0VduYjap0lYGqGIUSedX3nylurbwnGQ0z1Edl2XC995otqxFxk8 Erk_hhqUk3L8- Received: from [71.22.243.36] by web121605.mail.ne1.yahoo.com via HTTP; Mon, 04 Feb 2013 11:04:33 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEFsbCwNCg0KSSB3YXMgc3VycHJpc2VkIHRvIHNlZSB0aGUgRGlnZXN0IGxhdGUgaW4gdGhlIGFmdGVybm9vbiBhZnRlciByZXBseWluZyBiYWNrIHRvIEVyaWMgJiBLYXRobGVlbidzIGVtYWlscyBNb25kYXkgYW5kIFN1bmRheSBwcm9zcGVjdGl2ZWx5Lg0KDQpGdXJ0aGVybW9yZSwgSSdtIGxpdHRsZSBjb25mdXNlZC7CoCBTdW5kYXkgRXZlbmluZywgS2F0aGxlZW4gYXNrZWQgbWUgdG8gbGVhdmUgb3V0IGN5YmVyIHNlY3VyaXR5IHJlbGF0ZWQgZGlzY3Vzc2lvbnMsIGJ1dCB0aGlzIG1vcm4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.132.503 Message-ID: <1360004673.90810.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Mon, 4 Feb 2013 11:04:33 -0800 (PST) From: "C. Henry Adams & BIE" To: mile@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2053635335-963227600-1360004673=:90810" Cc: "C. Henry Adams" Subject: [mile] "MILE IETF" X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:04:35 -0000 --2053635335-963227600-1360004673=:90810 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Greetings All, I was surprised to see the Digest late in the afternoon after replying back= to Eric & Kathleen's emails Monday and Sunday prospectively. Furthermore, I'm little confused.=A0 Sunday Evening, Kathleen asked me to l= eave out cyber security related discussions, but this morning Eric has chan= ged the thread. Great!=A0 I'm a believer in unorthodox approaches to solving problems, plea= se allow us 24 to 48 hours to come up with a good scenario that fits.=A0 I = was running out of the office when I saw the digest. Thanks, C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0Ahttp://biemediagroup.com =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. --2053635335-963227600-1360004673=:90810 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings All,

I was surprised to see = the Digest late in the afternoon after replying back to Eric & Kathleen= 's emails Monday and Sunday prospectively.

Furthermore, I'm little c= onfused.  Sunday Evening, Kathleen asked me to leave out cyber securit= y related discussions, but this morning Eric has changed the thread.
Great!  I'm a believer in unorthodox approaches to solving problems, = please allow us 24 to 48 hours to come up with a good scenario that fits.&n= bsp; I was running out of the office when I saw the digest.

Thanks,<= br>
C. Henry Adams
=0Achatlga2000@yahoo.com (Direct Email)
=0Achen= ryadams@biemediagroup.com
=0Ahttp://biemediagroup.com
=0A
=0AThe i= nformation contained herein is for the exclusive use of the original recipi= ent. This information is granted for limited distribution within the recipi= ent's place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
--2053635335-963227600-1360004673=:90810-- From kathleen.moriarty@emc.com Mon Feb 4 11:25:19 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7724421F89E9 for ; Mon, 4 Feb 2013 11:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqgqiSt9FksP for ; Mon, 4 Feb 2013 11:25:17 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF021F85A1 for ; Mon, 4 Feb 2013 11:25:15 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14JPD35007414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 14:25:13 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 4 Feb 2013 14:24:56 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14JOuP3031082; Mon, 4 Feb 2013 14:24:56 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Feb 2013 14:24:56 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Mon, 4 Feb 2013 14:24:55 -0500 From: "Moriarty, Kathleen" To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Mon, 4 Feb 2013 14:24:54 -0500 Thread-Topic: "MILE IETF" Thread-Index: Ac4DCoT90FpMCKrpR+yHx9NjNy0akgAAe0xA Message-ID: References: <1360004673.90810.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1360004673.90810.YahooMailClassic@web121605.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE9E2A71MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] "MILE IETF" X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:25:19 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A71MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi C. Henry, Please do follow up on the new thread Eric started if you have attack vecto= rs that we should be aware of on the MILE protocols. My message to you was= to ensure you understood that RFC5070 explicitly does not worry about secu= rity and leaves that up to RID and other protocol level exchange mechanisms= . Please do follow up on the new thread on attack vectors you see as possi= ble with the MILE protocol documents and we'll keep the IOC thread progress= ing so that we can set up methods to connect indicators within an IODEF doc= ument and between other data formats. Best regards, Kathleen From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] Sent: Monday, February 04, 2013 2:05 PM To: mile@ietf.org Cc: C. Henry Adams; Eric Burger; Moriarty, Kathleen Subject: "MILE IETF" Greetings All, I was surprised to see the Digest late in the afternoon after replying back= to Eric & Kathleen's emails Monday and Sunday prospectively. Furthermore, I'm little confused. Sunday Evening, Kathleen asked me to lea= ve out cyber security related discussions, but this morning Eric has change= d the thread. Great! I'm a believer in unorthodox approaches to solving problems, please= allow us 24 to 48 hours to come up with a good scenario that fits. I was = running out of the office when I saw the digest. Thanks, C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A71MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi C. Hen= ry,

 

Please do follow up on the new thread Eri= c started if you have attack vectors that we should be aware of on the MILE= protocols.  My message to you was to ensure you understood that RFC50= 70 explicitly does not worry about security and leaves that up to RID and o= ther protocol level exchange mechanisms.  Please do follow up on the n= ew thread on attack vectors you see as possible with the MILE protocol docu= ments and we’ll keep the IOC thread progressing so that we can set up= methods to connect indicators within an IODEF document and between other d= ata formats.

 

Best regards,<= /p>

Kathleen

 

= From:= C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]
Sent: M= onday, February 04, 2013 2:05 PM
To: mile@ietf.org
Cc: = C. Henry Adams; Eric Burger; Moriarty, Kathleen
Subject: "MI= LE IETF" <mile@ietf.org>

 

Greetings All,

I was surprised to see t= he Digest late in the afternoon after replying back to Eric & Kathleen'= s emails Monday and Sunday prospectively.

Furthermore, I'm little co= nfused.  Sunday Evening, Kathleen asked me to leave out cyber security= related discussions, but this morning Eric has changed the thread.

= Great!  I'm a believer in unorthodox approaches to solving problems, p= lease allow us 24 to 48 hours to come up with a good scenario that fits.&nb= sp; I was running out of the office when I saw the digest.

Thanks,
C. Henry Adams
chatlga200= 0@yahoo.com (Direct Email)
chenryadams@biemediagroup.com
http://biemediagroup.com

The information contained herein= is for the exclusive use of the original recipient. This information is gr= anted for limited distribution within the recipient's place of business for= planning purposes only. Further dissemination, whether private or public i= s prohibited.

 

= --_000_F5063677821E3B4F81ACFB7905573F24CE9E2A71MX15Acorpemccom_-- From Christopher.Harrington@emc.com Mon Feb 4 11:25:38 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9238D21F85A1 for ; Mon, 4 Feb 2013 11:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.134 X-Spam-Level: ** X-Spam-Status: No, score=2.134 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEishMKmVyLT for ; Mon, 4 Feb 2013 11:25:25 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F229E21F8A67 for ; Mon, 4 Feb 2013 11:25:23 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14JPMUB007548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2013 14:25:23 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Mon, 4 Feb 2013 14:25:13 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r14JPCN0015008 for ; Mon, 4 Feb 2013 14:25:12 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 4 Feb 2013 14:25:11 -0500 From: "Harrington, Christopher" To: "Stoecker, Paul" , "Moriarty, Kathleen" , MILE IETF Date: Mon, 4 Feb 2013 14:25:10 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4Cdpmb1RU1c3enRUyj7UuiUQgqBQAZqt+Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01C2_01CE02E3.6F6C8DE0" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:25:38 -0000 ------=_NextPart_000_01C2_01CE02E3.6F6C8DE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01C3_01CE02E3.6F6C8DE0" ------=_NextPart_001_01C3_01CE02E3.6F6C8DE0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I think some sort of group ID would do the trick. We also need a logical = and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have = the same group ID since they are related.=20 =20 Thanks, --Chris =20 From: Stoecker, Paul=20 Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs =20 What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group = ID. Would this resolve the issue? =20 It is either that or going back to adding a Detection (or Indicators) = class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't = mean a place to put indicators that are missing from IODEF.I mean a place in = the IODEF document where you put the indicators that are used for detection = and prevention of the shared Incident. I don't know the answer here, but = there has got to be a good way for indicators to be identified and being able = to group them as Chris has suggested without basically recreating something complicated like STIX. =20 Paul =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com =20 =20 From: , Kathleen Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" , MILE = IETF Subject: Re: [mile] IOCs =20 Hi Chris, =20 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =20 The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to 'parts of an = incident or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, = Rosella proposed a number of changes back in July, both for guidance and for = format updates. It may help to have the first draft try to address at least = some of these issues so people can understand the problems and at least a proposed solution. =20 As you point out, we need to be able to show relationships between sets = of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, = one of the questions was to see if we should add new category attribute = values for the System class that would connect the list of included indicators. = I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type = of attack. Rosella had suggested pulling forward the "FraudType" from = RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some = broader term). It may be better to have the FraudTypes, plus attribute values = like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. =20 I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared = into the base IODEF. =20 Back in July, we talked about adding Registry Key/Value pairs and hashes = to the main IODEF document (trying to see if this will help Chris below). = What if we added the Registry Key/Value pairs as a class off of RecordData, = using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid = at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with = Node inside of the System class, using the indicator_uid to tie the set = together. Then at the more specific level for the hash, registry Key/value, IP, = etc. use an indicator_uid if we needed them marked at this level as well? = Maybe we want indicator_set at the higher level? I'd like some opinions on = this approach. +1 if you agree, suggestions if you have other ideas that may work better. =20 We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or = something else. =20 =20 Thank you! Kathleen =20 =20 From: Harrington, Christopher=20 Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =20 I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show are related: =20 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise.=20 =20 Two or more indicators of the same type that relate to the same threat:=20 2 different registry values for the same registry key. If either value = is present it is a compromise indicator but both will not be present.=20 =20 The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple = IODEF messages for this from what I remember reading.=20 =20 The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It's not uncommon to send both the = MD5 and SHA1 hash of a malicious file. The indicator is the file but the = IOCs are the 2 hash values. How do we show they are related? If we use a = unique Inidcator ID for each hash value there needs to be a higher level = grouping.=20 =20 Thoughts? =20 Thanks, =20 --Chris =20 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =20 All -=20 =20 I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. =20 Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. =20 Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of = indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. =20 If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark = who sent the indicator as well so that we can prevent forward sharing when = it is not permitted or handle that separately? =20 =20 Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my = first message). =20 Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =20 Temporal Dependency sounds interesting. I remember when I first ran = across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP = Address to your computer?" =20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation. He /or She needs to communication = back to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's = only a matter of time before they utilize reverse engineering to figure out how = it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less = thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrote: > Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider = to a degree what appears to be illogical in brilliant minds in some = instances." >=20 > However, I see Dr. Stoecker's point a little clearer. However, it = would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different = perspective=A9let's > say I get an XML document that tells me about an incident. This = document > has source IP and destination IP that is being shared. However, what = I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing = to > tell me which IP is the one, even if the roles are set it still might = not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow = us > to easily identify indicators from contextual data. I do admit to = being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make = it > very clear what the indicators are in the XML document and the other = data > that may be important as I investigate activity that I have detected = off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more = flexibility > with the indicator_uid. One thing that I haven't considered is the = UID > portion of this=A9how do we use that UID? How is the UID created? = Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once. However, could you = share a few advantages and disadvantages to the latter? >=20 > -------------------------------------------------------------------------= --- ---------------------------------------------- > "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via = SCI." >=20 > -------------------------------------------------------------------------= --- --------------------------------------------- >=20 > You pointed out what you consider to be logical places, but if I = wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this. We have a few considerations in = this email thread I would like to hear thoughts on (and there may be more = once RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for = non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about = the included data in most cases. =20 >=20 > The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on = the report as a whole. Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point. =20 >=20 > Take asked about including vulnerability information, I would think = that would fit under the Vulnerability extension point of the SCI draft in = the Method class. He did ask about non-XML. RecordItem or AdditionalData = do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come = directly off the AdditionalData or RecordItem classes according to what makes = sense from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the = various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an = attribute to the various elements in IODEF that could be indicators? Is this = enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not = in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in = multiple places if the relationships did not need to be shown in the data format. = If we have cases like this where you need more complex representations, = should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI. I think I = like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= --- -------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the = SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it = could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey = the > indicators. > We could for instance extend the list of indicators of the Impact = class, if > needed. > -------------------------------------------------------------------------= --- -------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > -------------------------------------------------------------------------= --- ------------------------- > For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --- ------------------------ >=20 > Kathleen thoughts related yet still with other indicators and the EventData Class. >=20 > Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify = this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_01C3_01CE02E3.6F6C8DE0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I think some sort of group ID would do the trick. We also need a = logical and / or somewhere to show relationship between indicators. If I = give you 2 registry keys do they both have to be present to be an = indication of compromise or is either one by themselves an indicator? = Both would have the same group ID since they are related. =

 

Thanks,

--Chris

 

From:= = Stoecker, Paul
Sent: Sunday, February 03, 2013 8:26 = PM
To: Moriarty, Kathleen; Harrington, Christopher; MILE = IETF
Subject: Re: [mile] = IOCs

 

What if we added indicator group ID along with the indicator_uid? =  This would allow you to group indicators that are related into the = same group ID.  Would this resolve the = issue?

 

It is either that or going back to adding a Detection (or Indicators) = class that will should be used to take all of the indicators put them = into one place and have the ability to group the ones that go together. =  I don't mean a place to put indicators that are missing from = IODEF…I mean a place in the IODEF document where you put the = indicators that are used for detection and prevention of the shared = Incident.  I don't know the answer here, but there has got to be a = good way for indicators to be identified and being able to group them as = Chris has suggested without basically recreating something complicated = like STIX.

 

Paul

 

 

Paul W. Stoecker, Ph.D.

= SMC Lead Content Architect

R= SA, The Security Division of EMC

= cell: 302.379.3375 | e: paul.stoecker@rsa.com

<= p class=3DMsoNormal> 

 

From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com&g= t;
Date: Sunday, February 3, 2013 5:11 PM
To: = "Harrington, Christopher" <Christopher.Harrington@emc= .com>, MILE IETF <mile@ietf.org>
Subject: = Re: [mile] IOCs

 

Hi Chris,

 

I agree, we have some work to do in the updated IODEF, = RFC5070-bis.

 

The list has already said they would like to see indicators added to = the definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to = ‘parts of an incident or the useful information on an incident for = sharing purposes.  It was written before we used terms like = indicators.  With that in mind, Rosella proposed a number of = changes back in July, both for guidance and for format updates.  It = may help to have the first draft try to address at least some of these = issues so people can understand the problems and at least a proposed = solution.

 

As you point out, we need to be able to show relationships between = sets of indicators, where we may have a few sets of indicators that = could have a relationship to each other within a document.  In the = July presentation, one of the questions was to see if we should add new = category attribute values for the System class that would connect the = list of included indicators.  I think we should still keep the = concept of a Node to a single node, but perhaps within System, list = multiple sets of Nodes that may be one type of attack.  Rosella had = suggested pulling forward the “FraudType” from RFC5901, this = would help solve the issue as NodeRole values would compliment an = AttackType (FraudType values could be included in AttackType or some = broader term).  It may be better to have the FraudTypes, plus = attribute values like “C2-server”, = “sinkhole”,  “MalwareDistribution” for = added context so you know what to do with the received set of = indicators.

 

I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method = to connect indicators and indicator sets within an IODEF using an = attribute of indicator_uid (or some other name) with a string value to = make the connection points, and add a few indicators that are commonly = shared into the base IODEF.

 

Back in July, we talked about adding Registry Key/Value pairs and = hashes to the main IODEF document (trying to see if this will help Chris = below).  What if we added the Registry Key/Value pairs as a class = off of RecordData, using a similar structure to what is in RFC5901, and = also added the ability to include hashes in RecordData?  I think if = we then had the indicator_uid at the RecordData level, we could connect = a set within that structure and repeat the structure for other sets in = the same way we would do with Node inside of the System class, using the = indicator_uid to tie the set together.  Then at the more specific = level for the hash, registry Key/value, IP, etc. use an indicator_uid if = we needed them marked at this level as well?  Maybe we want = indicator_set at the higher level?  I’d like some opinions on = this approach.  +1 if you agree, suggestions if you have other = ideas that may work better.

 

We’ll also need to worry about marking the indicators to = prevent forward sharing when not permitted.  We may want to use = these values or something else. 

 

Thank you!
Kathleen 

 

= From:= Harrington, Christopher
Sent: Friday, February 01, 2013 = 12:01 PM
To: Moriarty, Kathleen; MILE IETF
Subject: = RE: [mile] IOCs

 

I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related:

 

Two or more indicators of different type that relate to the same = threat:

The file hash of a malicious file and the URL of the C2 that the file = uses. Either or both may be present to indicate a compromise. =

 

Two or more indicators of the same type that relate to the same = threat:

2 different registry values for the same registry key. If either = value is present it is a compromise indicator but both will not be = present.

 

The problem compounds itself very quickly. Consider the scenario = where both groupings above are part of the same threat. I need to show = that logical groupings of Indicators are related as well. We can’t = send multiple IODEF messages for this from what I remember reading. =

 

The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It’s not uncommon to = send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping.

 

Thoughts?

 <= span style=3D'color:black'>

Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security Engineer

GSO - Critical Incident Response Center

EMC - Where Information Lives

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

 

= From:= mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of Moriarty, Kathleen
Sent: Friday, February = 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] = IOCs

 

All –

 

I’d like your input and will refocus the thread to get opinions = from the list on options to help solve the problems raised in my message = and additionally in Paul’s message.

 

Interesting point, C. Henry.  Our objective here is to have = machine automated exchanges, so we rely on encryption rather than = obfuscation to achieve the necessary level of = confidentiality.

 

Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that = could be indicators.  The question I raised was on how to connect = sets of indicators in the same IODEF document, assuming the ability to = have watchlists that could have several sets of indicators included, as = well as to connect indicators that may be included in embedded = schemas.

 

If we add an attribute on all of the relevant indicators, let’s = say ‘indicator-uid’ how do we mark the indicators?  Do = we use this to mark who sent the indicator as well so that we can = prevent forward sharing when it is not permitted or handle that = separately? 

 

Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of = SCI or right off of the IODE schema in EventData? (more details on this = in my first message).

 

Comments and questions encouraged to figure out the right technical = solution to have this machine automatable.

 

Thank you,

Kathleen

 

= From:= mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of C. Henry Adams & BIE
Sent: = Monday, January 28, 2013 11:25 PM
To: MILE = IETF
Subject: Re: [mile] IOCs

 

Temporal Dependency sounds interesting.  = I remember when I first ran across this particular craft, an experienced = colleague asked me a peculiar question.  He said, " How do you = stop someone from tracking the IP Address to your computer?"  =

I replied, "I don't know, how?"

Then he said, = "Cut the dog-gone thing off  and the modem that it is = connected- which is constantly on!"   LOL

Here's = my point (Hypothetical Situation) :  There is a 1st Responder = searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation.  He /or She = needs to communication back to other Officials that he /or somehow is in = Danger.  The device used to communicate has been captured by the = great minds of the enemy.  It's only a matter of time before they = utilize reverse engineering to figure out how it functions.  = However, their pride comes before a fall when seeking the location of = other similar devices to attack.  Why? Perhaps the less thought of = concepts that makes the device function properly, saves the day by = disguise or cutting it off (figuratively speaking).

Just a = visionary thought.

C. Henry Adams
chenryadams@biemediagroup.c= om
http://biemediagroup.com

The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is = prohibited.

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org>= wrote:


From: Dave Misell <david.misell@bcs.org>
Subj= ect: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Da= te: Monday, January 28, 2013, 9:25 PM

UID could be mirrored = with DNS SEC a pemanent and temporal key, with a temporal = Id?

Yours Faithfully,

Dave Misell MSc = CISSP
SilentCircle  dsm
07710 380044
david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:

> Serialization of a particular Lists of XML = Classes in a unique way was closely related to what I attempted to = express when I stated, "consider to a degree what appears to be = illogical in brilliant minds in some instances."
>
> = However, I see Dr. Stoecker's point a little clearer.  However, it = would be nice if the UID was in some way disguised from those who study = this Security Art Form in a negative way.
>
> C. Henry = Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
>
> Re: [mile] = IOCs
>
> Sunday, January 27, 2013 8:52 PM
> = From:
> "Stoecker, Paul" <Paul.Stoecker@rsa.com= >
> To:
> "mile@ietf.org" <mile@ietf.org>
> I = would like to look at this from a slightly different = perspective=A9let's
> say I get an XML document that tells me = about an incident.  This document
> has source IP and = destination IP that is being shared.  However, what I
> don't = know is which IP address is my indicator and which is just a
> = contextual piece of information.  This means that my detection = product
> isn't going to know which one to use either, because = there is nothing to
> tell me which IP is the one, even if the = roles are set it still might not
> be enough to tell my system = which one I should use as the indicator.
>
> If we had = something like indicator_id as an attribute, it would allow us
> = to easily identify indicators from contextual data.  I do admit to = being
> biased as I have spent much of my career working on the = monitoring and
> detection side of these things, so I am just = thinking of ways to make it
> very clear what the indicators are = in the XML document and the other data
> that may be important as = I investigate activity that I have detected off
> of those = indicators.
>
>
> I did suggest the detection class, = but I think we may get more flexibility
> with the = indicator_uid.  One thing that I haven't considered is the = UID
> portion of this=A9how do we use that UID?  How is the = UID created?  Are
> there standards for UIDs?
> =
> Regards,
>
> Paul
>
>
> =
> Paul W. Stoecker, Ph.D.
> SMC Lead Content = Architect
> RSA, The Security Division of EMC
> cell: = 302.379.3375 | e: paul.stoecker@rsa.com=
>
> --- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com= > wrote:
>
> From: C. Henry Adams & BIE <chatlga2000@yahoo.com= >
> Subject: RE: [mile] IOCs
> To: = "KathleenMoriarty" <kathleen.moriarty@emc= .com>
> Cc: mile@ietf.org
> Date: = Saturday, January 26, 2013, 6:17 PM
>
> Greetings = Kathleen,
>
> Your logic stimulates my visionary brain = because I'm amazed at the many avenues you review with this approach at = once.  However,  could you share a few advantages and = disadvantages to the latter?
>
> = -------------------------------------------------------------------------= -------------------------------------------------
> "we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via = SCI."
>
> = -------------------------------------------------------------------------= ------------------------------------------------
>
> You = pointed out what you consider to be logical places, but if I wanted to = protect information from parties capable of ascertaining it from your = logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances.
>
> =
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
> The information contained herein is = for the exclusive use of the original recipient. This information is = granted for limited distribution within the recipient's place of = business for planning purposes only. Further dissemination, whether = private or public is prohibited.
>
> --- On Sat, 1/26/13, = Moriarty, Kathleen <kathleen.moriarty@emc= .com> wrote:
>
> From: Moriarty, Kathleen <kathleen.moriarty@emc= .com>
> Subject: RE: [mile] IOCs
> To: "C. Henry = Adams & BIE" <chatlga2000@yahoo.com= >, "mile@ietf.org" <mile@ietf.org>
> = Date: Saturday, January 26, 2013, 10:13 AM
>
> Hello C. = Henry & others,
>
> Thanks for taking a look at = this.  We have a few considerations in this email thread I would = like to hear thoughts on (and there may be more once RFC5070-bis is = actively edited).
>
> The AdditionalData class and the = RecordItem class both allow for non-XML extensions.  Where you = place the extensions should be specific to the logical grouping of the = parent elements so you can understand more about the included data in = most cases. 
>
> The Impact class can be used to = provide context information on the included data of the report and also = can include a confidence rating on the report as a whole.  = Extensions related to impact would be one level higher (at the moment) = in the Assessment class using the AdditionalData extension point.  =
>
> Take asked about including vulnerability information, = I would think that would fit under the Vulnerability extension point of = the SCI draft in the Method class.  He did ask about non-XML.  = RecordItem or AdditionalData do allow for non-XML extension points, we = could either have the SCI draft handle these as well or have the = extensions that are non-XML come directly off the AdditionalData or = RecordItem classes according to what makes sense from a logical = standpoint.
>
> As for my question, it was = two-fold.
>
> Indicator based schemas have a reference = number or a GUID for the various indicators they share.  If we are = extending to embed other schemas that include such reference or GUID = identifiers, do we want to add an attribute to the various elements in = IODEF that could be indicators?  Is this enough to make the = connections or is something else else needed?  We could add = something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers.
>
> Then the other = question was on how to include indicators that are not in the base = schema that may be related or have language with "and" = "or" to specify the relationships.  In some cases, you = will want to group these indictors in one extension point, where they = may fit logically in multiple places if the relationships did not need = to be shown in the data format.  If we have cases like this where = you need more complex representations, should we use one extension point = via the SCI draft off of the EventData class AdditionalData extension = point?  Opinions are needed here....
>
> A few people = have mentioned wanting to include some commonly shared indictors into = the base IODEF document.  We could have a catch-all class that does = this and has an extension point off of it in EventData or we could = continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI.  I = think I like the latter approach.
>
> Thank you,
> = Kathleen
> ________________________________________
> From: = mile-bounces@ietf.org= [mile-bounces@ietf.org= ] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com= ]
> Sent: Saturday, January 26, 2013 3:05 AM
> To: mile@ietf.org
> Cc: C. = Henry Adams
> Subject: Re: [mile] IOCs
>
> Greetings = Everyone,
>
> Take mentioned two types of indicators based = on the :
> = -------------------------------------------------------------------------= -----------------------------
> 1) If the indicators are something = like an XML-based alert/warning of
> information leakage, it could = be an event that are conveyed in the SCI's
> EventReport class, = IMHO.
>
> 2) If the indicators are something like an = non-XML ones, I guess it could be
> conveyed without using SCI = draft.
> For instance, we could use Impact class of the base IODEF = to convey the
> indicators.
> We could for instance extend = the list of indicators of the Impact class, if
> needed.
> = -------------------------------------------------------------------------= -----------------------------
>
> In doing so he pointed = out the "Impact Class"
>
> Whereas, Kathleen = stated,
>
> = -------------------------------------------------------------------------= ----------------------------
> For the discussion below, I was = thinking more of combined set with relationships that may be included in = a single extension point, so that's why I was thinking about the = EventData class, but there may be better locations or a specific area = within the EventData.
>
> Paul Stoecker had suggested a = "Detection" class as a consideration.
> = -------------------------------------------------------------------------= ---------------------------
>
> Kathleen thoughts related = yet still with other indicators and the EventData Class.
> =
> Is there a possible way to create a new XML class which = encompass combining the EventData, Detection and base IODEF classes to = simplify this issue?
>
>
> C. Henry Adams
> chatlga2000@yahoo.com= (Direct Email)
> chenryadams@bieme= diagroup.com
>
>
> The information contained = herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's = place of business for planning purposes only. Further dissemination, = whether private or public is prohibited.
> = _______________________________________________
> mile mailing = list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile

 

------=_NextPart_001_01C3_01CE02E3.6F6C8DE0-- ------=_NextPart_000_01C2_01CE02E3.6F6C8DE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMDQx OTI1MDlaMCMGCSqGSIb3DQEJBDEWBBRDZ+Z3liXP+uYoLq1+/OoRpFuDITCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAPsIh5gdY9uRfFou8T3++ZRijIEQTMzN/s3e2PPabaZn+o5zLU/yyjvMTMJ90gDFx YfLDVxDab5jOygjkLU2oOQiKL52kgfBgXd5bYO81UkzQXNGXcpUikLTe2yc4tmwOAj4gf2ApbrPy pL+rbp6NGRMLDBwnGJ4LQzjpRnnEXbKne0W3KscEifQnrBFiR5TQXx4DxMRCSJBDhIVv+fcH6STo oOf9l9sQZ8MaiwsEn9n1l62J8cnpEfU68vQ/ZiCs4+d6vE1WuvQxyoMH5zag8pHWowQwK4swFpiX H/cwhMLTU8GjhCv4yxpsu5ssuv89MbGw6nCJIcmRA+Y9tXwLqQAAAAAAAA== ------=_NextPart_000_01C2_01CE02E3.6F6C8DE0-- From takeshi_takahashi@nict.go.jp Tue Feb 5 09:03:58 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2E21F886A for ; Tue, 5 Feb 2013 09:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.633 X-Spam-Level: ** X-Spam-Status: No, score=2.633 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ltvxcqiaNN for ; Tue, 5 Feb 2013 09:03:57 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22921F8880 for ; Tue, 5 Feb 2013 09:03:55 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r15H3l22000454; Wed, 6 Feb 2013 02:03:47 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r15H3lAs001004; Wed, 6 Feb 2013 02:03:47 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r15H3lFi001001; Wed, 6 Feb 2013 02:03:47 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 7074D52BE; Wed, 6 Feb 2013 02:03:47 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6610F1793; Wed, 6 Feb 2013 02:03:47 +0900 (JST) From: "Takeshi Takahashi" To: "'Harrington, Christopher'" , "'Stoecker, Paul'" , "'Moriarty, Kathleen'" , "'MILE IETF'" References: In-Reply-To: Date: Wed, 6 Feb 2013 02:03:44 +0900 Message-ID: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBiX7UQKYA== Content-Language: ja Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:03:59 -0000 I like this discussion. I agree, it would be good idea to have indicator identifiers inside the IOC-related classes. > Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of SCI = or right off of the IODE schema in EventData? (more details on this in my = first message). If we could see any indicator of compromise as computer event record, we could use SCI:EventReport class as the place for the XML-based IOCs that couldn't fit anywhere else. For the non-XML IOCs, we could use RecordData class, as suggested. I agree to have indicator_uid, but I am not sure about the needs of the indicator_set_id. I understand we could do some grouping of individual indicator_uids and = its usability, but I am not sure whether we do not have any other way to = express these groupings. For instance, a Reference class refers to several indicadtor_uids. In = this case, they could be, in a sense, grouped. Isn't it enough? I would appreciate if anybody could share expertise on this. Though I = think I have read all the emails in the list, I might have mis-understood some points. By the way, I think the indicator_uids should be added to the SCI = classes' attributes so that they can be correlated with another information as = well. Thanks Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs I think some sort of group ID would do the trick. We also need a logical = and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have = the same group ID since they are related.=20 Thanks, --Chris From: Stoecker, Paul=20 Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? = =A0This would allow you to group indicators that are related into the same group = ID. =A0Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) = class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. =A0I = don't mean a place to put indicators that are missing from IODEF.I mean a place in = the IODEF document where you put the indicators that are used for detection = and prevention of the shared Incident. =A0I don't know the answer here, but = there has got to be a good way for indicators to be identified and being able = to group them as Chris has suggested without basically recreating something complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e:=A0paul.stoecker@rsa.com From: , Kathleen Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" , MILE = IETF Subject: Re: [mile] IOCs Hi Chris, =A0 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =A0 The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to 'parts of an = incident or the useful information on an incident for sharing purposes.=A0 It was written before we used terms like indicators.=A0 With that in mind, = Rosella proposed a number of changes back in July, both for guidance and for = format updates.=A0 It may help to have the first draft try to address at least = some of these issues so people can understand the problems and at least a proposed solution. =A0 As you point out, we need to be able to show relationships between sets = of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document.=A0 In the July = presentation, one of the questions was to see if we should add new category attribute = values for the System class that would connect the list of included = indicators.=A0 I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type = of attack.=A0 Rosella had suggested pulling forward the "FraudType" from = RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some = broader term).=A0 It may be better to have the FraudTypes, plus attribute values = like "C2-server", "sinkhole",=A0 "MalwareDistribution" for added context so = you know what to do with the received set of indicators. =A0 I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared = into the base IODEF. =A0 Back in July, we talked about adding Registry Key/Value pairs and hashes = to the main IODEF document (trying to see if this will help Chris = below).=A0 What if we added the Registry Key/Value pairs as a class off of RecordData, = using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData?=A0 I think if we then had the = indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with = Node inside of the System class, using the indicator_uid to tie the set together.=A0 Then at the more specific level for the hash, registry = Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well?=A0 Maybe we want indicator_set at the higher level?=A0 I'd like = some opinions on this approach.=A0 +1 if you agree, suggestions if you have = other ideas that may work better. =A0 We'll also need to worry about marking the indicators to prevent forward sharing when not permitted.=A0 We may want to use these values or = something else.=A0=20 =A0 Thank you! Kathleen=A0=20 =A0 From: Harrington, Christopher=20 Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =A0 I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show are related: =A0 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the = file uses. Either or both may be present to indicate a compromise.=20 =A0 Two or more indicators of the same type that relate to the same threat:=20 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be = present.=20 =A0 The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple = IODEF messages for this from what I remember reading.=20 =A0 The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It's not uncommon to send both the = MD5 and SHA1 hash of a malicious file. The indicator is the file but the = IOCs are the 2 hash values. How do we show they are related? If we use a = unique Inidcator ID for each hash value there needs to be a higher level = grouping.=20 =A0 Thoughts? =A0 Thanks, =A0 --Chris =A0 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =A0 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =A0 All -=20 =A0 I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. =A0 Interesting point, C. Henry.=A0 Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. =A0 Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that could be indicators.=A0 The question I raised was on how to connect sets of = indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. =A0 If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators?=A0 Do we use this to mark = who sent the indicator as well so that we can prevent forward sharing when = it is not permitted or handle that separately?=A0=20 =A0 Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my = first message). =A0 Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. =A0 Thank you, Kathleen =A0 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =A0 Temporal Dependency sounds interesting.=A0 I remember when I first ran = across this particular craft, an experienced colleague asked me a peculiar question.=A0 He said, " How do you stop someone from tracking the IP = Address to your computer?"=A0=20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off=A0 and the modem that it is connected- which is constantly on!"=A0=A0 LOL Here's my point (Hypothetical Situation) :=A0 There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation.=A0 He /or She needs to = communication back to other Officials that he /or somehow is in Danger.=A0 The device used = to communicate has been captured by the great minds of the enemy.=A0 It's = only a matter of time before they utilize reverse engineering to figure out how = it functions.=A0 However, their pride comes before a fall when seeking the location of other similar devices to attack.=A0 Why? Perhaps the less = thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle=A0 dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrote: > Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider = to a degree what appears to be illogical in brilliant minds in some = instances." >=20 > However, I see Dr. Stoecker's point a little clearer.=A0 However, it = would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different = perspective=A9let's > say I get an XML document that tells me about an incident.=A0 This = document > has source IP and destination IP that is being shared.=A0 However, = what I > don't know is which IP address is my indicator and which is just a > contextual piece of information.=A0 This means that my detection = product > isn't going to know which one to use either, because there is nothing = to > tell me which IP is the one, even if the roles are set it still might = not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow = us > to easily identify indicators from contextual data.=A0 I do admit to = being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make = it > very clear what the indicators are in the XML document and the other = data > that may be important as I investigate activity that I have detected = off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more = flexibility > with the indicator_uid.=A0 One thing that I haven't considered is the = UID > portion of this=A9how do we use that UID?=A0 How is the UID = created?=A0 Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once.=A0 However,=A0 could you = share a few advantages and disadvantages to the latter? >=20 > -------------------------------------------------------------------------= --- ---------------------------------------------- > "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via = SCI." >=20 > -------------------------------------------------------------------------= --- --------------------------------------------- >=20 > You pointed out what you consider to be logical places, but if I = wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this.=A0 We have a few considerations in = this email thread I would like to hear thoughts on (and there may be more = once RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for = non-XML extensions.=A0 Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about = the included data in most cases.=A0=20 >=20 > The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on = the report as a whole.=A0 Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point.=A0=20 >=20 > Take asked about including vulnerability information, I would think = that would fit under the Vulnerability extension point of the SCI draft in = the Method class.=A0 He did ask about non-XML.=A0 RecordItem or = AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come = directly off the AdditionalData or RecordItem classes according to what makes = sense from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the = various indicators they share.=A0 If we are extending to embed other schemas = that include such reference or GUID identifiers, do we want to add an = attribute to the various elements in IODEF that could be indicators?=A0 Is this = enough to make the connections or is something else else needed?=A0 We could = add something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not = in the base schema that may be related or have language with "and" "or" to specify the relationships.=A0 In some cases, you will want to group = these indictors in one extension point, where they may fit logically in = multiple places if the relationships did not need to be shown in the data = format.=A0 If we have cases like this where you need more complex representations, = should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point?=A0 Opinions are needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document.=A0 We could have a catch-all = class that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI.=A0 I think I = like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= --- -------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the = SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it = could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey = the > indicators. > We could for instance extend the list of indicators of the Impact = class, if > needed. > -------------------------------------------------------------------------= --- -------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > -------------------------------------------------------------------------= --- ------------------------- > For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --- ------------------------ >=20 > Kathleen thoughts related yet still with other indicators and the EventData Class. >=20 > Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify = this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile =A0 From chatlga2000@yahoo.com Tue Feb 5 21:00:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794DE21F8A0D for ; Tue, 5 Feb 2013 21:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=1.992, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ8U32OtmpSd for ; Tue, 5 Feb 2013 21:00:41 -0800 (PST) Received: from nm8-vm4.bullet.mail.ne1.yahoo.com (nm8-vm4.bullet.mail.ne1.yahoo.com [98.138.91.168]) by ietfa.amsl.com (Postfix) with ESMTP id B0A2D21F87D6 for ; Tue, 5 Feb 2013 21:00:41 -0800 (PST) Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 05:00:41 -0000 Received: from [98.138.89.246] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 05:00:41 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 05:00:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 993129.63440.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 83094 invoked by uid 60001); 6 Feb 2013 05:00:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360126840; bh=F4iLiHDT2bBgkUVaEifEsyVZkswhRVcVNgVj04lYc9M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=37WGzI1UlXlNviKItSGNBtHVegsPk7Yib86OdqKHdKmUe1orAz7phN3SdseTjpwxHEr/jT76MTEVoYrr/ZFOeaJFxrSxMeB93QOit2y45st0dP8iXl9zhWMVchMh/qlUiZu0HJo0s2RYYccDwmyw/QtKzDb8p4u6lkMR4eUF0Gw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=yGHLS3CxBxnxLqHXw7QNjk3LNp++BpKzi2XXnPGfWDD/41ytDT0xLt8SwQaZBKqDLJnVkHmiG/FqIUruhyxetNMdTNIyi+PrzxxmnMIQ+YHXsfuDwrZ9JIXyHKaOCPP71t18cKMdE7CbZWvOHd6t6m9czSZZJnYn0TKB0ZiL2U0=; X-YMail-OSG: qPRdnKsVM1lfYsuulPk.XDnBIdYiZkIht9MMiXNcmZm1pUH TGMn0R7TRs.vwfawomQew.7qDMQhd_d9wOghIj1Y3c3e7AJGO7xJRCwasyuV 3na6wO_x.LvZeBvOAv8HUzbVY0F1eBIZpnY4fPJBx4ijt9.44QORYkY0bi_G YdfcTIQZNn7FOscBV0i3PZFoakK._MFBAIHzuRzAtlNXIjD1dTOW2JTWwlQA FMhIU1D.k4wZ2qLtUiQuTvC42Y1EF9EveNx_WOW0b6JPGAncg4r9UBAV3qAq R5mFErU_ACWuN8ogktByBzMHWitdLuGZk7cIJwoHtpMd0Jv3cimm4KdsoHWE SzgNSsoBHu4y.6s3QlHpdKEWcG4CUfskykyVGQpWhka7SVlTvb56AXEFSq8C qSH.ZgMH0_YrZVhWOJQpvw3Xffg.ZAcDwFyJ1usNkTAL8Jthu7lcWIcWRC.E dkebxW8HBYxrlg2RCPRAC7HPXeUiNxqFNYcqMBsCjqGGqDBxgA6_MFC32mrW 5 Received: from [71.22.243.36] by web121604.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 21:00:40 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEFsbCwNCg0KRmlyc3QsIEkgd291bGQgbGlrZSB0byB0aGFuayBFcmljICYgS2F0aGxlZW4gZm9yIHRoZSBvcHBvcnR1bml0eSB0byBwcm9kdWNlIGEgcG9zc2libGUgQXR0YWNrIFZlY3RvciBTY2VuYXJpbyB0b3dhcmQgTUlMRS7CoCBUaGlzIHNjZW5hcmlvIHdhcyBzaW1wbHkgY3JlYXRlZCB0byBkcnVtIHVwIHVub3J0aG9kb3ggaWRlYXMgb3Igc29sdXRpb25zIHRvIGhlbHAgc29sdmUgdGhlIGN1cnJlbnQgaXNzdWUgb2JzZXJ2ZWQuwqAgSXQgbWF5IG9yIG1heSBub3QgaGF2ZSBhbnkgdXMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.132.503 Message-ID: <1360126840.60482.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 21:00:40 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-595860442-1360126840=:60482" Cc: "C. Henry Adams" Subject: [mile] C. Henry's Analytical Attack X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 05:00:42 -0000 ---36511695-595860442-1360126840=:60482 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Greetings All, First, I would like to thank Eric & Kathleen for the opportunity to produce= a possible Attack Vector Scenario toward MILE.=A0 This scenario was simply= created to drum up unorthodox ideas or solutions to help solve the current= issue observed.=A0 It may or may not have any use in the identifier correl= ations. Attack Vector Scenario for MILE Assumption:=A0 Let's assume the device (a particular Smartphone) utilizes I= ODEF, RID & MILE in a special software to send certain communications to Em= ergency Mgmt Agencies. An Attacker steals a First Responder's Smartphone equipped with the IODEF, = RID & MILE technology via its SECURED Web Browser. This particular phone was poorly researched by a Government Agency that uti= lize it.=A0 In fact, it has an older model Android or iPhone Browser which = is not patched. Furthermore, this particular smartphone FTS (Factory Test Screen) informati= on is easily found on the Internet showing how to break into it. Therefore, the Attacker removes the IP Address of the smartphone to stop it= from being tracked or buy time to perform analysis. Furthermore while parsing the special software (i.e. Software consisting of= IODEF, RID & MILE), the attacker takes a lexical analysis approach primari= ly toward MILE. Discovering the correlations of MILE identifiers with RID and IODEF;=A0 a p= robe is establish which eventually leads to a unique attack. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. ---36511695-595860442-1360126840=:60482 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings All,

First, I would like to = thank Eric & Kathleen for the opportunity to produce a possible Attack = Vector Scenario toward MILE.  This scenario was simply created to drum= up unorthodox ideas or solutions to help solve the current issue observed.=   It may or may not have any use in the identifier correlations.
Attack Vector Scenario for MILE

Assumption:  Let's assume the= device (a particular Smartphone) utilizes IODEF, RID & MILE in a speci= al software to send certain communications to Emergency Mgmt Agencies.
<= br>An Attacker steals a First Responder's Smartphone equipped with the IODE= F, RID & MILE technology via its SECURED Web Browser.

This parti= cular phone was poorly researched by a Government Agency that utilize it.&n= bsp; In fact, it has an older model Android or iPhone Browser which is not patched.

Furthermore, this particular smartphone FTS (Factory Test = Screen) information is easily found on the Internet showing how to break in= to it.

Therefore, the Attacker removes the IP Address of the smartph= one to stop it from being tracked or buy time to perform analysis.

F= urthermore while parsing the special software (i.e. Software consisting of = IODEF, RID & MILE), the attacker takes a lexical analysis approach prim= arily toward MILE.

Discovering the correlations of MILE identifiers = with RID and IODEF;  a probe is establish which eventually leads to a = unique attack.


C. Henry Adams
=0Achatlga2000@yahoo.com (Direc= t Email)
=0Achenryadams@biemediagroup.com
=0A
=0A
=0AThe inform= ation contained herein is for the exclusive use of the original recipient. = This information is granted for limited distribution within the recipient's= place of business for planning purposes only. Further dissemination, wheth= er private or public is prohibited.
---36511695-595860442-1360126840=:60482-- From chatlga2000@yahoo.com Wed Feb 6 10:42:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50FD21F86EC for ; Wed, 6 Feb 2013 10:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=2.405, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNVNKbTNKC2k for ; Wed, 6 Feb 2013 10:42:24 -0800 (PST) Received: from nm33-vm1.bullet.mail.ne1.yahoo.com (nm33-vm1.bullet.mail.ne1.yahoo.com [98.138.229.65]) by ietfa.amsl.com (Postfix) with ESMTP id BAA3621F86EB for ; Wed, 6 Feb 2013 10:42:23 -0800 (PST) Received: from [98.138.90.56] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 18:42:20 -0000 Received: from [98.138.87.9] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 18:42:20 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 18:42:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 350371.67659.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 61388 invoked by uid 60001); 6 Feb 2013 18:42:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360176140; bh=jomo4RfM18Qi+sgMG7kMWagbe60Ryzbc/U7uBajKUVc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=iq/p693QZcqp7XUO07roSpob7HljfJZ01oHtbMGOP+uFPI3GRAy8ZgCjmBfanLZWmmCxZxlx6Ibgm8IeGOiNQjBEt+5Gcp0BK0CtSH5cMoOTEhH0N3yPHt15jc7pl/74HHOCt8tlRleqZua/XgVx+EKR8RQ3flZyyvpNSXNs4bw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=aEWVXmgoqNxaWoVDF6hqa62SuWd3NoT4iQQ9L0iKLCUtgzwxEFzx0U2Cuk0Q3pyADMPQjs7eEMfpHfSBkIZIyCu8hg3bg4nyHgv8QHevvvYeRpzVs3xrd5nIkB9NHy9hvXoDmUXsHdeFAAxgxlUA8Jjnj3Ogv2M7It+l8MtW2dg=; X-YMail-OSG: NLVm43MVM1k9aMUCZYPY6xePYfF.0gDA5bwsFWox9ulyKxf nmY2UIJROcKwK2HA23GQSRDWltYDWxxPuIPZtpZxJoiCGq9T4E0ZZTqQBrZM fpLhU2wWx.My0Tmsi2gjaN4MUQ3Kat0eKVFzINACLUyn20fhB.TZCDaxY2d1 gSK6WyiZcfvGPxImeXkVY2q2xENc.Qfel42RHswPrsRyZLP1hvzjqhjY.7q. gnLQjSqMtb_VIwu96g_.d1vxNl9uipWUMODnTt5ee78dtHE9ik_CmIJ3N1cn UOVUw507sQ0hc_d6YKkWSmyYKlaIhoX4Oo_RGzHtoAkKKaNuvtNmUIMoqwEI e_RbRZc2fF5k6BHwxYiV7r6nKXwrczBw1m0dc_Ip5wEn8wczoNHorGNzQzGN pOgdflnrpYwUyQMED2UNp_vGRt4ex_H2MpxL0K3wIlwFc_yWnHUhpKNcwtgF qcoFDHih1IC1IJ4AdLYi5ncN61EhURQH213WWz6TFMjytDman9tDiL8T.wsC p Received: from [71.22.243.36] by web121606.mail.ne1.yahoo.com via HTTP; Wed, 06 Feb 2013 10:42:20 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEFsbCwNCg0KQXMgSSBzdGF0ZWQgY2F1dGlvdXNseSBvcHRpbWlzdGljLCB0aGUgQXR0YWNrIFZlY3RvciBzY2VuYXJpbyBmcm9tIGEgdmlzdWFsDQpzdGFuZHBvaW50IGNvdWxkIGJlIHVzZWZ1bCBvciBub3QuICANCg0KTmV2ZXJ0aGVsZXMsIGxldCBtZSBwb2ludCBvdXQgdGhhdCBpZiB0aGVyZSBhcmUgaXNzdWVzIHdpdGggc2F5IFhNTCBpZGVudGlmaWVycyB3aXRoaW4gTUlMRSB3aGljaCB3YXMgZGVyaXZlZCBmcm9tDQpJTkNIIHRvIGhlbHA6DQoNCjEpIENvb3JkaW5hdGUgSW5jaWRlbnQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.132.503 Message-ID: <1360176140.49224.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Wed, 6 Feb 2013 10:42:20 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-64005260-1360176140=:49224" Cc: "C. Henry Adams" , Burger Eric Subject: Re: [mile] C. Henry's Analytical Attack X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:42:24 -0000 --1458340343-64005260-1360176140=:49224 Content-Type: text/plain; charset=us-ascii Greetings All, As I stated cautiously optimistic, the Attack Vector scenario from a visual standpoint could be useful or not. Nevertheles, let me point out that if there are issues with say XML identifiers within MILE which was derived from INCH to help: 1) Coordinate Incident Reports 2) Reference SCAP Enumerations Perhaps, looking at different scenarios whether they are way out of scope will help somehow identify a simplified solution. Thanks, for the consideration. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --1458340343-64005260-1360176140=:49224 Content-Type: text/html; charset=us-ascii 
Greetings All,

As I stated cautiously optimistic, the Attack Vector scenario from a visual
standpoint could be useful or not.  

Nevertheles, let me point out that if there are issues with say XML identifiers within MILE which was derived from
INCH to help:

1) Coordinate Incident Reports
2) Reference SCAP Enumerations  

Perhaps, looking at different scenarios whether they are way out of scope will help somehow identify a simplified solution.
Thanks, for the consideration.

C. Henry Adams
chatlga2000@yahoo.com (Direct Email)
chenryadams@biemediagroup.com


The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.
--1458340343-64005260-1360176140=:49224-- From eburger@cs.georgetown.edu Wed Feb 6 10:18:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4B21F897A for ; Wed, 6 Feb 2013 10:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5nKDWydqibT for ; Wed, 6 Feb 2013 10:18:42 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 03E8721F8464 for ; Wed, 6 Feb 2013 10:18:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 5A62543253; Wed, 6 Feb 2013 13:18:41 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-gqKEFH5-rf; Wed, 6 Feb 2013 13:18:39 -0500 (EST) Received: from [10.166.71.157] (208.177.47.110.ptr.us.xo.net [208.177.47.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id E4EB14324A; Wed, 6 Feb 2013 13:18:38 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Burger Eric In-Reply-To: <1360126840.60482.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Wed, 6 Feb 2013 13:18:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26B0C9C1-40CF-48E3-9114-98502FD48FFA@cs.georgetown.edu> References: <1360126840.60482.YahooMailClassic@web121604.mail.ne1.yahoo.com> To: C.Henry Adams & BIE X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 06 Feb 2013 10:43:38 -0800 Cc: MILE IETF Subject: Re: [mile] C. Henry's Analytical Attack X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:18:42 -0000 I do not believe this is a use case for MILE and as such is way out of = scope. On Feb 6, 2013, at 12:00 AM, C. Henry Adams & BIE = wrote: > Greetings All, >=20 > First, I would like to thank Eric & Kathleen for the opportunity to = produce a possible Attack Vector Scenario toward MILE. This scenario = was simply created to drum up unorthodox ideas or solutions to help = solve the current issue observed. It may or may not have any use in the = identifier correlations. >=20 > Attack Vector Scenario for MILE >=20 > Assumption: Let's assume the device (a particular Smartphone) = utilizes IODEF, RID & MILE in a special software to send certain = communications to Emergency Mgmt Agencies. >=20 > An Attacker steals a First Responder's Smartphone equipped with the = IODEF, RID & MILE technology via its SECURED Web Browser. >=20 > This particular phone was poorly researched by a Government Agency = that utilize it. In fact, it has an older model Android or iPhone = Browser which is not patched. >=20 > Furthermore, this particular smartphone FTS (Factory Test Screen) = information is easily found on the Internet showing how to break into = it. >=20 > Therefore, the Attacker removes the IP Address of the smartphone to = stop it from being tracked or buy time to perform analysis. >=20 > Furthermore while parsing the special software (i.e. Software = consisting of IODEF, RID & MILE), the attacker takes a lexical analysis = approach primarily toward MILE. >=20 > Discovering the correlations of MILE identifiers with RID and IODEF; = a probe is establish which eventually leads to a unique attack. >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution = within the recipient's place of business for planning purposes only. = Further dissemination, whether private or public is prohibited. From kathleen.moriarty@emc.com Thu Feb 7 11:00:25 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF41021F8837 for ; Thu, 7 Feb 2013 11:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL3Hm4RUWGj3 for ; Thu, 7 Feb 2013 11:00:24 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1621F86EF for ; Thu, 7 Feb 2013 11:00:23 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r17J0LFX013337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2013 14:00:22 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 7 Feb 2013 13:59:48 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r17Ixlnd007276; Thu, 7 Feb 2013 13:59:48 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Thu, 7 Feb 2013 13:59:47 -0500 From: "Moriarty, Kathleen" To: Takeshi Takahashi , "Harrington, Christopher" , "Stoecker, Paul" , "'MILE IETF'" Date: Thu, 7 Feb 2013 13:59:46 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBiX7UQKYIADUbfQ Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> In-Reply-To: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 19:00:26 -0000 Hi Take & others, Thanks for chiming in, I've been talking about this with Chris and a few ot= hers on their use cases and would like more opinions. I'll provide an opti= on below from what we have discussed from a CIRC view point. We are also w= ondering how to also provide logic in IODEF that could cross over into SCI = attached schemas or IODEF extensions (the solutions may all tie together wi= th this discussion - or there may be better/more elegant solutions others w= ould like to propose). -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF= ' Subject: RE: [mile] IOCs > I like this discussion. > I agree, it would be good idea to have indicator identifiers inside the > IOC-related classes. KMM: At the class level, we may have several indicators listed that should = be viewed as a set and may have another instance of that same class that is= a related issue, but a separate set. We could as you say, list the indica= tor IDs connected through the reference class. The set IDs might give us o= ther ways to group the values when we get into logic and relationships betw= een sets or indicators. This could also be a way to connect indicators or = sets across XML documents that could have been shared previously. If there= are a large number of indicators in the set, then this becomes useful, for= smaller sets, I agree it doesn't make as much sense. What do others think? >> Then for indicators not included in the base schema that may not fit int= o >> a category in the SCI draft, do we create a place for these off of SCI o= r >> right off of the IODE schema in EventData? (more details on this in my f= irst >> message). > > If we could see any indicator of compromise as computer event record, we > could use SCI:EventReport class as the place for the XML-based IOCs that > couldn't fit anywhere else. KMM: That sounds like a good idea to me. This should go into guidance in t= he SCI draft. Does anyone else want to weigh in? > > For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! > I agree to have indicator_uid, but I am not sure about the needs of the > indicator_set_id. > I understand we could do some grouping of individual indicator_uids and i= ts > usability, but I am not sure whether we do not have any other way to expr= ess > these groupings. > For instance, a Reference class refers to several indicadtor_uids. In th= is > case, they could be, in a sense, grouped. Isn't it enough? KMM: It may be, what do you think about large sets of indicators or subsequ= ent messages that add indicators to existing sets? Would this happen? Wou= ld it be easier to express relationships with sets of indicators in additio= n to individual indicators? By using this, it could give us a unique way t= o also provide the logic and relationships in a new class of IODEF so we do= n't have to worry about adding it into the current structure. If there are= better ways to handle that, and others can provide some options, that woul= d be appreciated! Thank you, Kathleen > I would appreciate if anybody could share expertise on this. Though I thi= nk > I have read all the emails in the list, I might have mis-understood some > points. > > By the way, I think the indicator_uids should be added to the SCI classes= ' > attributes so that they can be correlated with another information as wel= l. > > Thanks > Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs I think some sort of group ID would do the trick. We also need a logical an= d / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have the same group ID since they are related. Thanks, --Chris From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group ID= . Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't mea= n a place to put indicators that are missing from IODEF.I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident. I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From: , Kathleen Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" , MILE IETF Subject: Re: [mile] IOCs Hi Chris, I agree, we have some work to do in the updated IODEF, RFC5070-bis. The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an inciden= t or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates. It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution. As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, on= e of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators. I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack. Rosella had suggested pulling forward the "FraudType" from RFC5901= , this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broade= r term). It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF. Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below). Wha= t if we added the Registry Key/Value pairs as a class off of RecordData, usin= g a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together. Then at the more specific level for the hash, registry Key/value= , IP, etc. use an indicator_uid if we needed them marked at this level as well? Maybe we want indicator_set at the higher level? I'd like some opinions on this approach. +1 if you agree, suggestions if you have other ideas that may work better. We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or something else. Thank you! Kathleen From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related: Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the fil= e uses. Either or both may be present to indicate a compromise. Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading. The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. Thoughts? Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs All - I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. Paul mentioned the need to distinguish indicators of compromise from contex= t information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it i= s not permitted or handle that separately? Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my firs= t message). Comments and questions encouraged to figure out the right technical solutio= n to have this machine automatable. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs Temporal Dependency sounds interesting. I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP Address to your computer?" I replied, "I don't know, how?" Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let'= s just say "Live" Terrorist Situation. He /or She needs to communication bac= k to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's only a matter of time before they utilize reverse engineering to figure out how it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrote: > Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to = a degree what appears to be illogical in brilliant minds in some instances." > > However, I see Dr. Stoecker's point a little clearer. However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. > > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > > Re: [mile] IOCs > > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different perspective=A9let'= s > say I get an XML document that tells me about an incident. This document > has source IP and destination IP that is being shared. However, what I > don't know is which IP address is my indicator and which is just a > contextual piece of information. This means that my detection product > isn't going to know which one to use either, because there is nothing to > tell me which IP is the one, even if the roles are set it still might not > be enough to tell my system which one I should use as the indicator. > > If we had something like indicator_id as an attribute, it would allow us > to easily identify indicators from contextual data. I do admit to being > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make it > very clear what the indicators are in the XML document and the other data > that may be important as I investigate activity that I have detected off > of those indicators. > > > I did suggest the detection class, but I think we may get more flexibilit= y > with the indicator_uid. One thing that I haven't considered is the UID > portion of this=A9how do we use that UID? How is the UID created? Are > there standards for UIDs? > > Regards, > > Paul > > > > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote: > > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM > > Greetings Kathleen, > > Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once. However, could you share a few advantages and disadvantages to the latter? > > ---------------------------------------------------------------------------= - ---------------------------------------------- > "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI." > > ---------------------------------------------------------------------------= - --------------------------------------------- > > You pointed out what you consider to be logical places, but if I wanted t= o protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances. > > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com > > The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > > --- On Sat, 1/26/13, Moriarty, Kathleen wrote= : > > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM > > Hello C. Henry & others, > > Thanks for taking a look at this. We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited). > > The AdditionalData class and the RecordItem class both allow for non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about th= e included data in most cases. > > The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole. Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point. > > Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class. He did ask about non-XML. RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint. > > As for my question, it was two-fold. > > Indicator based schemas have a reference number or a GUID for the various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators? Is this enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers. > > Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format. I= f we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here.... > > A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we coul= d continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI. I think I like the latter approach. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs > > Greetings Everyone, > > Take mentioned two types of indicators based on the : > ---------------------------------------------------------------------------= - -------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the SCI's > EventReport class, IMHO. > > 2) If the indicators are something like an non-XML ones, I guess it could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey the > indicators. > We could for instance extend the list of indicators of the Impact class, if > needed. > ---------------------------------------------------------------------------= - -------------------------- > > In doing so he pointed out the "Impact Class" > > Whereas, Kathleen stated, > > ---------------------------------------------------------------------------= - ------------------------- > For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. > > Paul Stoecker had suggested a "Detection" class as a consideration. > ---------------------------------------------------------------------------= - ------------------------ > > Kathleen thoughts related yet still with other indicators and the EventData Class. > > Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? > > > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com > > > The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Christopher.Harrington@emc.com Thu Feb 7 11:11:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29721F87ED for ; Thu, 7 Feb 2013 11:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW1nUzZ1CC8v for ; Thu, 7 Feb 2013 11:11:38 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 35C1621F87CA for ; Thu, 7 Feb 2013 11:11:37 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r17JBPvu029244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2013 14:11:36 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 7 Feb 2013 14:11:07 -0500 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r17JB6oo003995; Thu, 7 Feb 2013 14:11:07 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub36.corp.emc.com ([::1]) with mapi; Thu, 7 Feb 2013 14:11:06 -0500 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , Takeshi Takahashi , "Stoecker, Paul" , "'MILE IETF'" Date: Thu, 7 Feb 2013 14:11:06 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBiX7UQKYIADUbfQgAAIJgA= Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0556_01CE053C.F7C543C0" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 19:11:40 -0000 ------=_NextPart_000_0556_01CE053C.F7C543C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable With respect to tying things back to threat actors, from what I have = seen and use this is a generally accepted grouping: Indicator --> Indictor Set --> Campaign --> Threat Actor Campaign and Threat Actor are where having a "Confidence" attribute = would be beneficial as making those associations is not a perfect science by any means.=20 Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen=20 Sent: Thursday, February 07, 2013 2:00 PM To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE = IETF' Subject: RE: [mile] IOCs Hi Take & others, Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions. I'll provide an option below from what we have discussed from a CIRC view point. We are also wondering how to also provide logic in IODEF that could cross over = into SCI attached schemas or IODEF extensions (the solutions may all tie = together with this discussion - or there may be better/more elegant solutions = others would like to propose). -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE = IETF' Subject: RE: [mile] IOCs > I like this discussion. > I agree, it would be good idea to have indicator identifiers inside=20 > the IOC-related classes. KMM: At the class level, we may have several indicators listed that = should be viewed as a set and may have another instance of that same class that = is a related issue, but a separate set. We could as you say, list the indicator IDs connected through the reference class. The set IDs might = give us other ways to group the values when we get into logic and = relationships between sets or indicators. This could also be a way to connect = indicators or sets across XML documents that could have been shared previously. If there are a large number of indicators in the set, then this becomes = useful, for smaller sets, I agree it doesn't make as much sense. What do others think? >> Then for indicators not included in the base schema that may not fit=20 >> into a category in the SCI draft, do we create a place for these off=20 >> of SCI or right off of the IODE schema in EventData? (more details on = >> this in my first message). > > If we could see any indicator of compromise as computer event record,=20 > we could use SCI:EventReport class as the place for the XML-based IOCs = > that couldn't fit anywhere else. KMM: That sounds like a good idea to me. This should go into guidance = in the SCI draft. Does anyone else want to weigh in? > > For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! > I agree to have indicator_uid, but I am not sure about the needs of=20 > the indicator_set_id. > I understand we could do some grouping of individual indicator_uids=20 > and its usability, but I am not sure whether we do not have any other=20 > way to express these groupings. > For instance, a Reference class refers to several indicadtor_uids. In = > this case, they could be, in a sense, grouped. Isn't it enough? KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets? Would this happen? Would it be easier to express relationships with sets of = indicators in addition to individual indicators? By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current = structure. If there are better ways to handle that, and others can provide some options, that would be appreciated!=20 Thank you, Kathleen > I would appreciate if anybody could share expertise on this. Though I=20 > think I have read all the emails in the list, I might have=20 > mis-understood some points. > > By the way, I think the indicator_uids should be added to the SCI = classes' > attributes so that they can be correlated with another information as well. > > Thanks > Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs I think some sort of group ID would do the trick. We also need a logical = and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have = the same group ID since they are related.=20 Thanks, --Chris From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? = =A0This would allow you to group indicators that are related into the same group = ID. =A0Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) = class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. =A0I = don't mean a place to put indicators that are missing from IODEF.I mean a place in = the IODEF document where you put the indicators that are used for detection = and prevention of the shared Incident. =A0I don't know the answer here, but = there has got to be a good way for indicators to be identified and being able = to group them as Chris has suggested without basically recreating something complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e:=A0paul.stoecker@rsa.com From: , Kathleen Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" , MILE = IETF Subject: Re: [mile] IOCs Hi Chris, =A0 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =A0 The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including = indicators and sets of indicators in IODE documents as opposed to 'parts of an = incident or the useful information on an incident for sharing purposes.=A0 It was written before we used terms like indicators.=A0 With that in mind, = Rosella proposed a number of changes back in July, both for guidance and for = format updates.=A0 It may help to have the first draft try to address at least = some of these issues so people can understand the problems and at least a proposed solution. =A0 As you point out, we need to be able to show relationships between sets = of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document.=A0 In the July = presentation, one of the questions was to see if we should add new category attribute = values for the System class that would connect the list of included = indicators.=A0 I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type = of attack.=A0 Rosella had suggested pulling forward the "FraudType" from = RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some = broader term).=A0 It may be better to have the FraudTypes, plus attribute values = like "C2-server", "sinkhole",=A0 "MalwareDistribution" for added context so = you know what to do with the received set of indicators. =A0 I am proposing that we change IODEF to include multiple sets of = indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared = into the base IODEF. =A0 Back in July, we talked about adding Registry Key/Value pairs and hashes = to the main IODEF document (trying to see if this will help Chris = below).=A0 What if we added the Registry Key/Value pairs as a class off of RecordData, = using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData?=A0 I think if we then had the = indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with = Node inside of the System class, using the indicator_uid to tie the set together.=A0 Then at the more specific level for the hash, registry = Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well?=A0 Maybe we want indicator_set at the higher level?=A0 I'd like = some opinions on this approach.=A0 +1 if you agree, suggestions if you have = other ideas that may work better. =A0 We'll also need to worry about marking the indicators to prevent forward sharing when not permitted.=A0 We may want to use these values or = something else.=A0=20 =A0 Thank you! Kathleen=A0=20 =A0 From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =A0 I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show are related: =A0 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the = file uses. Either or both may be present to indicate a compromise.=20 =A0 Two or more indicators of the same type that relate to the same threat:=20 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be = present.=20 =A0 The problem compounds itself very quickly. Consider the scenario where = both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple = IODEF messages for this from what I remember reading.=20 =A0 The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It's not uncommon to send both the = MD5 and SHA1 hash of a malicious file. The indicator is the file but the = IOCs are the 2 hash values. How do we show they are related? If we use a = unique Inidcator ID for each hash value there needs to be a higher level = grouping.=20 =A0 Thoughts? =A0 Thanks, =A0 --Chris =A0 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =A0 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =A0 All -=20 =A0 I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. =A0 Interesting point, C. Henry.=A0 Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. =A0 Paul mentioned the need to distinguish indicators of compromise from = context information that may also include IP address or other data that could be indicators.=A0 The question I raised was on how to connect sets of = indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. =A0 If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators?=A0 Do we use this to mark = who sent the indicator as well so that we can prevent forward sharing when = it is not permitted or handle that separately?=A0=20 =A0 Then for indicators not included in the base schema that may not fit = into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my = first message). =A0 Comments and questions encouraged to figure out the right technical = solution to have this machine automatable. =A0 Thank you, Kathleen =A0 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =A0 Temporal Dependency sounds interesting.=A0 I remember when I first ran = across this particular craft, an experienced colleague asked me a peculiar question.=A0 He said, " How do you stop someone from tracking the IP = Address to your computer?"=A0=20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off=A0 and the modem that it is connected- which is constantly on!"=A0=A0 LOL Here's my point (Hypothetical Situation) :=A0 There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or = let's just say "Live" Terrorist Situation.=A0 He /or She needs to = communication back to other Officials that he /or somehow is in Danger.=A0 The device used = to communicate has been captured by the great minds of the enemy.=A0 It's = only a matter of time before they utilize reverse engineering to figure out how = it functions.=A0 However, their pride comes before a fall when seeking the location of other similar devices to attack.=A0 Why? Perhaps the less = thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the = original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle=A0 dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrote: > Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider = to a degree what appears to be illogical in brilliant minds in some = instances." >=20 > However, I see Dr. Stoecker's point a little clearer.=A0 However, it=20 > would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different=20 > perspective=A9let's say I get an XML document that tells me about an=20 > incident.=A0 This document has source IP and destination IP that is=20 > being shared.=A0 However, what I don't know is which IP address is my=20 > indicator and which is just a contextual piece of information.=A0 This = > means that my detection product isn't going to know which one to use=20 > either, because there is nothing to tell me which IP is the one, even=20 > if the roles are set it still might not be enough to tell my system = which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow=20 > us to easily identify indicators from contextual data.=A0 I do admit = to=20 > being biased as I have spent much of my career working on the=20 > monitoring and detection side of these things, so I am just thinking=20 > of ways to make it very clear what the indicators are in the XML=20 > document and the other data that may be important as I investigate=20 > activity that I have detected off of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more=20 > flexibility with the indicator_uid.=A0 One thing that I haven't=20 > considered is the UID portion of this=A9how do we use that UID?=A0 How = is=20 > the UID created?=A0 Are there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the=20 > many avenues you review with this approach at once.=A0 However,=A0 could you = share a few advantages and disadvantages to the latter? >=20 > -------------------------------------------------------------------------= --- ---------------------------------------------- > "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via = SCI." >=20 > -------------------------------------------------------------------------= --- --------------------------------------------- >=20 > You pointed out what you consider to be logical places, but if I=20 > wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears = to be illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen = wrote: >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this.=A0 We have a few considerations in=20 > this email thread I would like to hear thoughts on (and there may be more = once RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for=20 > non-XML extensions.=A0 Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about = the included data in most cases.=A0=20 >=20 > The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on = the report as a whole.=A0 Extensions related to impact would be one level = higher (at the moment) in the Assessment class using the AdditionalData = extension point.=A0=20 >=20 > Take asked about including vulnerability information, I would think=20 > that would fit under the Vulnerability extension point of the SCI draft in = the Method class.=A0 He did ask about non-XML.=A0 RecordItem or = AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come = directly off the AdditionalData or RecordItem classes according to what makes = sense from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the=20 > various indicators they share.=A0 If we are extending to embed other schemas = that include such reference or GUID identifiers, do we want to add an = attribute to the various elements in IODEF that could be indicators?=A0 Is this = enough to make the connections or is something else else needed?=A0 We could = add something like an Indicator_ID in RFC5070-bis which would then correlate = to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not=20 > in the base schema that may be related or have language with "and" "or" to specify the relationships.=A0 In some cases, you will want to group = these indictors in one extension point, where they may fit logically in = multiple places if the relationships did not need to be shown in the data = format.=A0 If we have cases like this where you need more complex representations, = should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point?=A0 Opinions are needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document.=A0 We could have a catch-all = class that does this and has an extension point off of it in EventData or we = could continue to group items in logical places as is done now in IODEF and = then have the extension point for combined indicators via SCI.=A0 I think I = like the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C.=20 > Henry Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= --- -------------------------- > 1) If the indicators are something like an XML-based alert/warning of=20 > information leakage, it could be an event that are conveyed in the=20 > SCI's EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it=20 > could be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey=20 > the indicators. > We could for instance extend the list of indicators of the Impact=20 > class, if > needed. > -------------------------------------------------------------------------= --- -------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > -------------------------------------------------------------------------= --- ------------------------- > For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so = that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --- ------------------------ >=20 > Kathleen thoughts related yet still with other indicators and the EventData Class. >=20 > Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify = this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited distribution within = the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile =A0 ------=_NextPart_000_0556_01CE053C.F7C543C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMDcx OTExMDVaMCMGCSqGSIb3DQEJBDEWBBR0eU9U7+iJ2nI46oXUaA8eo0CyATCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAXl71eRiDWeP8a8/wHrdeJpdJ9Etn4BPjCD69TekwLEVu9Z04Uyj6i34toNJkNHur 3qcUHHPnNP6GqJqi5JGQKBYLSGEICVincjATe6xsZ3RbqLSRK5hmYCBFsr9WL1l67Le6VkNiKgmM Uo2MRDf7eXVIx3lwIK373H0ptX1YpDfOuqbzWuMQ+eNB/bAhE7XIlrSkWSr0XkPvGEpKrbhIlqsp IEsAOhKg1K+/EhTr1V3ZWl3gaXl7JcAVcNK1Kk5Agkbj2L7JgG0fbObDZPr85SBYHHIJLCs/3SgE viy3UrhtkiSfOOfJbYiQl7m3eXvByrcxnoOK2k98ct0aFvVUAwAAAAAAAA== ------=_NextPart_000_0556_01CE053C.F7C543C0-- From kathleen.moriarty@emc.com Fri Feb 8 07:28:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01D21F8AAC for ; Fri, 8 Feb 2013 07:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8v4dPZRgArW for ; Fri, 8 Feb 2013 07:28:41 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 403B521F8A5E for ; Fri, 8 Feb 2013 07:28:40 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r18FSdSs008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Feb 2013 10:28:39 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 8 Feb 2013 10:28:31 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r18FSTaD023320 for ; Fri, 8 Feb 2013 10:28:30 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Fri, 8 Feb 2013 10:28:29 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Fri, 8 Feb 2013 10:28:27 -0500 Thread-Topic: Next Meeting & important dates Thread-Index: Ac4GEPFD+uvSUL8qQ+ecC9s5pspWXw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CEBDED4AMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Next Meeting & important dates X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 15:28:42 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CEBDED4AMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The next MILE meeting has been scheduled for Wednesday March 13, 2013 from = 13:00-15:00 EDT (Note: we switch to daylight savings time on March 10th) in= Orlando, Florida. https://www.ietf.org/ Important dates: * 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) s= ubmission by UTC 24:00, upload using IETF ID Submission Tool. * 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:0= 0, upload using IETF ID Submission Tool. MeetEcho will be available. Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24CEBDED4AMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
The next MILE meeting has been scheduled for Wednesday March 13, 2013 = from 13:00-15:00 EDT (Note: we switch to daylight savings time on March 10<= font size=3D"1">th) in Orlando, Florida.
 
Important dates:
·  2013-02-18 (Mond= ay): Internet Draft Cut-off for initial document (-00) submission by UT= C 24:00, upload using IETF ID Submission Tool.
·  2013-02-25 (Mond= ay): Internet Draft final submission cut-off by UTC 24:00, upload using= <= u>IETF ID Submission Tool.
 
MeetEcho will be available.
 
Best regards,
Kathleen
 
--_000_F5063677821E3B4F81ACFB7905573F24CEBDED4AMX15Acorpemccom_-- From eburger-l@standardstrack.com Sat Feb 9 04:47:35 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7C621F861B for ; Sat, 9 Feb 2013 04:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnKSWTq5Z+-U for ; Sat, 9 Feb 2013 04:47:35 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0113E21F85EE for ; Sat, 9 Feb 2013 04:47:34 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53420 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U49pz-0007mi-1Q; Sat, 09 Feb 2013 04:47:23 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <1359995713.43811.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Sat, 9 Feb 2013 07:47:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D1D34FD-4BA6-4532-856F-F4423C830869@standardstrack.com> References: <1359995713.43811.YahooMailClassic@web121602.mail.ne1.yahoo.com> To: C. Henry Adams & BIE X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: MILE IETF Subject: Re: [mile] C. Henry's Analytical Attack X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 12:47:35 -0000 By "this attack", I was talking about attacks on MILE, not attacks on = you. Apologies if it was interpreted that way. As Kathleen stated, this would be the thread to enumerate the possible = attack vectors to MILE. Not being chartered for security is not the = same as ignoring security. All IETF documents post 1997 must discuss = the security implications of whatever is described in the document. The = reason for moving this discussion to a difference subject is that people = uninterested in the discussion can quickly delete the messages and = people interested can contribute here. That is the best of both worlds. So, what attacks to you see? It would be helpful if you could be more = specific than saying a bad person steals a device. We would need to = know what they would do with the device to attack the system. On Feb 4, 2013, at 11:35 AM, C. Henry Adams & BIE = wrote: > Greetings Eric, >=20 > [snip] >=20 > --- On Mon, 2/4/13, Eric Burger wrote: >=20 > From: Eric Burger > Subject: C. Henry's Analytical Attack > To: "C. Henry Adams & BIE" > Cc: "MILE IETF" > Date: Monday, February 4, 2013, 6:18 AM >=20 > I am not quite sure this attack is relevant in the MILE use case. I = would be curious if you could explain in further detail how you would = disrupt MILE communications. If there is a fatal flaw (beyond the known = flaws in TCP), it would be good to get them out in the open. >=20 > Considering the Computer Science perspective, if we are modeling a = complex world, our model will be complex. Check out McCabe. However, = one can add more complexity than necessary to model our domain. That is = what we seek to avoid here. >=20 > Note that I changed the subject of the thread, as this has nothing to = do with indicator correlation. >=20 > On Feb 1, 2013, at 2:24 PM, C. Henry Adams & BIE = wrote: > [snip] > > Furthermore, if I was to tell you that a "Simple Minded Computer = Technician" like myself could figure out analytically how to attack your = indicators to set up a simple plan to disable your automated machine's = communications, would you not believe me? Oh, one more thing, the fact = of the matter that the capabilities would be there- would be based on = say the protocol you put into place by complexity rather than = simplicity. > [snip] > > From: > > "Harrington, Christopher" > > To: > > "Moriarty, Kathleen" , "MILE IETF" = > > Message contains attachments > > 1 File (7KB) > > =95 smime.p7s > > I think we have a bigger relationship issue to address. Let use the = Watchlist Use Case. A bunch of indicators are sent in one message. In = that message we could have groupings of indicators that we need to show = are related: > >=20 > > =20 > > Two or more indicators of different type that relate to the same = threat: > >=20 > > The file hash of a malicious file and the URL of the C2 that the = file uses. Either or both may be present to indicate a compromise. > >=20 > > =20 > > Two or more indicators of the same type that relate to the same = threat: > >=20 > > 2 different registry values for the same registry key. If either = value is present it is a compromise indicator but both will not be = present. > >=20 > > =20 > > The problem compounds itself very quickly. Consider the scenario = where both groupings above are part of the same threat. I need to show = that logical groupings of Indicators are related as well. We can=92t = send multiple IODEF messages for this from what I remember reading. > >=20 > > =20 > > The last one I can think of would be when you have 2 different = indicators that represent the same indicator. It=92s not uncommon to = send both the MD5 and SHA1 hash of a malicious file. The indicator is = the file but the IOCs are the 2 hash values. How do we show they are = related? If we use a unique Inidcator ID for each hash value there needs = to be a higher level grouping. > > [snip] From takeshi_takahashi@nict.go.jp Tue Feb 12 01:20:43 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC01021F8BE9 for ; Tue, 12 Feb 2013 01:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.84 X-Spam-Level: *** X-Spam-Status: No, score=3.84 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FRT_STOCK2=3.988, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jdbOQz53ycn for ; Tue, 12 Feb 2013 01:20:41 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3021F8AE7 for ; Tue, 12 Feb 2013 01:20:40 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r1C9KY0q026398; Tue, 12 Feb 2013 18:20:34 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r1C9KYXL018934; Tue, 12 Feb 2013 18:20:34 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r1C9KX8i018931; Tue, 12 Feb 2013 18:20:33 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id C0BD62C4A1; Tue, 12 Feb 2013 18:20:33 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail1.nict.go.jp (NICT Mail) with ESMTP id B76202C49C; Tue, 12 Feb 2013 18:20:33 +0900 (JST) From: "Takeshi Takahashi" To: "'Harrington, Christopher'" , "'Moriarty, Kathleen'" , "'Stoecker, Paul'" , "'MILE IETF'" References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> In-Reply-To: Date: Tue, 12 Feb 2013 18:20:31 +0900 Message-ID: <005101ce0902$34aed260$9e0c7720$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBgCtxHytwJEdcHEAmgDEnOXvLbGAA== Content-Language: ja Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 09:20:43 -0000 Regarding the indicator_set_id, I agree, it is useful when we need to = deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be = omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence = attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? = For instance, 1 means "no confidence" while 5 means "strong confidence", = etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have = seen > and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute = would > be > beneficial as making those associations is not a perfect science by = any > means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a = few > others on their use cases and would like more opinions. I'll provide > an > option below from what we have discussed from a CIRC view point. We = are > also wondering how to also provide logic in IODEF that could cross = over > into > SCI attached schemas or IODEF extensions (the solutions may all tie > together > with this discussion - or there may be better/more elegant solutions > others > would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that = should > be viewed as a set and may have another instance of that same class = that > is > a related issue, but a separate set. We could as you say, list the > indicator IDs connected through the reference class. The set IDs = might > give > us other ways to group the values when we get into logic and = relationships > between sets or indicators. This could also be a way to connect > indicators > or sets across XML documents that could have been shared previously. = If > there are a large number of indicators in the set, then this becomes > useful, > for smaller sets, I agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not = fit > >> into a category in the SCI draft, do we create a place for these = off > >> of SCI or right off of the IODE schema in EventData? (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event = record, > > we could use SCI:EventReport class as the place for the XML-based = IOCs > > that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me. This should go into guidance > in > the SCI draft. Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids > > and its usability, but I am not sure whether we do not have any = other > > way to express these groupings. > > For instance, a Reference class refers to several indicadtor_uids. > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or > subsequent messages that add indicators to existing sets? Would this > happen? Would it be easier to express relationships with sets of > indicators > in addition to individual indicators? By using this, it could give us > a > unique way to also provide the logic and relationships in a new class > of > IODEF so we don't have to worry about adding it into the current structure. > If there are better ways to handle that, and others can provide some > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information = as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a = logical > and > / or somewhere to show relationship between indicators. If I give you > 2 > registry keys do they both have to be present to be an indication of > compromise or is either one by themselves an indicator? Both would = have > the > same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid? = =A0This > would allow you to group indicators that are related into the same = group > ID. > =A0Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators) > class > that will should be used to take all of the indicators put them into = one > place and have the ability to group the ones that go together. =A0I = don't > mean > a place to put indicators that are missing from IODEF.I mean a place = in > the > IODEF document where you put the indicators that are used for = detection > and > prevention of the shared Incident. =A0I don't know the answer here, = but > there > has got to be a good way for indicators to be identified and being = able > to > group them as Chris has suggested without basically recreating = something > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e:=A0paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE > IETF > > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to = the > definitions in RFC5070-bis, to be more explicit about including > indicators > and sets of indicators in IODE documents as opposed to 'parts of an > incident > or the useful information on an incident for sharing purposes.=A0 It = was > written before we used terms like indicators.=A0 With that in mind, = Rosella > proposed a number of changes back in July, both for guidance and for format > updates.=A0 It may help to have the first draft try to address at = least > some > of these issues so people can understand the problems and at least a > proposed solution. >=20 > As you point out, we need to be able to show relationships between = sets > of > indicators, where we may have a few sets of indicators that could have > a > relationship to each other within a document.=A0 In the July = presentation, > one > of the questions was to see if we should add new category attribute = values > for the System class that would connect the list of included > indicators.=A0 I > think we should still keep the concept of a Node to a single node, but > perhaps within System, list multiple sets of Nodes that may be one = type > of > attack.=A0 Rosella had suggested pulling forward the "FraudType" from > RFC5901, > this would help solve the issue as NodeRole values would compliment an > AttackType (FraudType values could be included in AttackType or some > broader > term).=A0 It may be better to have the FraudTypes, plus attribute = values > like > "C2-server", "sinkhole",=A0 "MalwareDistribution" for added context so > you > know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect > indicators and indicator sets within an IODEF using an attribute of > indicator_uid (or some other name) with a string value to make the > connection points, and add a few indicators that are commonly shared = into > the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and = hashes > to > the main IODEF document (trying to see if this will help Chris > below).=A0 What > if we added the Registry Key/Value pairs as a class off of RecordData, > using > a similar structure to what is in RFC5901, and also added the ability > to > include hashes in RecordData?=A0 I think if we then had the = indicator_uid > at > the RecordData level, we could connect a set within that structure and > repeat the structure for other sets in the same way we would do with = Node > inside of the System class, using the indicator_uid to tie the set > together.=A0 Then at the more specific level for the hash, registry > Key/value, > IP, etc. use an indicator_uid if we needed them marked at this level = as > well?=A0 Maybe we want indicator_set at the higher level?=A0 I'd like = some > opinions on this approach.=A0 +1 if you agree, suggestions if you have = other > ideas that may work better. >=20 > We'll also need to worry about marking the indicators to prevent = forward > sharing when not permitted.=A0 We may want to use these values or = something > else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the > Watchlist Use Case. A bunch of indicators are sent in one message. In > that > message we could have groupings of indicators that we need to show are > related: >=20 > Two or more indicators of different type that relate to the same = threat: > The file hash of a malicious file and the URL of the C2 that = the > file > uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same = threat: > 2 different registry values for the same registry key. If = either > value is present it is a compromise indicator but both will not be present. >=20 > The problem compounds itself very quickly. Consider the scenario where > both > groupings above are part of the same threat. I need to show that = logical > groupings of Indicators are related as well. We can't send multiple = IODEF > messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different = indicators > that represent the same indicator. It's not uncommon to send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the = IOCs > are the 2 hash values. How do we show they are related? If we use a = unique > Inidcator ID for each hash value there needs to be a higher level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center > EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from = the > list on options to help solve the problems raised in my message and > additionally in Paul's message. >=20 > Interesting point, C. Henry.=A0 Our objective here is to have machine > automated exchanges, so we rely on encryption rather than obfuscation > to > achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from > context > information that may also include IP address or other data that could > be > indicators.=A0 The question I raised was on how to connect sets of > indicators > in the same IODEF document, assuming the ability to have watchlists = that > could have several sets of indicators included, as well as to connect > indicators that may be included in embedded schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say > 'indicator-uid' how do we mark the indicators?=A0 Do we use this to = mark > who > sent the indicator as well so that we can prevent forward sharing when > it is > not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit = into > a > category in the SCI draft, do we create a place for these off of SCI = or > right off of the IODE schema in EventData? (more details on this in my > first > message). >=20 > Comments and questions encouraged to figure out the right technical > solution > to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting.=A0 I remember when I first ran > across > this particular craft, an experienced colleague asked me a peculiar > question.=A0 He said, " How do you stop someone from tracking the IP = Address > to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off=A0 and the modem that it is > connected- which is constantly on!"=A0=A0 LOL >=20 > Here's my point (Hypothetical Situation) :=A0 There is a 1st Responder > searching a Neighborhood for Survivors which were hit by a Disaster or > let's > just say "Live" Terrorist Situation.=A0 He /or She needs to = communication > back > to other Officials that he /or somehow is in Danger.=A0 The device = used > to > communicate has been captured by the great minds of the enemy.=A0 It's = only > a > matter of time before they utilize reverse engineering to figure out = how > it > functions.=A0 However, their pride comes before a fall when seeking = the > location of other similar devices to attack.=A0 Why? Perhaps the less > thought > of concepts that makes the device function properly, saves the day by > disguise or cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the = original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM > UID could be mirrored with DNS SEC a pemanent and temporal key, with a > temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle=A0 dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way = was > closely related to what I attempted to express when I stated, = "consider > to a > degree what appears to be illogical in brilliant minds in some = instances." > > > > However, I see Dr. Stoecker's point a little clearer.=A0 However, it > > would > be nice if the UID was in some way disguised from those who study this > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=A9let's say I get an XML document that tells me about an > > incident.=A0 This document has source IP and destination IP that is > > being shared.=A0 However, what I don't know is which IP address is = my > > indicator and which is just a contextual piece of information.=A0 = This > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, = even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would = allow > > us to easily identify indicators from contextual data.=A0 I do admit = to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid.=A0 One thing that I haven't > > considered is the UID portion of this=A9how do we use that UID?=A0 = How is > > the UID created?=A0 Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once.=A0 However,=A0 could = you share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now = in > IODEF and then have the extension point for combined indicators via = SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what = appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this.=A0 We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more = once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions.=A0 Where you place the extensions should be specific to = the > logical grouping of the parent elements so you can understand more = about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating = on > the > report as a whole.=A0 Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData = extension > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class.=A0 He did ask about non-XML.=A0 RecordItem or = AdditionalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come = directly > off the AdditionalData or RecordItem classes according to what makes = sense > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share.=A0 If we are extending to embed other schemas = that > include such reference or GUID identifiers, do we want to add an = attribute > to the various elements in IODEF that could be indicators?=A0 Is this = enough > to make the connections or is something else else needed?=A0 We could = add > something like an Indicator_ID in RFC5070-bis which would then = correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are = not > > in > the base schema that may be related or have language with "and" "or" = to > specify the relationships.=A0 In some cases, you will want to group = these > indictors in one extension point, where they may fit logically in = multiple > places if the relationships did not need to be shown in the data > format.=A0 If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData = class > AdditionalData extension point?=A0 Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document.=A0 We could have a catch-all = class > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI.=A0 I think I = like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning = of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so = that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 From kathleen.moriarty@emc.com Tue Feb 12 04:04:06 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43F521F8D2B for ; Tue, 12 Feb 2013 04:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vCbUbNc6DyD for ; Tue, 12 Feb 2013 04:04:04 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 045B221F8D2E for ; Tue, 12 Feb 2013 04:04:00 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CC3u57021064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 07:03:56 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 12 Feb 2013 07:03:37 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CC3bQV029363; Tue, 12 Feb 2013 07:03:37 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Tue, 12 Feb 2013 07:03:37 -0500 From: "Moriarty, Kathleen" To: Takeshi Takahashi , "Harrington, Christopher" , "Stoecker, Paul" , "'MILE IETF'" Date: Tue, 12 Feb 2013 07:03:35 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBgCtxHytwJEdcHEAmgDEnOXvLbGAIAALzcg Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> <005101ce0902$34aed260$9e0c7720$@nict.go.jp> In-Reply-To: <005101ce0902$34aed260$9e0c7720$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 12:04:06 -0000 Hi Take, Great! As for Confidence, if you look at the current schema, you can list it as ei= ther low, medium, high or provide a numerical value (I think) between 0-100= . Paul is working to get a draft out soon so you and others can look at it an= d review/comment and we'll see what else requires adjustment. Thank you, Kathleen -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF= ' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs > > With respect to tying things back to threat actors, from what I have seen > and use this is a generally accepted grouping: > > Indicator --> Indictor Set --> Campaign --> Threat Actor > > Campaign and Threat Actor are where having a "Confidence" attribute would > be > beneficial as making those associations is not a perfect science by any > means. > > Thanks, > > --Chris > > > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs > > Hi Take & others, > > Thanks for chiming in, I've been talking about this with Chris and a few > others on their use cases and would like more opinions. I'll provide > an > option below from what we have discussed from a CIRC view point. We are > also wondering how to also provide logic in IODEF that could cross over > into > SCI attached schemas or IODEF extensions (the solutions may all tie > together > with this discussion - or there may be better/more elegant solutions > others > would like to propose). > > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE > IETF' > Subject: RE: [mile] IOCs > > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside > > the IOC-related classes. > > KMM: At the class level, we may have several indicators listed that shoul= d > be viewed as a set and may have another instance of that same class that > is > a related issue, but a separate set. We could as you say, list the > indicator IDs connected through the reference class. The set IDs might > give > us other ways to group the values when we get into logic and relationship= s > between sets or indicators. This could also be a way to connect > indicators > or sets across XML documents that could have been shared previously. If > there are a large number of indicators in the set, then this becomes > useful, > for smaller sets, I agree it doesn't make as much sense. > > What do others think? > > >> Then for indicators not included in the base schema that may not fit > >> into a category in the SCI draft, do we create a place for these off > >> of SCI or right off of the IODE schema in EventData? (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event record, > > we could use SCI:EventReport class as the place for the XML-based IOCs > > that couldn't fit anywhere else. > > KMM: That sounds like a good idea to me. This should go into guidance > in > the SCI draft. Does anyone else want to weigh in? > > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! > > > I agree to have indicator_uid, but I am not sure about the needs of > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids > > and its usability, but I am not sure whether we do not have any other > > way to express these groupings. > > For instance, a Reference class refers to several indicadtor_uids. > In > > this case, they could be, in a sense, grouped. Isn't it enough? > > KMM: It may be, what do you think about large sets of indicators or > subsequent messages that add indicators to existing sets? Would this > happen? Would it be easier to express relationships with sets of > indicators > in addition to individual indicators? By using this, it could give us > a > unique way to also provide the logic and relationships in a new class > of > IODEF so we don't have to worry about adding it into the current structure. > If there are better ways to handle that, and others can provide some > options, that would be appreciated! > > Thank you, > Kathleen > > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information as > well. > > > > Thanks > > Take > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs > > I think some sort of group ID would do the trick. We also need a logical > and > / or somewhere to show relationship between indicators. If I give you > 2 > registry keys do they both have to be present to be an indication of > compromise or is either one by themselves an indicator? Both would have > the > same group ID since they are related. > > Thanks, > --Chris > > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs > > What if we added indicator group ID along with the indicator_uid? This > would allow you to group indicators that are related into the same group > ID. > Would this resolve the issue? > > It is either that or going back to adding a Detection (or Indicators) > class > that will should be used to take all of the indicators put them into one > place and have the ability to group the ones that go together. I don't > mean > a place to put indicators that are missing from IODEF.I mean a place in > the > IODEF document where you put the indicators that are used for detection > and > prevention of the shared Incident. I don't know the answer here, but > there > has got to be a good way for indicators to be identified and being able > to > group them as Chris has suggested without basically recreating something > complicated like STIX. > > Paul > > > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE > IETF > > Subject: Re: [mile] IOCs > > Hi Chris, > > I agree, we have some work to do in the updated IODEF, RFC5070-bis. > > The list has already said they would like to see indicators added to the > definitions in RFC5070-bis, to be more explicit about including > indicators > and sets of indicators in IODE documents as opposed to 'parts of an > incident > or the useful information on an incident for sharing purposes. It was > written before we used terms like indicators. With that in mind, Rosella > proposed a number of changes back in July, both for guidance and for format > updates. It may help to have the first draft try to address at least > some > of these issues so people can understand the problems and at least a > proposed solution. > > As you point out, we need to be able to show relationships between sets > of > indicators, where we may have a few sets of indicators that could have > a > relationship to each other within a document. In the July presentation, > one > of the questions was to see if we should add new category attribute value= s > for the System class that would connect the list of included > indicators. I > think we should still keep the concept of a Node to a single node, but > perhaps within System, list multiple sets of Nodes that may be one type > of > attack. Rosella had suggested pulling forward the "FraudType" from > RFC5901, > this would help solve the issue as NodeRole values would compliment an > AttackType (FraudType values could be included in AttackType or some > broader > term). It may be better to have the FraudTypes, plus attribute values > like > "C2-server", "sinkhole", "MalwareDistribution" for added context so > you > know what to do with the received set of indicators. > > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect > indicators and indicator sets within an IODEF using an attribute of > indicator_uid (or some other name) with a string value to make the > connection points, and add a few indicators that are commonly shared into > the base IODEF. > > Back in July, we talked about adding Registry Key/Value pairs and hashes > to > the main IODEF document (trying to see if this will help Chris > below). What > if we added the Registry Key/Value pairs as a class off of RecordData, > using > a similar structure to what is in RFC5901, and also added the ability > to > include hashes in RecordData? I think if we then had the indicator_uid > at > the RecordData level, we could connect a set within that structure and > repeat the structure for other sets in the same way we would do with Node > inside of the System class, using the indicator_uid to tie the set > together. Then at the more specific level for the hash, registry > Key/value, > IP, etc. use an indicator_uid if we needed them marked at this level as > well? Maybe we want indicator_set at the higher level? I'd like some > opinions on this approach. +1 if you agree, suggestions if you have othe= r > ideas that may work better. > > We'll also need to worry about marking the indicators to prevent forward > sharing when not permitted. We may want to use these values or something > else. > > Thank you! > Kathleen > > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs > > I think we have a bigger relationship issue to address. Let use the > Watchlist Use Case. A bunch of indicators are sent in one message. In > that > message we could have groupings of indicators that we need to show are > related: > > Two or more indicators of different type that relate to the same threat: > The file hash of a malicious file and the URL of the C2 that the > file > uses. Either or both may be present to indicate a compromise. > > Two or more indicators of the same type that relate to the same threat: > 2 different registry values for the same registry key. If either > value is present it is a compromise indicator but both will not be present. > > The problem compounds itself very quickly. Consider the scenario where > both > groupings above are part of the same threat. I need to show that logical > groupings of Indicators are related as well. We can't send multiple IODEF > messages for this from what I remember reading. > > The last one I can think of would be when you have 2 different indicators > that represent the same indicator. It's not uncommon to send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the IOCs > are the 2 hash values. How do we show they are related? If we use a uniqu= e > Inidcator ID for each hash value there needs to be a higher level grouping. > > Thoughts? > > Thanks, > > --Chris > > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center > EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs > > All - > > I'd like your input and will refocus the thread to get opinions from the > list on options to help solve the problems raised in my message and > additionally in Paul's message. > > Interesting point, C. Henry. Our objective here is to have machine > automated exchanges, so we rely on encryption rather than obfuscation > to > achieve the necessary level of confidentiality. > > Paul mentioned the need to distinguish indicators of compromise from > context > information that may also include IP address or other data that could > be > indicators. The question I raised was on how to connect sets of > indicators > in the same IODEF document, assuming the ability to have watchlists that > could have several sets of indicators included, as well as to connect > indicators that may be included in embedded schemas. > > If we add an attribute on all of the relevant indicators, let's say > 'indicator-uid' how do we mark the indicators? Do we use this to mark > who > sent the indicator as well so that we can prevent forward sharing when > it is > not permitted or handle that separately? > > Then for indicators not included in the base schema that may not fit into > a > category in the SCI draft, do we create a place for these off of SCI or > right off of the IODE schema in EventData? (more details on this in my > first > message). > > Comments and questions encouraged to figure out the right technical > solution > to have this machine automatable. > > Thank you, > Kathleen > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs > > Temporal Dependency sounds interesting. I remember when I first ran > across > this particular craft, an experienced colleague asked me a peculiar > question. He said, " How do you stop someone from tracking the IP Addres= s > to your computer?" > > I replied, "I don't know, how?" > > Then he said, "Cut the dog-gone thing off and the modem that it is > connected- which is constantly on!" LOL > > Here's my point (Hypothetical Situation) : There is a 1st Responder > searching a Neighborhood for Survivors which were hit by a Disaster or > let's > just say "Live" Terrorist Situation. He /or She needs to communication > back > to other Officials that he /or somehow is in Danger. The device used > to > communicate has been captured by the great minds of the enemy. It's only > a > matter of time before they utilize reverse engineering to figure out how > it > functions. However, their pride comes before a fall when seeking the > location of other similar devices to attack. Why? Perhaps the less > thought > of concepts that makes the device function properly, saves the day by > disguise or cutting it off (figuratively speaking). > > Just a visionary thought. > > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com > > > The information contained herein is for the exclusive use of the original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > --- On Mon, 1/28/13, Dave Misell wrote: > > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM > UID could be mirrored with DNS SEC a pemanent and temporal key, with a > temporal Id? > > Yours Faithfully, > > Dave Misell MSc CISSP > SilentCircle dsm > 07710 380044 > david.misell@bcs.org > > > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: > > > Serialization of a particular Lists of XML Classes in a unique way was > closely related to what I attempted to express when I stated, "consider > to a > degree what appears to be illogical in brilliant minds in some instances.= " > > > > However, I see Dr. Stoecker's point a little clearer. However, it > > would > be nice if the UID was in some way disguised from those who study this > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=A9let's say I get an XML document that tells me about an > > incident. This document has source IP and destination IP that is > > being shared. However, what I don't know is which IP address is my > > indicator and which is just a contextual piece of information. This > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would allow > > us to easily identify indicators from contextual data. I do admit to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid. One thing that I haven't > > considered is the UID portion of this=A9how do we use that UID? How is > > the UID created? Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote= : > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once. However, could you share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now in > IODEF and then have the extension point for combined indicators via SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this. We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions. Where you place the extensions should be specific to the > logical grouping of the parent elements so you can understand more about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating on > the > report as a whole. Extensions related to impact would be one level highe= r > (at the moment) in the Assessment class using the AdditionalData extensio= n > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class. He did ask about non-XML. RecordItem or AdditionalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come directl= y > off the AdditionalData or RecordItem classes according to what makes sens= e > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share. If we are extending to embed other schemas that > include such reference or GUID identifiers, do we want to add an attribut= e > to the various elements in IODEF that could be indicators? Is this enoug= h > to make the connections or is something else else needed? We could add > something like an Indicator_ID in RFC5070-bis which would then correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are not > > in > the base schema that may be related or have language with "and" "or" to > specify the relationships. In some cases, you will want to group these > indictors in one extension point, where they may fit logically in multipl= e > places if the relationships did not need to be shown in the data > format. If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData class > AdditionalData extension point? Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document. We could have a catch-all class > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI. I think I like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > From internet-drafts@ietf.org Tue Feb 12 05:14:52 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F50221F8D66; Tue, 12 Feb 2013 05:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXTWyFm4OwwX; Tue, 12 Feb 2013 05:14:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E451B21F8D03; Tue, 12 Feb 2013 05:14:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212131451.1685.33868.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 05:14:51 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-06.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:14:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF-extension to support structured cybersecurity info= rmation Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-06.txt Pages : 32 Date : 2013-02-12 Abstract: This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-sci There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-sci-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-sci-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From takeshi_takahashi@nict.go.jp Tue Feb 12 05:22:49 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BCF21F8AC3 for ; Tue, 12 Feb 2013 05:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.242 X-Spam-Level: * X-Spam-Status: No, score=1.242 tagged_above=-999 required=5 tests=[AWL=2.598, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVdOLMHbJPse for ; Tue, 12 Feb 2013 05:22:49 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id D626C21F8AB6 for ; Tue, 12 Feb 2013 05:22:48 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r1CDMk1f025652 for ; Tue, 12 Feb 2013 22:22:46 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r1CDMkZb027217 for ; Tue, 12 Feb 2013 22:22:46 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r1CDMk4m027214 for ; Tue, 12 Feb 2013 22:22:46 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 3AE0E2C581 for ; Tue, 12 Feb 2013 22:22:46 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 35FF92C45A for ; Tue, 12 Feb 2013 22:22:46 +0900 (JST) From: "Takeshi Takahashi" To: References: <20130212131451.1685.33868.idtracker@ietfa.amsl.com> In-Reply-To: <20130212131451.1685.33868.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 22:22:44 +0900 Message-ID: <006101ce0924$0a8f9e20$1faeda60$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJcvN57mcw8Yv6EdUZXnsSnPgXlpZdYzENw Content-Language: ja Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-06.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:22:49 -0000 Hi all, The updated version of the SCI draft is now available. Major changes. 1. Following the discussion over the mailing list, the normative reference section now has MMDEF 1.2. (See section 12.1) 2. Since MMDEF 1.2 is a specification in the normative reference, the initial entry of the IANA table has MMDEF 1.2. (See section 4.1) 3. The entry listed in the initial IANA table is regarded as the MTI (See section 5) I hope this version correctly reflected the discussion result and addressed the remaining issues of the draft, i.e., MTI and normative reference. I would appreciate very much if I could hear some feedback here. Kind regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, February 12, 2013 10:15 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-sci-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Managed Incident Lightweight Exchange > Working Group of the IETF. > > Title : IODEF-extension to support structured > cybersecurity information > Author(s) : Takeshi Takahashi > Kent Landfield > Thomas Millar > Youki Kadobayashi > Filename : draft-ietf-mile-sci-06.txt > Pages : 32 > Date : 2013-02-12 > > Abstract: > This document extends the Incident Object Description Exchange Format > (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched > cybersecurity information among cybersecurity entities and > facilitate > their operations. It provides the capability of embedding structured > information, such as identifier- and XML-based information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-sci > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-sci-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-sci-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Christopher.Harrington@emc.com Tue Feb 12 06:22:32 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920D21F8E62 for ; Tue, 12 Feb 2013 06:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHLkR+EREZFf for ; Tue, 12 Feb 2013 06:22:30 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 995AD21F8E5E for ; Tue, 12 Feb 2013 06:22:30 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CEMSTW008018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 09:22:29 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 12 Feb 2013 09:22:17 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CEMHI1024726; Tue, 12 Feb 2013 09:22:17 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 12 Feb 2013 09:22:16 -0500 From: "Harrington, Christopher" To: "'Takeshi Takahashi'" , "Moriarty, Kathleen" , "Stoecker, Paul" , "'MILE IETF'" Date: Tue, 12 Feb 2013 09:22:16 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBgCtxHytwJEdcHEAmgDEnOXvLbGAIAAVQIA Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> <005101ce0902$34aed260$9e0c7720$@nict.go.jp> In-Reply-To: <005101ce0902$34aed260$9e0c7720$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01CE0902.723C1D90" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:22:33 -0000 ------=_NextPart_000_0042_01CE0902.723C1D90 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break = it down to more levels than that we would need to provide guidance on = scoring, rating, etc. I think most people should be able to understand = low/med/high without having to have a mathematical method for arriving at the level.=20 Low - I am not sure Medium - I am reasonably sure High - I am very sure=20 Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE = IETF' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to = deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be = omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence = attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? = For instance, 1 means "no confidence" while 5 means "strong confidence", = etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have=20 > seen and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute=20 > would be beneficial as making those associations is not a perfect=20 > science by any means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a=20 > few others on their use cases and would like more opinions. I'll=20 > provide an option below from what we have discussed from a CIRC view=20 > point. We are also wondering how to also provide logic in IODEF that=20 > could cross over into SCI attached schemas or IODEF extensions (the=20 > solutions may all tie together with this discussion - or there may be=20 > better/more elegant solutions others would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE = > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside=20 > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that=20 > should be viewed as a set and may have another instance of that same=20 > class that is a related issue, but a separate set. We could as you=20 > say, list the indicator IDs connected through the reference class. =20 > The set IDs might give us other ways to group the values when we get=20 > into logic and relationships between sets or indicators. This could=20 > also be a way to connect indicators or sets across XML documents that=20 > could have been shared previously. If there are a large number of=20 > indicators in the set, then this becomes useful, for smaller sets, I=20 > agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not=20 > >> fit into a category in the SCI draft, do we create a place for=20 > >> these off of SCI or right off of the IODE schema in EventData?=20 > >> (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event=20 > > record, we could use SCI:EventReport class as the place for the=20 > > XML-based IOCs that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me. This should go into guidance = > in the SCI draft. Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of=20 > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids=20 > > and its usability, but I am not sure whether we do not have any=20 > > other way to express these groupings. > > For instance, a Reference class refers to several indicadtor_uids. > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or=20 > subsequent messages that add indicators to existing sets? Would this=20 > happen? Would it be easier to express relationships with sets of=20 > indicators in addition to individual indicators? By using this, it=20 > could give us a unique way to also provide the logic and relationships = > in a new class of IODEF so we don't have to worry about adding it into = > the current structure. > If there are better ways to handle that, and others can provide some=20 > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have=20 > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information=20 > > as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a=20 > logical and / or somewhere to show relationship between indicators. If = > I give you > 2 > registry keys do they both have to be present to be an indication of=20 > compromise or is either one by themselves an indicator? Both would=20 > have the same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid? =A0 > This would allow you to group indicators that are related into the=20 > same group ID. > =A0Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators)=20 > class that will should be used to take all of the indicators put them=20 > into one place and have the ability to group the ones that go=20 > together. =A0I don't mean a place to put indicators that are missing=20 > from IODEF.I mean a place in the IODEF document where you put the=20 > indicators that are used for detection and prevention of the shared=20 > Incident. =A0I don't know the answer here, but there has got to be a=20 > good way for indicators to be identified and being able to group them=20 > as Chris has suggested without basically recreating something=20 > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e:=A0paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE=20 > IETF > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to=20 > the definitions in RFC5070-bis, to be more explicit about including=20 > indicators and sets of indicators in IODE documents as opposed to=20 > 'parts of an incident or the useful information on an incident for=20 > sharing purposes.=A0 It was written before we used terms like=20 > indicators.=A0 With that in mind, Rosella proposed a number of changes = > back in July, both for guidance and for format > updates.=A0 It may help to have the first draft try to address at = least=20 > some of these issues so people can understand the problems and at=20 > least a proposed solution. >=20 > As you point out, we need to be able to show relationships between=20 > sets of indicators, where we may have a few sets of indicators that=20 > could have a relationship to each other within a document.=A0 In the=20 > July presentation, one of the questions was to see if we should add=20 > new category attribute values for the System class that would connect=20 > the list of included indicators.=A0 I think we should still keep the=20 > concept of a Node to a single node, but perhaps within System, list=20 > multiple sets of Nodes that may be one type of attack.=A0 Rosella had=20 > suggested pulling forward the "FraudType" from RFC5901, this would=20 > help solve the issue as NodeRole values would compliment an AttackType = > (FraudType values could be included in AttackType or some broader=20 > term).=A0 It may be better to have the FraudTypes, plus attribute = values=20 > like "C2-server", "sinkhole",=A0 "MalwareDistribution" for added = context=20 > so you know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect=20 > indicators and indicator sets within an IODEF using an attribute of=20 > indicator_uid (or some other name) with a string value to make the=20 > connection points, and add a few indicators that are commonly shared=20 > into the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and=20 > hashes to the main IODEF document (trying to see if this will help=20 > Chris below).=A0 What if we added the Registry Key/Value pairs as a=20 > class off of RecordData, using a similar structure to what is in=20 > RFC5901, and also added the ability to include hashes in = RecordData?=A0=20 > I think if we then had the indicator_uid at the RecordData level, we=20 > could connect a set within that structure and repeat the structure for = > other sets in the same way we would do with Node inside of the System=20 > class, using the indicator_uid to tie the set together.=A0 Then at the = > more specific level for the hash, registry Key/value, IP, etc. use an=20 > indicator_uid if we needed them marked at this level as well?=A0 Maybe = > we want indicator_set at the higher level?=A0 I'd like some opinions = on=20 > this approach.=A0 +1 if you agree, suggestions if you have other ideas = > that may work better. >=20 > We'll also need to worry about marking the indicators to prevent=20 > forward sharing when not permitted.=A0 We may want to use these values = > or something else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the=20 > Watchlist Use Case. A bunch of indicators are sent in one message. In=20 > that message we could have groupings of indicators that we need to=20 > show are > related: >=20 > Two or more indicators of different type that relate to the same = threat: > The file hash of a malicious file and the URL of the C2 that=20 > the file uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same = threat: > 2 different registry values for the same registry key. If=20 > either value is present it is a compromise indicator but both will not = > be present. >=20 > The problem compounds itself very quickly. Consider the scenario where = > both groupings above are part of the same threat. I need to show that=20 > logical groupings of Indicators are related as well. We can't send=20 > multiple IODEF messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different=20 > indicators that represent the same indicator. It's not uncommon to=20 > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the=20 > IOCs are the 2 hash values. How do we show they are related? If we use = > a unique Inidcator ID for each hash value there needs to be a higher=20 > level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from=20 > the list on options to help solve the problems raised in my message=20 > and additionally in Paul's message. >=20 > Interesting point, C. Henry.=A0 Our objective here is to have machine=20 > automated exchanges, so we rely on encryption rather than obfuscation=20 > to achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from=20 > context information that may also include IP address or other data=20 > that could be indicators.=A0 The question I raised was on how to = connect=20 > sets of indicators in the same IODEF document, assuming the ability to = > have watchlists that could have several sets of indicators included,=20 > as well as to connect indicators that may be included in embedded=20 > schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say=20 > 'indicator-uid' how do we mark the indicators?=A0 Do we use this to = mark=20 > who sent the indicator as well so that we can prevent forward sharing=20 > when it is not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit=20 > into a category in the SCI draft, do we create a place for these off=20 > of SCI or right off of the IODE schema in EventData? (more details on=20 > this in my first message). >=20 > Comments and questions encouraged to figure out the right technical=20 > solution to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting.=A0 I remember when I first ran = > across this particular craft, an experienced colleague asked me a=20 > peculiar question.=A0 He said, " How do you stop someone from tracking = > the IP Address to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off=A0 and the modem that it is > connected- which is constantly on!"=A0=A0 LOL >=20 > Here's my point (Hypothetical Situation) :=A0 There is a 1st Responder = > searching a Neighborhood for Survivors which were hit by a Disaster or = > let's just say "Live" Terrorist Situation.=A0 He /or She needs to=20 > communication back to other Officials that he /or somehow is in=20 > Danger.=A0 The device used to communicate has been captured by the = great=20 > minds of the enemy.=A0 It's only a matter of time before they utilize=20 > reverse engineering to figure out how it functions.=A0 However, their=20 > pride comes before a fall when seeking the location of other similar=20 > devices to attack.=A0 Why? Perhaps the less thought of concepts that=20 > makes the device function properly, saves the day by disguise or=20 > cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited=20 > distribution within the recipient's place of business for planning=20 > purposes only. Further dissemination, whether private or public is=20 > prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS = > SEC a pemanent and temporal key, with a temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle=A0 dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way=20 > > was > closely related to what I attempted to express when I stated,=20 > "consider to a degree what appears to be illogical in brilliant minds=20 > in some instances." > > > > However, I see Dr. Stoecker's point a little clearer.=A0 However, it = > > would > be nice if the UID was in some way disguised from those who study this = > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=A9let's say I get an XML document that tells me about an > > incident.=A0 This document has source IP and destination IP that is > > being shared.=A0 However, what I don't know is which IP address is = my > > indicator and which is just a contextual piece of information.=A0 = This > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, = even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would = allow > > us to easily identify indicators from contextual data.=A0 I do admit = to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid.=A0 One thing that I haven't > > considered is the UID portion of this=A9how do we use that UID?=A0 = How is > > the UID created?=A0 Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once.=A0 However,=A0 could = you share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now = in > IODEF and then have the extension point for combined indicators via = SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what = appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this.=A0 We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more = once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions.=A0 Where you place the extensions should be specific to = the > logical grouping of the parent elements so you can understand more = about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating = on > the > report as a whole.=A0 Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData = extension > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class.=A0 He did ask about non-XML.=A0 RecordItem or = AdditionalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come = directly > off the AdditionalData or RecordItem classes according to what makes = sense > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share.=A0 If we are extending to embed other schemas = that > include such reference or GUID identifiers, do we want to add an = attribute > to the various elements in IODEF that could be indicators?=A0 Is this = enough > to make the connections or is something else else needed?=A0 We could = add > something like an Indicator_ID in RFC5070-bis which would then = correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are = not > > in > the base schema that may be related or have language with "and" "or" = to > specify the relationships.=A0 In some cases, you will want to group = these > indictors in one extension point, where they may fit logically in = multiple > places if the relationships did not need to be shown in the data > format.=A0 If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData = class > AdditionalData extension point?=A0 Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document.=A0 We could have a catch-all = class > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI.=A0 I think I = like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning = of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so = that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 ------=_NextPart_000_0042_01CE0902.723C1D90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTIx NDIyMTVaMCMGCSqGSIb3DQEJBDEWBBQkGmo/aGDfrxSozGvdiEJm0l3TmzCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAXl7/LCntx/ZqJ6XYCLA66uL/eGKhvoGVJIJJgEJ7NcP6CuhhW/gOyPfwwMMK0uTN SyXsgTyo3WImlGgBnK7kGVBbNDML0k2H+LUgYkTsxsnrGZ+7quxOn3pmokiSNhk+URkRMi/Ruc58 PJCUfrOqhpgaDfn/mXbbE6oLOhgQvPX4reE2PSY+STk8CXf5W+utPwYO6WRzaL50wT5qZv6The8g eaBGhI8LDG7AP7TSTybv7Bm0yi0UV9Z6RKzjPhyt99gyAIzzeROJdWbpQdegUXIcXHhSWfNBGhaM Ez7s1j12hZmvCL7ty36AymbeWZfm7KsHkppJUlvOZSOQ8nPK0gAAAAAAAA== ------=_NextPart_000_0042_01CE0902.723C1D90-- From kathleen.moriarty@emc.com Tue Feb 12 06:59:23 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ACB21F8EC2 for ; Tue, 12 Feb 2013 06:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.367 X-Spam-Level: X-Spam-Status: No, score=0.367 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQRIle31h2dq for ; Tue, 12 Feb 2013 06:59:21 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2A30C21F8EC1 for ; Tue, 12 Feb 2013 06:59:19 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CExG8k019034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 09:59:19 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 12 Feb 2013 09:59:04 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CEx3YJ020802; Tue, 12 Feb 2013 09:59:04 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Feb 2013 09:59:03 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 12 Feb 2013 09:59:02 -0500 From: "Moriarty, Kathleen" To: "Harrington, Christopher" , "'Takeshi Takahashi'" , "Stoecker, Paul" , "'MILE IETF'" Date: Tue, 12 Feb 2013 09:59:00 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBgCtxHytwJEdcHEAmgDEnOXvLbGAIAAVQIAgAALC6A= Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> <005101ce0902$34aed260$9e0c7720$@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01CE0907.94961D50" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:59:23 -0000 ------=_NextPart_000_0009_01CE0907.94961D50 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Chris & Take, I'll just focus on the confidence scoring. Right now, the schema allows = for you to either use a numerical score OR the ratings of low, medium, = and high. Different sharing groups can decide how they want to share = the data. If people were to use the numerical values, I agree it would = be helpful to have guidance. This could go in the IODE guidance = document. I have seen examples of current users that use each of the approaches, = so we'll need to keep the option for backwards compatibility and it is = nice to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher=20 Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break = it down to more levels than that we would need to provide guidance on = scoring, rating, etc. I think most people should be able to understand = low/med/high without having to have a mathematical method for arriving at the level.=20 Low - I am not sure Medium - I am reasonably sure High - I am very sure=20 Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE = IETF' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to = deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be = omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence = attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? = For instance, 1 means "no confidence" while 5 means "strong confidence", = etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have=20 > seen and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute=20 > would be beneficial as making those associations is not a perfect=20 > science by any means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a=20 > few others on their use cases and would like more opinions. I'll=20 > provide an option below from what we have discussed from a CIRC view=20 > point. We are also wondering how to also provide logic in IODEF that=20 > could cross over into SCI attached schemas or IODEF extensions (the=20 > solutions may all tie together with this discussion - or there may be=20 > better/more elegant solutions others would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE = > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside=20 > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that=20 > should be viewed as a set and may have another instance of that same=20 > class that is a related issue, but a separate set. We could as you=20 > say, list the indicator IDs connected through the reference class. =20 > The set IDs might give us other ways to group the values when we get=20 > into logic and relationships between sets or indicators. This could=20 > also be a way to connect indicators or sets across XML documents that=20 > could have been shared previously. If there are a large number of=20 > indicators in the set, then this becomes useful, for smaller sets, I=20 > agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not=20 > >> fit into a category in the SCI draft, do we create a place for=20 > >> these off of SCI or right off of the IODE schema in EventData?=20 > >> (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event=20 > > record, we could use SCI:EventReport class as the place for the=20 > > XML-based IOCs that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me. This should go into guidance = > in the SCI draft. Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of=20 > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids=20 > > and its usability, but I am not sure whether we do not have any=20 > > other way to express these groupings. > > For instance, a Reference class refers to several indicadtor_uids. > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or=20 > subsequent messages that add indicators to existing sets? Would this=20 > happen? Would it be easier to express relationships with sets of=20 > indicators in addition to individual indicators? By using this, it=20 > could give us a unique way to also provide the logic and relationships = > in a new class of IODEF so we don't have to worry about adding it into = > the current structure. > If there are better ways to handle that, and others can provide some=20 > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have=20 > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information=20 > > as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a=20 > logical and / or somewhere to show relationship between indicators. If = > I give you > 2 > registry keys do they both have to be present to be an indication of=20 > compromise or is either one by themselves an indicator? Both would=20 > have the same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid? =20 > This would allow you to group indicators that are related into the=20 > same group ID. > Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators)=20 > class that will should be used to take all of the indicators put them=20 > into one place and have the ability to group the ones that go=20 > together. I don't mean a place to put indicators that are missing=20 > from IODEF.I mean a place in the IODEF document where you put the=20 > indicators that are used for detection and prevention of the shared=20 > Incident. I don't know the answer here, but there has got to be a=20 > good way for indicators to be identified and being able to group them=20 > as Chris has suggested without basically recreating something=20 > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE=20 > IETF > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to=20 > the definitions in RFC5070-bis, to be more explicit about including=20 > indicators and sets of indicators in IODE documents as opposed to=20 > 'parts of an incident or the useful information on an incident for=20 > sharing purposes. It was written before we used terms like=20 > indicators. With that in mind, Rosella proposed a number of changes=20 > back in July, both for guidance and for format > updates. It may help to have the first draft try to address at least=20 > some of these issues so people can understand the problems and at=20 > least a proposed solution. >=20 > As you point out, we need to be able to show relationships between=20 > sets of indicators, where we may have a few sets of indicators that=20 > could have a relationship to each other within a document. In the=20 > July presentation, one of the questions was to see if we should add=20 > new category attribute values for the System class that would connect=20 > the list of included indicators. I think we should still keep the=20 > concept of a Node to a single node, but perhaps within System, list=20 > multiple sets of Nodes that may be one type of attack. Rosella had=20 > suggested pulling forward the "FraudType" from RFC5901, this would=20 > help solve the issue as NodeRole values would compliment an AttackType = > (FraudType values could be included in AttackType or some broader=20 > term). It may be better to have the FraudTypes, plus attribute values = > like "C2-server", "sinkhole", "MalwareDistribution" for added context = > so you know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect=20 > indicators and indicator sets within an IODEF using an attribute of=20 > indicator_uid (or some other name) with a string value to make the=20 > connection points, and add a few indicators that are commonly shared=20 > into the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and=20 > hashes to the main IODEF document (trying to see if this will help=20 > Chris below). What if we added the Registry Key/Value pairs as a=20 > class off of RecordData, using a similar structure to what is in=20 > RFC5901, and also added the ability to include hashes in RecordData? =20 > I think if we then had the indicator_uid at the RecordData level, we=20 > could connect a set within that structure and repeat the structure for = > other sets in the same way we would do with Node inside of the System=20 > class, using the indicator_uid to tie the set together. Then at the=20 > more specific level for the hash, registry Key/value, IP, etc. use an=20 > indicator_uid if we needed them marked at this level as well? Maybe=20 > we want indicator_set at the higher level? I'd like some opinions on=20 > this approach. +1 if you agree, suggestions if you have other ideas=20 > that may work better. >=20 > We'll also need to worry about marking the indicators to prevent=20 > forward sharing when not permitted. We may want to use these values=20 > or something else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the=20 > Watchlist Use Case. A bunch of indicators are sent in one message. In=20 > that message we could have groupings of indicators that we need to=20 > show are > related: >=20 > Two or more indicators of different type that relate to the same = threat: > The file hash of a malicious file and the URL of the C2 that=20 > the file uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same = threat: > 2 different registry values for the same registry key. If=20 > either value is present it is a compromise indicator but both will not = > be present. >=20 > The problem compounds itself very quickly. Consider the scenario where = > both groupings above are part of the same threat. I need to show that=20 > logical groupings of Indicators are related as well. We can't send=20 > multiple IODEF messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different=20 > indicators that represent the same indicator. It's not uncommon to=20 > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the=20 > IOCs are the 2 hash values. How do we show they are related? If we use = > a unique Inidcator ID for each hash value there needs to be a higher=20 > level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from=20 > the list on options to help solve the problems raised in my message=20 > and additionally in Paul's message. >=20 > Interesting point, C. Henry. Our objective here is to have machine=20 > automated exchanges, so we rely on encryption rather than obfuscation=20 > to achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from=20 > context information that may also include IP address or other data=20 > that could be indicators. The question I raised was on how to connect = > sets of indicators in the same IODEF document, assuming the ability to = > have watchlists that could have several sets of indicators included,=20 > as well as to connect indicators that may be included in embedded=20 > schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say=20 > 'indicator-uid' how do we mark the indicators? Do we use this to mark = > who sent the indicator as well so that we can prevent forward sharing=20 > when it is not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit=20 > into a category in the SCI draft, do we create a place for these off=20 > of SCI or right off of the IODE schema in EventData? (more details on=20 > this in my first message). >=20 > Comments and questions encouraged to figure out the right technical=20 > solution to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting. I remember when I first ran=20 > across this particular craft, an experienced colleague asked me a=20 > peculiar question. He said, " How do you stop someone from tracking=20 > the IP Address to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off and the modem that it is > connected- which is constantly on!" LOL >=20 > Here's my point (Hypothetical Situation) : There is a 1st Responder=20 > searching a Neighborhood for Survivors which were hit by a Disaster or = > let's just say "Live" Terrorist Situation. He /or She needs to=20 > communication back to other Officials that he /or somehow is in=20 > Danger. The device used to communicate has been captured by the great = > minds of the enemy. It's only a matter of time before they utilize=20 > reverse engineering to figure out how it functions. However, their=20 > pride comes before a fall when seeking the location of other similar=20 > devices to attack. Why? Perhaps the less thought of concepts that=20 > makes the device function properly, saves the day by disguise or=20 > cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited=20 > distribution within the recipient's place of business for planning=20 > purposes only. Further dissemination, whether private or public is=20 > prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS = > SEC a pemanent and temporal key, with a temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way=20 > > was > closely related to what I attempted to express when I stated,=20 > "consider to a degree what appears to be illogical in brilliant minds=20 > in some instances." > > > > However, I see Dr. Stoecker's point a little clearer. However, it=20 > > would > be nice if the UID was in some way disguised from those who study this = > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=A9let's say I get an XML document that tells me about an > > incident. This document has source IP and destination IP that is > > being shared. However, what I don't know is which IP address is my > > indicator and which is just a contextual piece of information. This > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, = even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would = allow > > us to easily identify indicators from contextual data. I do admit = to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid. One thing that I haven't > > considered is the UID portion of this=A9how do we use that UID? How = is > > the UID created? Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once. However, could you = share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now = in > IODEF and then have the extension point for combined indicators via = SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what = appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this. We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more = once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions. Where you place the extensions should be specific to the > logical grouping of the parent elements so you can understand more = about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating = on > the > report as a whole. Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData = extension > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class. He did ask about non-XML. RecordItem or AdditionalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come = directly > off the AdditionalData or RecordItem classes according to what makes = sense > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share. If we are extending to embed other schemas = that > include such reference or GUID identifiers, do we want to add an = attribute > to the various elements in IODEF that could be indicators? Is this = enough > to make the connections or is something else else needed? We could = add > something like an Indicator_ID in RFC5070-bis which would then = correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are = not > > in > the base schema that may be related or have language with "and" "or" = to > specify the relationships. In some cases, you will want to group = these > indictors in one extension point, where they may fit logically in = multiple > places if the relationships did not need to be shown in the data > format. If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData = class > AdditionalData extension point? Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document. We could have a catch-all = class > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI. I think I = like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning = of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so = that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 ------=_NextPart_000_0009_01CE0907.94961D50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYoDCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFqDCCBJCgAwIBAgIQYNecC3elyT7NQnxWXD4qHDANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEy MDQwMzE3MTA0NVoXDTE0MDQwMzE3MTA0NVowgdkxEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxETAPBgNVBAsTCENvbnN1bWVyMQ8wDQYDVQQFEwYwODQxNTMxFjAUBgoJkiaJk/IsZAEBEwZt b3JpYWsxGjAYBgNVBAMTEUthdGhsZWVuIE1vcmlhcnR5MSgwJgYJKoZIhvcNAQkBFhlrYXRobGVl bi5tb3JpYXJ0eUBlbWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv+TnbpOG gqBZF5MBRDiDNLy/TMUs61qdYCiNbyCpHKm4eONu8Bkjl+5BsQ04GP7yooZqZ53GN8wI4Xd2PbHi b6YVlujtTRaxQvjtTBzWrJL8oHgJf7zNPtRM3pu0BsdVhoxL28CCvuTqlNDEBuLDU8W8cX+3xYB1 tA3JCFmrHxxgQ0WNpFCFeoRcxJkHB3JfRIXfpXJw2NTwfpNyiYIXEY5TmUWq+xiVtZwEjKQ/kXSs Q7d6SXcMVHmKvndA9XYhjEzp7zhevhAJqBJuJwhC5MNQ/Ixyhi2Lb98EwJh5vOYV0XRu0WpdFNST wlhh7kyFB8ZIrhsTtz4WDEUBe4cXpwIDAQABo4IBozCCAZ8wHwYDVR0jBBgwFoAUFDDra/X0SbVo UnWm272uW8isfUwwgZEGA1UdIASBiTCBhjCBgwYJKoZIhvcNBQcFMHYwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5yc2FzZWN1cml0eS5jb20vQ1BTLmh0bWwwRAYIKwYBBQUHAgIwODAXFhBSU0EgU2Vj dXJpdHkgTExDMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCkGA1UdJQQiMCAG CisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgNVHREEPTA7gRlrYXRobGVlbi5tb3Jp YXJ0eUBlbWMuY29toB4GCisGAQQBgjcUAgOgEAwObW9yaWFrQGVtYy5jb20wDgYDVR0PAQH/BAQD AgeAMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNs YXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYEFEfJREQxfcvAOlqJ3jwY1/++6ktIMA0GCSqG SIb3DQEBBQUAA4IBAQBwuy2NnyUuHNb79RtlEU+nmBbPaGNUtELBtIXmmMHzmylw/SK1kkUH7+Eq 1M4lylKZnHtFb0W0EVsf3bU6RoTPNxQitgx6gQp9RXnu0UXD5L0PybdDD0ShKLPifUe5HIFfZ6rn sKZ+coYMAYxFMPRVbvZcchlR9aAhAtS9JIS49cp6F8L7BvSrGMRpODzDCGyD4+8a1M1pivDwEMd7 OrTNimQMrjfoDA8Hbqw3FUgavQTAmcwwx88GaCQnVguxYd59mwVpDh4NtGnsz2tIAJ/9cEieYLwW 06RgYpZtTE6GAAxd90uYqo94CK31azcUN2GjmnfLj/nsscSR66pBSn50MIIFuTCCBKGgAwIBAgIR AJMBY13rQIwiCFVvrbx5PZ4wDQYJKoZIhvcNAQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQI Ew1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkg TExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0Eg Q2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMjA0MDMxNzEwNDhaFw0xNDA0MDMxNzEwMzJaMIHd MRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMg Q29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2FzMREwDwYDVQQLEwhDb25zdW1lcjEPMA0GA1UE BRMGMDg0MTUzMRYwFAYKCZImiZPyLGQBARMGbW9yaWFrMR4wHAYDVQQDExVLYXRobGVlbiBNb3Jp YXJ0eS1FbmMxKDAmBgkqhkiG9w0BCQEWGWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcbesv4mh7Z07BKcyAeA9MgiHS5o78g4HjhdHyVYgw 6wg0TkfWhTKPKVlcHqkcTaAcvxKm3GBiMsiFz6Ys9GQrSiApXTJlJOVd946e26pGeQ6ZIQB1Mt2K BTxac2+zX5TcDhlvmLExBKTPiEbjsJR1f1azksUdDxSaAFBxYUsoqipvniwfRPOaqqXv4GTQsqOC 6Wl5exk7IJYTFxiautdPD/5a2TJF5ThC2gQrXWo9wL3yOJJ8/vbdh2AQMAXXmyfsMNtuhF1Ct+sK nhGjhG4jJQwLYbRG9dR0uMFtyxDILD9vz8ScuUkaypv771Z2VPZ6mS4Pn2vHluvvQhoEWU4FAgMB AAGjggGvMIIBqzA1BgNVHSUELjAsBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHwYDVR0jBBgwFoAUFDDra/X0SbVoUnWm272uW8isfUwwgZEGA1UdIASBiTCBhjCB gwYJKoZIhvcNBQcFMHYwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1cml0eS5jb20vQ1BT Lmh0bWwwRAYIKwYBBQUHAgIwODAXFhBSU0EgU2VjdXJpdHkgTExDMAMCAQEaHUNQUyBJbmNvcnBv cmF0ZWQgYnkgcmVmZXJlbmNlMEQGA1UdEQQ9MDuBGWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb22g HgYKKwYBBAGCNxQCA6AQDA5tb3JpYWtAZW1jLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBSramWspVPOGwyy09NkCwcziN1W5jAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQADggEB ACrOJZt/SlHcro3HWRYEznk3JyKMFLUakwsppH0NvAuX6pEc55bjNebanGUIxSXMKh6BtcZy2j84 2WUky6YQm4wvluSAvo8FvyjSD5C6Nvp5gl+NuPISVbxlePXImfbyxCWijqp1ecK2DQsNcb3IFAaa ymkDw7tz78C1ZqW+z2mC6xE9gwzD+1CzJHriFiVyv14Mnsb26dJKkGgJI9NrKP1jO0G+YY7kMDfN NReNxMBGraA+gashn3Bwe4pYxHh+moSAbAOxhMgbsiEE1TNdspDz8GLZ3FkDZjhRPghOpOnCDFpz agxioFquh9toWfUCKwLAgMHpLjjbsZKmtzl1+YkxggQ3MIIEMwIBATCBszCBnjELMAkGA1UEBhMC VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0JlZGZvcmQxGTAXBgNVBAoTEFJT QSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0eSBPcmdhbml6YXRpb24xIzAh BgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyAhBg15wLd6XJPs1CfFZcPiocMAkGBSsO AwIaBQCgggJYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIx MjE0NTkwMFowIwYJKoZIhvcNAQkEMRYEFJdeeCSudYsAhYOxYJiWOowh4hhvMGcGCSqGSIb3DQEJ DzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHFBgkrBgEEAYI3EAQxgbcwgbQw gZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3Jk MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3Jn YW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIRAJMBY13rQIwi CFVvrbx5PZ4wgccGCyqGSIb3DQEJEAILMYG3oIG0MIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMN TWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExM QzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENs YXNzIDIgUGVyc29uYWwgQ0EgdjICEQCTAWNd60CMIghVb628eT2eMA0GCSqGSIb3DQEBAQUABIIB AHECCXTea64b0EYBBuuy//GjWAV7JI4yAtkqxI+8A4/Ex1a6DJh4AB2+y7mgjsQXRKOwbpNdW6jU SScm5Tiv01jLtTGs4v4xYL5Nj696aWjLWGIcTAK9yfiluqV8rboHKVR0OOGFs4GDo+p63AsQVoPQ HG0Jv+A+F2u1va9afDhGi5BKPtteIwxXUhecaA+5bzYF/yNoOqz6lDNBSargvDbT4qRdP2gM0pY6 tVBUekfAR8AuOgkEKWi969XWPBLYZX2xNz4qloqa75cvjmWyhbZJrXRE4ti0yavVlEgiJNThFc2j 3ZlrU3ykkjNO4o7ds2P2gGuE9yp3adYa4JBsbU4AAAAAAAA= ------=_NextPart_000_0009_01CE0907.94961D50-- From Christopher.Harrington@emc.com Tue Feb 12 10:07:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E538821F905C for ; Tue, 12 Feb 2013 10:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.762 X-Spam-Level: * X-Spam-Status: No, score=1.762 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha67GCfUbeqv for ; Tue, 12 Feb 2013 10:07:06 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD621F905A for ; Tue, 12 Feb 2013 10:07:06 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CI72jb009600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 13:07:06 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 12 Feb 2013 13:06:43 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CI6gag012162; Tue, 12 Feb 2013 13:06:42 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Tue, 12 Feb 2013 13:06:41 -0500 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , "'Takeshi Takahashi'" , "Stoecker, Paul" , "'MILE IETF'" Date: Tue, 12 Feb 2013 13:06:41 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQH6FK7Ma5Jx1DXCz0Xe6yJsWBsaUwGN9Wf9AzK/UBgCtxHytwJEdcHEAmgDEnOXvLbGAIAAVQIAgAALC6CAADOFUA== Message-ID: References: <02bd01ce03c2$c1c84770$4558d650$@nict.go.jp> <005101ce0902$34aed260$9e0c7720$@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0039_01CE0921.CC5A8C20" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:07:09 -0000 ------=_NextPart_000_0039_01CE0921.CC5A8C20 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I see some confusion coming down the pike if we start using Confidence = the way it is supported. If I am using low/med/high and someone sends me an = IoC with a score of 70, what does that mean to me? What if I am using a = scale of 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when = we store IoC from multiple sources. I have confidence values that are = numeric as well as text. Makes searching / sorting very problematic.=20 At this point we have to roll with what we have. I would strongly = recommend that we revisit this at some point.=20 Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen=20 Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Chris & Take, I'll just focus on the confidence scoring. Right now, the schema allows = for you to either use a numerical score OR the ratings of low, medium, and = high. Different sharing groups can decide how they want to share the data. If people were to use the numerical values, I agree it would be helpful to = have guidance. This could go in the IODE guidance document. I have seen examples of current users that use each of the approaches, = so we'll need to keep the option for backwards compatibility and it is nice = to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher=20 Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break = it down to more levels than that we would need to provide guidance on = scoring, rating, etc. I think most people should be able to understand = low/med/high without having to have a mathematical method for arriving at the level.=20 Low - I am not sure Medium - I am reasonably sure High - I am very sure=20 Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE = IETF' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to = deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be = omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence = attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? = For instance, 1 means "no confidence" while 5 means "strong confidence", = etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have=20 > seen and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute=20 > would be beneficial as making those associations is not a perfect=20 > science by any means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a=20 > few others on their use cases and would like more opinions. I'll=20 > provide an option below from what we have discussed from a CIRC view=20 > point. We are also wondering how to also provide logic in IODEF that=20 > could cross over into SCI attached schemas or IODEF extensions (the=20 > solutions may all tie together with this discussion - or there may be=20 > better/more elegant solutions others would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE = > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside=20 > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that=20 > should be viewed as a set and may have another instance of that same=20 > class that is a related issue, but a separate set. We could as you=20 > say, list the indicator IDs connected through the reference class. =20 > The set IDs might give us other ways to group the values when we get=20 > into logic and relationships between sets or indicators. This could=20 > also be a way to connect indicators or sets across XML documents that=20 > could have been shared previously. If there are a large number of=20 > indicators in the set, then this becomes useful, for smaller sets, I=20 > agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not=20 > >> fit into a category in the SCI draft, do we create a place for=20 > >> these off of SCI or right off of the IODE schema in EventData?=20 > >> (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event=20 > > record, we could use SCI:EventReport class as the place for the=20 > > XML-based IOCs that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me. This should go into guidance = > in the SCI draft. Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of=20 > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids=20 > > and its usability, but I am not sure whether we do not have any=20 > > other way to express these groupings. > > For instance, a Reference class refers to several indicadtor_uids. > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or=20 > subsequent messages that add indicators to existing sets? Would this=20 > happen? Would it be easier to express relationships with sets of=20 > indicators in addition to individual indicators? By using this, it=20 > could give us a unique way to also provide the logic and relationships = > in a new class of IODEF so we don't have to worry about adding it into = > the current structure. > If there are better ways to handle that, and others can provide some=20 > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have=20 > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information=20 > > as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a=20 > logical and / or somewhere to show relationship between indicators. If = > I give you > 2 > registry keys do they both have to be present to be an indication of=20 > compromise or is either one by themselves an indicator? Both would=20 > have the same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid? =20 > This would allow you to group indicators that are related into the=20 > same group ID. > Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators)=20 > class that will should be used to take all of the indicators put them=20 > into one place and have the ability to group the ones that go=20 > together. I don't mean a place to put indicators that are missing=20 > from IODEF.I mean a place in the IODEF document where you put the=20 > indicators that are used for detection and prevention of the shared=20 > Incident. I don't know the answer here, but there has got to be a=20 > good way for indicators to be identified and being able to group them=20 > as Chris has suggested without basically recreating something=20 > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE=20 > IETF > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to=20 > the definitions in RFC5070-bis, to be more explicit about including=20 > indicators and sets of indicators in IODE documents as opposed to=20 > 'parts of an incident or the useful information on an incident for=20 > sharing purposes. It was written before we used terms like=20 > indicators. With that in mind, Rosella proposed a number of changes=20 > back in July, both for guidance and for format > updates. It may help to have the first draft try to address at least=20 > some of these issues so people can understand the problems and at=20 > least a proposed solution. >=20 > As you point out, we need to be able to show relationships between=20 > sets of indicators, where we may have a few sets of indicators that=20 > could have a relationship to each other within a document. In the=20 > July presentation, one of the questions was to see if we should add=20 > new category attribute values for the System class that would connect=20 > the list of included indicators. I think we should still keep the=20 > concept of a Node to a single node, but perhaps within System, list=20 > multiple sets of Nodes that may be one type of attack. Rosella had=20 > suggested pulling forward the "FraudType" from RFC5901, this would=20 > help solve the issue as NodeRole values would compliment an AttackType = > (FraudType values could be included in AttackType or some broader=20 > term). It may be better to have the FraudTypes, plus attribute values = > like "C2-server", "sinkhole", "MalwareDistribution" for added context = > so you know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect=20 > indicators and indicator sets within an IODEF using an attribute of=20 > indicator_uid (or some other name) with a string value to make the=20 > connection points, and add a few indicators that are commonly shared=20 > into the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and=20 > hashes to the main IODEF document (trying to see if this will help=20 > Chris below). What if we added the Registry Key/Value pairs as a=20 > class off of RecordData, using a similar structure to what is in=20 > RFC5901, and also added the ability to include hashes in RecordData? =20 > I think if we then had the indicator_uid at the RecordData level, we=20 > could connect a set within that structure and repeat the structure for = > other sets in the same way we would do with Node inside of the System=20 > class, using the indicator_uid to tie the set together. Then at the=20 > more specific level for the hash, registry Key/value, IP, etc. use an=20 > indicator_uid if we needed them marked at this level as well? Maybe=20 > we want indicator_set at the higher level? I'd like some opinions on=20 > this approach. +1 if you agree, suggestions if you have other ideas=20 > that may work better. >=20 > We'll also need to worry about marking the indicators to prevent=20 > forward sharing when not permitted. We may want to use these values=20 > or something else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the=20 > Watchlist Use Case. A bunch of indicators are sent in one message. In=20 > that message we could have groupings of indicators that we need to=20 > show are > related: >=20 > Two or more indicators of different type that relate to the same = threat: > The file hash of a malicious file and the URL of the C2 that=20 > the file uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same = threat: > 2 different registry values for the same registry key. If=20 > either value is present it is a compromise indicator but both will not = > be present. >=20 > The problem compounds itself very quickly. Consider the scenario where = > both groupings above are part of the same threat. I need to show that=20 > logical groupings of Indicators are related as well. We can't send=20 > multiple IODEF messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different=20 > indicators that represent the same indicator. It's not uncommon to=20 > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the=20 > IOCs are the 2 hash values. How do we show they are related? If we use = > a unique Inidcator ID for each hash value there needs to be a higher=20 > level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from=20 > the list on options to help solve the problems raised in my message=20 > and additionally in Paul's message. >=20 > Interesting point, C. Henry. Our objective here is to have machine=20 > automated exchanges, so we rely on encryption rather than obfuscation=20 > to achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from=20 > context information that may also include IP address or other data=20 > that could be indicators. The question I raised was on how to connect = > sets of indicators in the same IODEF document, assuming the ability to = > have watchlists that could have several sets of indicators included,=20 > as well as to connect indicators that may be included in embedded=20 > schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say=20 > 'indicator-uid' how do we mark the indicators? Do we use this to mark = > who sent the indicator as well so that we can prevent forward sharing=20 > when it is not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit=20 > into a category in the SCI draft, do we create a place for these off=20 > of SCI or right off of the IODE schema in EventData? (more details on=20 > this in my first message). >=20 > Comments and questions encouraged to figure out the right technical=20 > solution to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting. I remember when I first ran=20 > across this particular craft, an experienced colleague asked me a=20 > peculiar question. He said, " How do you stop someone from tracking=20 > the IP Address to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off and the modem that it is > connected- which is constantly on!" LOL >=20 > Here's my point (Hypothetical Situation) : There is a 1st Responder=20 > searching a Neighborhood for Survivors which were hit by a Disaster or = > let's just say "Live" Terrorist Situation. He /or She needs to=20 > communication back to other Officials that he /or somehow is in=20 > Danger. The device used to communicate has been captured by the great = > minds of the enemy. It's only a matter of time before they utilize=20 > reverse engineering to figure out how it functions. However, their=20 > pride comes before a fall when seeking the location of other similar=20 > devices to attack. Why? Perhaps the less thought of concepts that=20 > makes the device function properly, saves the day by disguise or=20 > cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited=20 > distribution within the recipient's place of business for planning=20 > purposes only. Further dissemination, whether private or public is=20 > prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS = > SEC a pemanent and temporal key, with a temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way=20 > > was > closely related to what I attempted to express when I stated,=20 > "consider to a degree what appears to be illogical in brilliant minds=20 > in some instances." > > > > However, I see Dr. Stoecker's point a little clearer. However, it=20 > > would > be nice if the UID was in some way disguised from those who study this = > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=A9let's say I get an XML document that tells me about an > > incident. This document has source IP and destination IP that is > > being shared. However, what I don't know is which IP address is my > > indicator and which is just a contextual piece of information. This > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, = even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would = allow > > us to easily identify indicators from contextual data. I do admit = to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid. One thing that I haven't > > considered is the UID portion of this=A9how do we use that UID? How = is > > the UID created? Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once. However, could you = share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now = in > IODEF and then have the extension point for combined indicators via = SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what = appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this. We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more = once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions. Where you place the extensions should be specific to the > logical grouping of the parent elements so you can understand more = about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating = on > the > report as a whole. Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData = extension > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class. He did ask about non-XML. RecordItem or AdditionalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come = directly > off the AdditionalData or RecordItem classes according to what makes = sense > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share. If we are extending to embed other schemas = that > include such reference or GUID identifiers, do we want to add an = attribute > to the various elements in IODEF that could be indicators? Is this = enough > to make the connections or is something else else needed? We could = add > something like an Indicator_ID in RFC5070-bis which would then = correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are = not > > in > the base schema that may be related or have language with "and" "or" = to > specify the relationships. In some cases, you will want to group = these > indictors in one extension point, where they may fit logically in = multiple > places if the relationships did not need to be shown in the data > format. If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData = class > AdditionalData extension point? Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document. We could have a catch-all = class > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI. I think I = like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning = of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so = that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 ------=_NextPart_000_0039_01CE0921.CC5A8C20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTIx ODA2NDBaMCMGCSqGSIb3DQEJBDEWBBT4lhURNL/ugE0tqFYCpndV/nVNHjCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAUUsjo7vlQ5KVcICDoW4hr7b578TBTfvopfNF8BJMFmSE2XxgMJcImMIRELRLxN6P s6EDauidHie67YJ8ja/HVtB9YIJkouTBdiVPYp/sXRLcR3P8WxMr/AkyJxuN2yJyrrnqVXK/XP1E 4N5QqqfN+lc7pgytb2sjQo+oTkyQnLq6WF1BGFw1rJvA2IA71qRZX/InJdsRrwhAURepORgFFru9 svAG6ZymOVDtSjbrqoU6WEGdcikJXggVZiL6YbX7ABkRiczxJmgojBYB0nVQwxHd+FehRPKoXTtM SJK3clJzBhwMg4boMmJHYlZKvyfNTkXdntHebUE/FO2q3LyzcwAAAAAAAA== ------=_NextPart_000_0039_01CE0921.CC5A8C20-- From chatlga2000@yahoo.com Tue Feb 12 11:45:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9821F8848 for ; Tue, 12 Feb 2013 11:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.664 X-Spam-Level: ** X-Spam-Status: No, score=2.664 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_40=-0.185, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGX+25KJoq+6 for ; Tue, 12 Feb 2013 11:45:36 -0800 (PST) Received: from nm20-vm2.bullet.mail.ne1.yahoo.com (nm20-vm2.bullet.mail.ne1.yahoo.com [98.138.91.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C221F8D8B for ; Tue, 12 Feb 2013 11:45:36 -0800 (PST) Received: from [98.138.226.180] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 19:45:35 -0000 Received: from [98.138.87.10] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 19:45:35 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 19:45:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 483609.73801.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 88283 invoked by uid 60001); 12 Feb 2013 19:45:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360698335; bh=CK2sRJtED24pczFuUnnIFyv1D8nsD0tq8f6XvHbgnVk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=MIknydEKRRWlmlYk2sgHQXThm+Uk4CjY8aASs1gAUa0uNn5caEBrXm8JoF++Drl7bkf1IV+bYLWZSzsMDytZhroG6eRE+3X7BcjJoS2WZXN1SQJIABaOs4BV9AEAEn87hjyOl7e3mjsxO8jOMNHc7ALXeli1jN+fMbLhs056gQ8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=YHi+p/ixPols6t1p4xkdlw7l35I50aJ95LmqNJ1+U6iXvhT9FzpEWcnvUV8oVJVWWxfh+o01R8BCUpCVz7uNJEkx9Zppk9aqLJvBuM7uRgFEMUdqlFYnkQxI9HQmmXy/6eQL0gjrlezsAL+pfnBcNtCtxYJAwW5T5emlxbUsCmg=; X-YMail-OSG: NtS4oNQVM1kQel52yryNhOOjNLTQYytqYIWwUz.Xk9Ja9HH _cRAwQ.sbyWohUZ7pho_0us4jZkiFgkY5xcWgg9HHmVKq8G5iCV2.N3WfiLt k3Coz9yCz45sJChQEWRNdwrHfegKPz7GOQu3ZhyHo13uMn9.Qwly.QFR_5uV atdXn11vJwMGNJ8MdUvL.6v0nm0VNNFeZPAUH5hPldCnRklW1bPyUmASaZJP gA9flFSWP3JEjNEAfZoU_dGc5hfu_9phUMquFUHsIRS8SVeN3ot86kDwbmzs DVmhfXgOzG5xBKadLsuZsmFTJzdch.q6DMM3I54OOkijgA8kdPDWAg6jLIty tBL8J_0NXqIJnVG.MQpbcsC.ySjfMIGBQwVhELS55WnFdqyuWocF0upZ1PEf uZxJQi2Ikws6rEBciCIsdWUmsfgo2K9.r_Ajg.NG4SDcb_QgWFWoeDG3OVHk tdTevXAwQLnPv82_Vgz9hGaYBuaHkSu7_7Rfer3ulon7qz9FiX81M57amFom 4te.xUCPBWZJksEGZhcs8rVVknXgBadkPbn.S0aWW93wSBf09CmGNxlIPkPO B_704ovSqA_M- Received: from [71.22.243.36] by web121606.mail.ne1.yahoo.com via HTTP; Tue, 12 Feb 2013 11:45:35 PST X-Rocket-MIMEInfo: 001.001, DQpSZWdhcmRpbmcgdGhlIElPQ3Mgb3IgSW5kaWNhdG9ycyBvZiBDb21wcm9taXNlLCBDaHJpcyBtYWRlIGEgdml0YWwgcG9pbnQuwqAgRGlmZmVyZW50IENvbmZpZGVuY2UgbGV2ZWxzIHdpbGwgY2F1c2UgY29uZnVzaW9uLsKgIEl0IGFwcGVhcnMgdGhhdCB0aGVyZSBtYXliZSBhIG5lZWQgZm9yIHNvbWUgdHlwZSBvZiBzaW1wbGlmaWVkIHN0YW5kYXJkaXphdGlvbiB0byBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIGFsbCBTaGFyaW5nIEdyb3VwcyBpbiB0aGlzIHJlZ2FyZC4NCg0KUGVyaGFwcyBudW1lcmljYWwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.133.508 Message-ID: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Tue, 12 Feb 2013 11:45:35 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-1531119564-1360698335=:82136" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 19:45:40 -0000 --1458340343-1531119564-1360698335=:82136 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding the IOCs or Indicators of Compromise, Chris made a vital point.= =C2=A0 Different Confidence levels will cause confusion.=C2=A0 It appears t= hat there maybe a need for some type of simplified standardization to be es= tablished between all Sharing Groups in this regard. Perhaps numerical scoring set at lower values should express levels of urge= ncy. ( i.e.=C2=A0 1 =3D Less Likely, =C2=A0 2 =3D Probable,=C2=A0 3 =3D A Concer= n,=C2=A0 4 =3D=C2=A0 Urgent,=C2=A0 5 =3D Imminent ) Thanks, C. Henry Adams =0A =0A =0AI see some confusion coming down the pike if we start using Confidence t= he way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale o= f 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text.=C2=A0 Makes searching / sorting very problematic.=20 At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point.=20 Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen=20 Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Chris & Take, I'll just focus on the confidence scoring.=C2=A0 Right now, the schema allo= ws for you to either use a numerical score OR the ratings of low, medium, and high= . Different sharing groups can decide how they want to share the data.=C2=A0 = If people were to use the numerical values, I agree it would be helpful to hav= e guidance.=C2=A0 This could go in the IODE guidance document. I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher=20 Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level.=20 Low - I am not sure Medium - I am reasonably sure High - I am very sure=20 Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF= ' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have=20 > seen and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute=20 > would be beneficial as making those associations is not a perfect=20 > science by any means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a=20 > few others on their use cases and would like more opinions.=C2=A0 I'll=20 > provide an option below from what we have discussed from a CIRC view=20 > point.=C2=A0 We are also wondering how to also provide logic in IODEF tha= t=20 > could cross over into SCI attached schemas or IODEF extensions (the=20 > solutions may all tie together with this discussion - or there may be=20 > better/more elegant solutions others would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside=20 > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that=20 > should be viewed as a set and may have another instance of that same=20 > class that is a related issue, but a separate set.=C2=A0 We could as you= =20 > say, list the indicator IDs connected through the reference class.=C2=A0= =20 > The set IDs might give us other ways to group the values when we get=20 > into logic and relationships between sets or indicators.=C2=A0 This could= =20 > also be a way to connect indicators or sets across XML documents that=20 > could have been shared previously.=C2=A0 If there are a large number of= =20 > indicators in the set, then this becomes useful, for smaller sets, I=20 > agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not=20 > >> fit into a category in the SCI draft, do we create a place for=20 > >> these off of SCI or right off of the IODE schema in EventData?=20 > >> (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event=20 > > record, we could use SCI:EventReport class as the place for the=20 > > XML-based IOCs that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me.=C2=A0 This should go into guidan= ce=20 > in the SCI draft.=C2=A0 Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of=20 > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids=20 > > and its usability, but I am not sure whether we do not have any=20 > > other way to express these groupings. > > For instance,=C2=A0 a Reference class refers to several indicadtor_uids= . > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or=20 > subsequent messages that add indicators to existing sets?=C2=A0 Would thi= s=20 > happen?=C2=A0 Would it be easier to express relationships with sets of=20 > indicators in addition to individual indicators?=C2=A0 By using this, it= =20 > could give us a unique way to also provide the logic and relationships=20 > in a new class of IODEF so we don't have to worry about adding it into=20 > the current structure. > If there are better ways to handle that, and others can provide some=20 > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have=20 > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information=20 > > as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a=20 > logical and / or somewhere to show relationship between indicators. If=20 > I give you > 2 > registry keys do they both have to be present to be an indication of=20 > compromise or is either one by themselves an indicator? Both would=20 > have the same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid?=C2=A0= =20 > This would allow you to group indicators that are related into the=20 > same group ID. >=C2=A0 Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators)=20 > class that will should be used to take all of the indicators put them=20 > into one place and have the ability to group the ones that go=20 > together.=C2=A0 I don't mean a place to put indicators that are missing= =20 > from IODEF.I mean a place in the IODEF document where you put the=20 > indicators that are used for detection and prevention of the shared=20 > Incident.=C2=A0 I don't know the answer here, but there has got to be a= =20 > good way for indicators to be identified and being able to group them=20 > as Chris has suggested without basically recreating something=20 > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE=20 > IETF > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to=20 > the definitions in RFC5070-bis, to be more explicit about including=20 > indicators and sets of indicators in IODE documents as opposed to=20 > 'parts of an incident or the useful information on an incident for=20 > sharing purposes.=C2=A0 It was written before we used terms like=20 > indicators.=C2=A0 With that in mind, Rosella proposed a number of changes= =20 > back in July, both for guidance and for format > updates.=C2=A0 It may help to have the first draft try to address at leas= t=20 > some of these issues so people can understand the problems and at=20 > least a proposed solution. >=20 > As you point out, we need to be able to show relationships between=20 > sets of indicators, where we may have a few sets of indicators that=20 > could have a relationship to each other within a document.=C2=A0 In the= =20 > July presentation, one of the questions was to see if we should add=20 > new category attribute values for the System class that would connect=20 > the list of included indicators.=C2=A0 I think we should still keep the= =20 > concept of a Node to a single node, but perhaps within System, list=20 > multiple sets of Nodes that may be one type of attack.=C2=A0 Rosella had= =20 > suggested pulling forward the "FraudType" from RFC5901, this would=20 > help solve the issue as NodeRole values would compliment an AttackType=20 > (FraudType values could be included in AttackType or some broader=20 > term).=C2=A0 It may be better to have the FraudTypes, plus attribute valu= es=20 > like "C2-server", "sinkhole",=C2=A0 "MalwareDistribution" for added conte= xt=20 > so you know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect=20 > indicators and indicator sets within an IODEF using an attribute of=20 > indicator_uid (or some other name) with a string value to make the=20 > connection points, and add a few indicators that are commonly shared=20 > into the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and=20 > hashes to the main IODEF document (trying to see if this will help=20 > Chris below).=C2=A0 What if we added the Registry Key/Value pairs as a=20 > class off of RecordData, using a similar structure to what is in=20 > RFC5901, and also added the ability to include hashes in RecordData?=C2= =A0=20 > I think if we then had the indicator_uid at the RecordData level, we=20 > could connect a set within that structure and repeat the structure for=20 > other sets in the same way we would do with Node inside of the System=20 > class, using the indicator_uid to tie the set together.=C2=A0 Then at the= =20 > more specific level for the hash, registry Key/value, IP, etc. use an=20 > indicator_uid if we needed them marked at this level as well?=C2=A0 Maybe= =20 > we want indicator_set at the higher level?=C2=A0 I'd like some opinions o= n=20 > this approach.=C2=A0 +1 if you agree, suggestions if you have other ideas= =20 > that may work better. >=20 > We'll also need to worry about marking the indicators to prevent=20 > forward sharing when not permitted.=C2=A0 We may want to use these values= =20 > or something else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the=20 > Watchlist Use Case. A bunch of indicators are sent in one message. In=20 > that message we could have groupings of indicators that we need to=20 > show are > related: >=20 > Two or more indicators of different type that relate to the same threat: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 The file hash of a malicious file and the URL = of the C2 that=20 > the file uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same threat: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 2 different registry values for the same regis= try key. If=20 > either value is present it is a compromise indicator but both will not=20 > be present. >=20 > The problem compounds itself very quickly. Consider the scenario where=20 > both groupings above are part of the same threat. I need to show that=20 > logical groupings of Indicators are related as well. We can't send=20 > multiple IODEF messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different=20 > indicators that represent the same indicator. It's not uncommon to=20 > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the=20 > IOCs are the 2 hash values. How do we show they are related? If we use=20 > a unique Inidcator ID for each hash value there needs to be a higher=20 > level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from=20 > the list on options to help solve the problems raised in my message=20 > and additionally in Paul's message. >=20 > Interesting point, C. Henry.=C2=A0 Our objective here is to have machine= =20 > automated exchanges, so we rely on encryption rather than obfuscation=20 > to achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from=20 > context information that may also include IP address or other data=20 > that could be indicators.=C2=A0 The question I raised was on how to conne= ct=20 > sets of indicators in the same IODEF document, assuming the ability to=20 > have watchlists that could have several sets of indicators included,=20 > as well as to connect indicators that may be included in embedded=20 > schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say=20 > 'indicator-uid' how do we mark the indicators?=C2=A0 Do we use this to ma= rk=20 > who sent the indicator as well so that we can prevent forward sharing=20 > when it is not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit=20 > into a category in the SCI draft, do we create a place for these off=20 > of SCI or right off of the IODE schema in EventData? (more details on=20 > this in my first message). >=20 > Comments and questions encouraged to figure out the right technical=20 > solution to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting.=C2=A0 I remember when I first ran= =20 > across this particular craft, an experienced colleague asked me a=20 > peculiar question.=C2=A0 He said, " How do you stop someone from tracking= =20 > the IP Address to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off=C2=A0 and the modem that it is > connected- which is constantly on!"=C2=A0=C2=A0=C2=A0LOL >=20 > Here's my point (Hypothetical Situation) :=C2=A0 There is a 1st Responder= =20 > searching a Neighborhood for Survivors which were hit by a Disaster or=20 > let's just say "Live" Terrorist Situation.=C2=A0 He /or She needs to=20 > communication back to other Officials that he /or somehow is in=20 > Danger.=C2=A0 The device used to communicate has been captured by the gre= at=20 > minds of the enemy.=C2=A0 It's only a matter of time before they utilize= =20 > reverse engineering to figure out how it functions.=C2=A0 However, their= =20 > pride comes before a fall when seeking the location of other similar=20 > devices to attack.=C2=A0 Why? Perhaps the less thought of concepts that= =20 > makes the device function properly, saves the day by disguise or=20 > cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited=20 > distribution within the recipient's place of business for planning=20 > purposes only. Further dissemination, whether private or public is=20 > prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS=20 > SEC a pemanent and temporal key, with a temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle=C2=A0 dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way=20 > > was > closely related to what I attempted to express when I stated,=20 > "consider to a degree what appears to be illogical in brilliant minds=20 > in some instances." > > > > However, I see Dr. Stoecker's point a little clearer.=C2=A0 However, it= =20 > > would > be nice if the UID was in some way disguised from those who study this=20 > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=C5=A0let's say I get an XML document that tells me about an > > incident.=C2=A0 This document has source IP and destination IP that is > > being shared.=C2=A0 However, what I don't know is which IP address is m= y > > indicator and which is just a contextual piece of information.=C2=A0 Th= is > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would allow > > us to easily identify indicators from contextual data.=C2=A0 I do admit= to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid.=C2=A0 One thing that I haven't > > considered is the UID portion of this=C5=A0how do we use that UID?=C2= =A0 How is > > the UID created?=C2=A0 Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote= : > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once.=C2=A0 However,=C2=A0 could= you share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now in > IODEF and then have the extension point for combined indicators via SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this.=C2=A0 We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions.=C2=A0 Where you place the extensions should be specific to th= e > logical grouping of the parent elements so you can understand more about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating on > the > report as a whole.=C2=A0 Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData extensio= n > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class.=C2=A0 He did ask about non-XML.=C2=A0 RecordItem or Additio= nalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come directl= y > off the AdditionalData or RecordItem classes according to what makes sens= e > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share.=C2=A0 If we are extending to embed other schemas t= hat > include such reference or GUID identifiers, do we want to add an attribut= e > to the various elements in IODEF that could be indicators?=C2=A0 Is this = enough > to make the connections or is something else else needed?=C2=A0 We could = add > something like an Indicator_ID in RFC5070-bis which would then correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are not > > in > the base schema that may be related or have language with "and" "or" to > specify the relationships.=C2=A0 In some cases, you will want to group th= ese > indictors in one extension point, where they may fit logically in multipl= e > places if the relationships did not need to be shown in the data > format.=C2=A0 If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData class > AdditionalData extension point?=C2=A0 Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document.=C2=A0 We could have a catch-all c= lass > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI.=C2=A0 I think I= like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 > --1458340343-1531119564-1360698335=:82136 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Regarding the IOCs or Indicators of Compr= omise, Chris made a vital point.  Different Confidence levels will cau= se confusion.  It appears that there maybe a need for some type of sim= plified standardization to be established between all Sharing Groups in thi= s regard.

Perhaps numerical scoring set at lower values should expre= ss levels of urgency.
( i.e.  1 =3D Less Likely,   2 =3D Proba= ble,  3 =3D A Concern,  4 =3D  Urgent,  5 =3D Imminent = )

Thanks,
C. Henry Adams
=0A

=0A
=0AI see some confu= sion coming down the pike if we start using Confidence the
way it is sup= ported. If I am using low/med/high and someone sends me an IoC
with a sc= ore of 70, what does that mean to me? What if I am using a scale of
1 to= 4 and someone else is on a scale of 1 to 5? We lose the ability to
desc= ribe something with a consistent language. It really gets ugly when we
s= tore IoC from multiple sources. I have confidence values that are numericas well as text.  Makes searching / sorting very problematic.
At this point we have to roll with what we have. I would strongly recomme= nd
that we revisit this at some point.

Thanks,

--Chris
-----Original Message-----
From: Moriarty, Kathleen
Sent: Tuesd= ay, February 12, 2013 9:59 AM
To: Harrington, Christopher; 'Takeshi Taka= hashi'; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

H= i Chris & Take,

I'll just focus on the confidence scoring.  Right now, the schema allows for
you to eithe= r use a numerical score OR the ratings of low, medium, and high.
Differe= nt sharing groups can decide how they want to share the data.  If
p= eople were to use the numerical values, I agree it would be helpful to have=
guidance.  This could go in the IODE guidance document.

I h= ave seen examples of current users that use each of the approaches, so
w= e'll need to keep the option for backwards compatibility and it is nice to<= br>keep in flexible options where we can.

Thank you,
Kathleen
=
-----Original Message-----
From: Harrington, Christopher
Sent: T= uesday, February 12, 2013 9:22 AM
To: 'Takeshi Takahashi'; Moriarty, Kat= hleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

The n= umber of indicators wouldn't necessarily drive the use of
indicator_set_= id. The purpose is to show relationship. If I sent 3 IP
addresses that were used as C2 for 3 different campaigns I would have
separate in= dicator_set_ids, each with one of the 3 C2 IPs

My suggestion would b= e a simple low, medium, high. I think if we break it
down to more levels= than that we would need to provide guidance on scoring,
rating, etc. I = think most people should be able to understand low/med/high
without havi= ng to have a mathematical method for arriving at the level.

Low - I= am not sure
Medium - I am reasonably sure
High - I am very sure
=

Thanks,

--Chris

-----Original Message-----
From: T= akeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; M= oriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs<= br>
Regarding the indicator_set_id, I agree, it is useful when we need to deal
with large sets of indicators.
Since indicator_set_id a= ttribute is optional (right?), it could be omitted
if we need to deal wi= th only small number of indicators.

Regarding the use case, I like t= he idea of using the confidence attribute
for the reason Chris kindly de= scribed.
I would like to hear a bit more on this: is it going to be nume= rical? For
instance, 1 means "no confidence" while 5 means "strong confi= dence", etc?

Thank you.
Take


> -----Original Messag= e-----
> From: Harrington, Christopher [mailto:Christo= pher.Harrington@emc.com]
> Sent: Friday, February 08, 2013 4:11 A= M
> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE = IETF'
> Subject: RE: [mile] IOCs
>
> With respect to tyi= ng things back to threat actors, from what I have
> seen and use this is a generally accepted grouping:
>
> Indicator --> I= ndictor Set --> Campaign --> Threat Actor
>
> Campaign a= nd Threat Actor are where having a "Confidence" attribute
> would be= beneficial as making those associations is not a perfect
> science = by any means.
>
> Thanks,
>
> --Chris
> >
> -----Original Message-----
> From: Moriarty, Kathleen<= br>> Sent: Thursday, February 07, 2013 2:00 PM
> To: Takeshi Takah= ashi; Harrington, Christopher; Stoecker, Paul; 'MILE
> IETF'
>= Subject: RE: [mile] IOCs
>
> Hi Take & others,
> > Thanks for chiming in, I've been talking about this with Chris and a=
> few others on their use cases and would like more opinions. = I'll
> provide an option below from what we have discussed from a C= IRC view
> point.  We are also wondering how to also provide logic in IODEF that
> could cross over into SCI attached sc= hemas or IODEF extensions (the
> solutions may all tie together with= this discussion - or there may be
> better/more elegant solutions o= thers would like to propose).
>
> -----Original Message-----> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.= go.jp]
> Sent: Tuesday, February 05, 2013 12:04 PM
> To: Ha= rrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE
> I= ETF'
> Subject: RE: [mile] IOCs
>
> > I like this dis= cussion.
> > I agree, it would be good idea to have indicator iden= tifiers inside
> > the IOC-related classes.
>
> KMM:= At the class level, we may have several indicators listed that
> sh= ould be viewed as a set and may have another instance of that same
> class that is a related issue, but a separate set.  We could= as you
> say, list the indicator IDs connected through the referenc= e class. 
> The set IDs might give us other ways to group the v= alues when we get
> into logic and relationships between sets or ind= icators.  This could
> also be a way to connect indicators or s= ets across XML documents that
> could have been shared previously.&n= bsp; If there are a large number of
> indicators in the set, then th= is becomes useful, for smaller sets, I
> agree it doesn't make as mu= ch sense.
>
> What do others think?
>
> >> = Then for indicators not included in the base schema that may not
> &= gt;> fit into a category in the SCI draft, do we create a place for
= > >> these off of SCI or right off of the IODE schema in EventData= ?
> >> (more details
> on
> >> this in my first message).
> >
> > If we could see any indica= tor of compromise as computer event
> > record, we could use SCI:= EventReport class as the place for the
> > XML-based IOCs that co= uldn't fit anywhere else.
>
> KMM: That sounds like a good ide= a to me.  This should go into guidance
> in the SCI draft. = ; Does anyone else want to weigh in?
>
> >
> > For= the non-XML IOCs, we could use RecordData class, as suggested.
> KMM= : Sounds good, thanks!
>
> > I agree to have indicator_uid,= but I am not sure about the needs of
> > the indicator_set_id.> > I understand we could do some grouping of individual indicator_= uids
> > and its usability, but I am not sure whether we do not h= ave any
> > other way to express these groupings.
> > Fo= r instance,  a Reference class refers to several indicadtor_uids.
> In
> > this case, they could be, in a se= nse, grouped. Isn't it enough?
>
> KMM: It may be, what do you= think about large sets of indicators or
> subsequent messages that = add indicators to existing sets?  Would this
> happen?  Wo= uld it be easier to express relationships with sets of
> indicators = in addition to individual indicators?  By using this, it
> coul= d give us a unique way to also provide the logic and relationships
>= in a new class of IODEF so we don't have to worry about adding it into > the current
structure.
> If there are better ways to handle = that, and others can provide some
> options, that would be appreciat= ed!
>
> Thank you,
> Kathleen
>
> > I wo= uld appreciate if anybody could share expertise on this. Though
> I> > think I have read all the emails in the list, I might have
> > mis-understood some points.
> >
> > B= y the way, I think the indicator_uids should be added to the SCI
classes= '
> > attributes so that they can be correlated with another infor= mation
> > as
> well.
> >
> > Thanks
&= gt; > Take
>
>
>
> From: mile-bounces@i= etf.org [mailto:mile-bounces@ietf.org] On Behalf
> Of = Harrington, Christopher
> Sent: Tuesday, February 05, 2013 4:25 AM> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF
> Subject: Re= : [mile] IOCs
>
> I think some sort of group ID would do the t= rick. We also need a
> logical and / or somewhere to show relationsh= ip between indicators. If
> I give you
> 2
> registry keys do they both have to be present to be an indication of
> compr= omise or is either one by themselves an indicator? Both would
> have= the same group ID since they are related.
>
> Thanks,
>= --Chris
>
> From: Stoecker, Paul
> Sent: Sunday, Februa= ry 03, 2013 8:26 PM
> To: Moriarty, Kathleen; Harrington, Christopher= ; MILE IETF
> Subject: Re: [mile] IOCs
>
> What if we ad= ded indicator group ID along with the indicator_uid? 
> This wo= uld allow you to group indicators that are related into the
> same g= roup ID.
>  Would this resolve the issue?
>
> It is= either that or going back to adding a Detection (or Indicators)
> c= lass that will should be used to take all of the indicators put them
&g= t; into one place and have the ability to group the ones that go
> t= ogether.  I don't mean a place to put indicators that are missing
> from IODEF.I mean a place in the IODEF document where you= put the
> indicators that are used for detection and prevention of = the shared
> Incident.  I don't know the answer here, but there= has got to be a
> good way for indicators to be identified and bein= g able to group them
> as Chris has suggested without basically recr= eating something
> complicated like STIX.
>
> Paul
&= gt;
>
> Paul W. Stoecker, Ph.D.
> SMC Lead Content Arch= itect
> RSA, The Security Division of EMC
> cell: 302.379.3375 = | e: paul.stoecker@rsa.com
>
>
> From: <Mo= riarty>, Kathleen <kathleen.moriarty@emc.com>
>= ; Date: Sunday, February 3, 2013 5:11 PM
> To: "Harrington, Christopher" <Christopher.Harrington@emc.com>, = MILE
> IETF <mile@ietf.org>
> Subject: Re: [mile] IOCs=
>
> Hi Chris,
>
> I agree, we have some work to = do in the updated IODEF, RFC5070-bis.
>
> The list has already= said they would like to see indicators added to
> the definitions i= n RFC5070-bis, to be more explicit about including
> indicators and = sets of indicators in IODE documents as opposed to
> 'parts of an in= cident or the useful information on an incident for
> sharing purpos= es.  It was written before we used terms like
> indicators.&nbs= p; With that in mind, Rosella proposed a number of changes
> back in= July, both for guidance and for
format
> updates.  It may he= lp to have the first draft try to address at least
> some of these iss= ues so people can understand the problems and at
> least a proposed = solution.
>
> As you point out, we need to be able to show rel= ationships between
> sets of indicators, where we may have a few set= s of indicators that
> could have a relationship to each other withi= n a document.  In the
> July presentation, one of the questions= was to see if we should add
> new category attribute values for the= System class that would connect
> the list of included indicators.&= nbsp; I think we should still keep the
> concept of a Node to a sing= le node, but perhaps within System, list
> multiple sets of Nodes th= at may be one type of attack.  Rosella had
> suggested pulling = forward the "FraudType" from RFC5901, this would
> help solve the is= sue as NodeRole values would compliment an AttackType
> (FraudType values could be included in AttackType or some broader
>= term).  It may be better to have the FraudTypes, plus attribute value= s
> like "C2-server", "sinkhole",  "MalwareDistribution" for ad= ded context
> so you know what to do with the received set of indica= tors.
>
> I am proposing that we change IODEF to include multi= ple sets of
indicators,
> add an AttackType attribute (or some oth= er name), a method to connect
> indicators and indicator sets within= an IODEF using an attribute of
> indicator_uid (or some other name)= with a string value to make the
> connection points, and add a few = indicators that are commonly shared
> into the base IODEF.
> <= br>> Back in July, we talked about adding Registry Key/Value pairs and <= br>> hashes to the main IODEF document (trying to see if this will help =
> Chris below).  What if we added the Registry Key/Value pairs as a
> class off of RecordData, using a similar structure to = what is in
> RFC5901, and also added the ability to include hashes i= n RecordData? 
> I think if we then had the indicator_uid at th= e RecordData level, we
> could connect a set within that structure a= nd repeat the structure for
> other sets in the same way we would do= with Node inside of the System
> class, using the indicator_uid to = tie the set together.  Then at the
> more specific level for th= e hash, registry Key/value, IP, etc. use an
> indicator_uid if we ne= eded them marked at this level as well?  Maybe
> we want indica= tor_set at the higher level?  I'd like some opinions on
> this = approach.  +1 if you agree, suggestions if you have other ideas
&g= t; that may work better.
>
> We'll also need to worry about ma= rking the indicators to prevent
> forward sharing when not permitted.  We may want to use these values
> or something els= e.
>
> Thank you!
> Kathleen
>
> From: Harr= ington, Christopher
> Sent: Friday, February 01, 2013 12:01 PM
>= ; To: Moriarty, Kathleen; MILE IETF
> Subject: RE: [mile] IOCs
>= ;
> I think we have a bigger relationship issue to address. Let use = the
> Watchlist Use Case. A bunch of indicators are sent in one mess= age. In
> that message we could have groupings of indicators that we= need to
> show are
> related:
>
> Two or more in= dicators of different type that relate to the same threat:
>  &n= bsp;     The file hash of a malicious file and the URL of the C2 = that
> the file uses. Either or both may be present to indicate a co= mpromise.
>
> Two or more indicators of the same type that rel= ate to the same threat:
>        2 different registry values for the same registry key. If
> either va= lue is present it is a compromise indicator but both will not
> bepresent.
>
> The problem compounds itself very quickly. Cons= ider the scenario where
> both groupings above are part of the same = threat. I need to show that
> logical groupings of Indicators are re= lated as well. We can't send
> multiple IODEF messages for this from= what I remember reading.
>
> The last one I can think of woul= d be when you have 2 different
> indicators that represent the same = indicator. It's not uncommon to
> send both the
> MD5
> = and SHA1 hash of a malicious file. The indicator is the file but the
&g= t; IOCs are the 2 hash values. How do we show they are related? If we use <= br>> a unique Inidcator ID for each hash value there needs to be a highe= r
> level
grouping.
>
> Thoughts?
>
> Thanks,
>
> --Chris
>
> Christopher Har= rington
> Consulting Security Engineer
> GSO - Critical Inciden= t Response Center EMC - Where Information Lives
> 174 Middlesex Turnp= ike
> Bedford, MA 01730
> 781-515-5862 (work)
> 603-583-1= 585 (cell)
>
> From: mile-bounces@ietf.org [mailto:<= a href=3D"http://us.mc534.mail.yahoo.com/mc/compose?to=3Dmile-bounces@ietf.= org">mile-bounces@ietf.org] On Behalf
> Of Moriarty, Kathleen> Sent: Friday, February 01, 2013 11:28 AM
> To: MILE IETF
>= ; Subject: Re: [mile] IOCs
>
> All -
>
> I'd like= your input and will refocus the thread to get opinions from
> the l= ist on options to help solve the problems raised in my message
> and= additionally in Paul's message.
>
> Interesting point, C. Henry.  Our objective here is to have machine
> automated exch= anges, so we rely on encryption rather than obfuscation
> to achieve= the necessary level of confidentiality.
>
> Paul mentioned th= e need to distinguish indicators of compromise from
> context inform= ation that may also include IP address or other data
> that could be= indicators.  The question I raised was on how to connect
> set= s of indicators in the same IODEF document, assuming the ability to
>= ; have watchlists that could have several sets of indicators included,
= > as well as to connect indicators that may be included in embedded
= > schemas.
>
> If we add an attribute on all of the relevan= t indicators, let's say
> 'indicator-uid' how do we mark the indicat= ors?  Do we use this to mark
> who sent the indicator as well s= o that we can prevent forward sharing
> when it is not permitted or handle that separately?
>
> Then for indicators = not included in the base schema that may not fit
> into a category i= n the SCI draft, do we create a place for these off
> of SCI or righ= t off of the IODE schema in EventData? (more details on
> this in my= first message).
>
> Comments and questions encouraged to figu= re out the right technical
> solution to have this machine automatab= le.
>
> Thank you,
> Kathleen
>
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Be= half
> Of C.
> Henry Adams & BIE
> Sent: Monday, Jan= uary 28, 2013 11:25 PM
> To: MILE IETF
> Subject: Re: [mile] IO= Cs
>
> Temporal Dependency sounds interesting.  I remembe= r when I first ran
> across this particular craft, an experienced col= league asked me a
> peculiar question.  He said, " How do you s= top someone from tracking
> the IP Address to your computer?"
>= ;
> I replied, "I don't know, how?"
>
> Then he said, "= Cut the dog-gone thing off  and the modem that it is
> connected= - which is constantly on!"   LOL
>
> Here's my = point (Hypothetical Situation) :  There is a 1st Responder
> se= arching a Neighborhood for Survivors which were hit by a Disaster or
&g= t; let's just say "Live" Terrorist Situation.  He /or She needs to > communication back to other Officials that he /or somehow is in
&= gt; Danger.  The device used to communicate has been captured by the g= reat
> minds of the enemy.  It's only a matter of time before t= hey utilize
> reverse engineering to figure out how it functions.  However, their
> pride comes before a fall when se= eking the location of other similar
> devices to attack.  Why? = Perhaps the less thought of concepts that
> makes the device functio= n properly, saves the day by disguise or
> cutting it off (figurativ= ely speaking).
>
> Just a visionary thought.
>
> = C. Henry Adams
> chenryadams@biemediagroup.com
&= gt; http://biemediag= roup.com
>
>
> The information contained herein is = for the exclusive use of the
> original recipient. This information = is granted for limited
> distribution within the recipient's place o= f business for planning
> purposes only. Further dissemination, whet= her private or public is
> prohibited.
>
> --- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> wrote:
> =
> From: Dave Misell <david.misell@bcs.org>
> Su= bject: Re: [mile] IOCs
> To: "C. Henry Adams & BIE" <c= hatlga2000@yahoo.com>
> Date: Monday, January 28, 2013, 9:25 P= M UID could be mirrored with DNS
> SEC a pemanent and temporal key, = with a temporal Id?
>
> Yours Faithfully,
>
> Dav= e Misell MSc CISSP
> SilentCircle  dsm
> 07710 380044
&= gt; david.misell@bcs.org
>
>
> On 29 Jan 2013,= at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com>
> wrote:
>
> > Seri= alization of a particular Lists of XML Classes in a unique way
> >= ; was
> closely related to what I attempted to express when I stated,=
> "consider to a degree what appears to be illogical in brilliant m= inds
> in some instances."
> >
> > However, I see = Dr. Stoecker's point a little clearer.  However, it
> > woul= d
> be nice if the UID was in some way disguised from those who study= this
> Security Art Form in a negative way.
> >
> &g= t; C. Henry Adams
> > chatlga2000@yahoo.com (Direct Emai= l) chenryadams@biemediagroup.com
> >
> >
> > The information contained herein is for the exclusive us= e of the
> > original
> recipient. This information is grant= ed for limited distribution within
> the
> recipient's place of= business for planning purposes only. Further
> dissemination, whethe= r private or public is prohibited.
> >
> > Re: [mile] IOC= s
> >
> > Sunday, January 27, 2013 8:52 PM
> > F= rom:
> > "Stoecker, Paul" <Paul.Stoecker@rsa.com><= br>> > To:
> > "mile@ietf.org" <mile@ietf.org>
= > > I would like to look at this from a slightly different
> &g= t; perspective=C5=A0let's say I get an XML document that tells me about an<= br>> > incident.  This document has source IP and destination IP that i= s
> > being shared.  However, what I don't know is which IP a= ddress is my
> > indicator and which is just a contextual piece of= information.  This
> > means that my detection product isn't= going to know which one to use
> > either, because there is nothi= ng to tell me which IP is the one, even
> > if the roles are set i= t still might not be enough to tell my system
> which
> one I s= hould use as the indicator.
> >
> > If we had something l= ike indicator_id as an attribute, it would allow
> > us to easily = identify indicators from contextual data.  I do admit to
> > = being biased as I have spent much of my career working on the
> > = monitoring and detection side of these things, so I am just thinking
>= ; > of ways to make it very clear what the indicators are in the XML
> > document and the other data that may be important as I in= vestigate
> > activity that I have detected off of those indicator= s.
> >
> >
> > I did suggest the detection class= , but I think we may get more
> > flexibility with the indicator_u= id.  One thing that I haven't
> > considered is the UID porti= on of this=C5=A0how do we use that UID?  How is
> > the UID c= reated?  Are there standards for UIDs?
> >
> > Regar= ds,
> >
> > Paul
> >
> >
> >> > Paul W. Stoecker, Ph.D.
> > SMC Lead Content Architect=
> > RSA, The Security Division of EMC
> > cell: 302.379.= 3375 | e: paul.stoecker@rsa.com
> >
> > --- On = Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote:
> >
> > From: C.= Henry Adams & BIE <chatlga2000@yahoo.com>
> >= Subject: RE: [mile] IOCs
> > To: "KathleenMoriarty" <kathleen.moriarty@emc.com>
> > Cc: mile@ietf.org
&g= t; > Date: Saturday, January 26, 2013, 6:17 PM
> >
> >= Greetings Kathleen,
> >
> > Your logic stimulates my vis= ionary brain because I'm amazed at the
> > many
> avenues yo= u review with this approach at once.  However,  could you share> a
> few advantages and disadvantages to the latter?
> &g= t;
> >
> -------------------------------------------------------------= -------
> --------
> ------------------------------------------= ----
> > "we could continue to group items in logical places as is= done now in
> IODEF and then have the extension point for combined i= ndicators via SCI."
> >
> >
> ---------------------= -----------------------------------------------
> --------
> --= -------------------------------------------
> >
> > You p= ointed out what you consider to be logical places, but if I
> > wa= nted to
> protect information from parties capable of ascertaining it= from your
> logical places, perhaps we should also consider to a deg= ree what appears
> to
> be illogical in brilliant minds in some= instances.
> >
> >
> >
> > C. Henry Ad= ams
> > chatlga2000@yahoo.com (Direct Email)
> > che= nryadams@biemediagroup.com
> >
> > The information co= ntained herein is for the exclusive use of the
> > original
>= ; recipient. This information is granted for limited distribution within> the
> recipient's place of business for planning purposes only.= Further
> dissemination, whether private or public is prohibited.> >
> > --- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>
> wrote:
> >
> &g= t; From: Moriarty, Kathleen <kathleen.moriarty@emc.com>=
> > Subject: RE: [mile] IOCs
> > To: "C. Henry Adams & BIE" = <chatlga2000@yahoo.com>, "mile@ietf.org"
> <mile@i= etf.org>
> > Date: Saturday, January 26, 2013, 10:13 AM
= > >
> > Hello C. Henry & others,
> >
> &g= t; Thanks for taking a look at this.  We have a few considerations in<= br>> > this
> email thread I would like to hear thoughts on (an= d there may be more once
> RFC5070-bis is actively edited).
> &= gt;
> > The AdditionalData class and the RecordItem class both all= ow for
> > non-XML
> extensions.  Where you place the e= xtensions should be specific to the
> logical grouping of the parent elements so you can understand more about
> the
> included dat= a in most cases.
> >
> > The Impact class can be used to = provide context information on the
> included data of the report and = also can include a confidence rating on
> the
> report as a who= le.  Extensions related to impact would be one level higher
> (a= t the moment) in the Assessment class using the AdditionalData extension> point.
> >
> > Take asked about including vulnerabi= lity information, I would think
> > that
> would fit under t= he Vulnerability extension point of the SCI draft in
> the
> Me= thod class.  He did ask about non-XML.  RecordItem or AdditionalD= ata
> do
> allow for non-XML extension points, we could either = have the SCI draft
> handle these as well or have the extensions that= are non-XML come directly
> off the AdditionalData or RecordItem classes according to what makes sense
> from a logical st= andpoint.
> >
> > As for my question, it was two-fold.> >
> > Indicator based schemas have a reference number or = a GUID for the
> > various
> indicators they share.  If= we are extending to embed other schemas that
> include such referenc= e or GUID identifiers, do we want to add an attribute
> to the variou= s elements in IODEF that could be indicators?  Is this enough
> = to make the connections or is something else else needed?  We could ad= d
> something like an Indicator_ID in RFC5070-bis which would then co= rrelate
> to
> the reference or GUID identifiers.
> ><= br>> > Then the other question was on how to include indicators that = are not
> > in
> the base schema that may be related or have= language with "and" "or" to
> specify the relationships.  In some cases, you will want to group these
> i= ndictors in one extension point, where they may fit logically in multiple> places if the relationships did not need to be shown in the data
= > format.  If
> we have cases like this where you need more c= omplex representations,
> should
> we use one extension point v= ia the SCI draft off of the EventData class
> AdditionalData extensio= n point?  Opinions are needed here....
> >
> > A few= people have mentioned wanting to include some commonly shared
> indi= ctors into the base IODEF document.  We could have a catch-all class> that does this and has an extension point off of it in EventData or = we
> could
> continue to group items in logical places as is do= ne now in IODEF and
> then
> have the extension point for combi= ned indicators via SCI.  I think I like
> the latter approach.
> >
> > Thank you,
> > Kathleen
&g= t; > ________________________________________
> > From: m= ile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C.<= br>> > Henry
> Adams & BIE [chatlga2000@yahoo.com= ]
> > Sent: Saturday, January 26, 2013 3:05 AM
> > To: mile= @ietf.org
> > Cc: C. Henry Adams
> > Subject: Re: [mi= le] IOCs
> >
> > Greetings Everyone,
> >
>= > Take mentioned two types of indicators based on the :
> >> --------------------------------------------------------------------<= br>> --------
> --------------------------
> > 1) If the indicat= ors are something like an XML-based alert/warning of
> > informati= on leakage, it could be an event that are conveyed in the
> > SCI'= s EventReport class, IMHO.
> >
> > 2) If the indicators a= re something like an non-XML ones, I guess it
> > could
> be=
> > conveyed without using SCI draft.
> > For instance, = we could use Impact class of the base IODEF to convey
> > the indi= cators.
> > We could for instance extend the list of indicators of= the Impact
> > class,
> if
> > needed.
> >= ;
> -----------------------------------------------------------------= ---
> --------
> --------------------------
> >
>= ; > In doing so he pointed out the "Impact Class"
> >
> &= gt; Whereas, Kathleen stated,
> >
> >
> --------------------------------------------------------------------
&g= t; --------
> -------------------------
> > For the discussi= on below, I was thinking more of combined set with
> relationships th= at may be included in a single extension point, so that's
> why I was= thinking about the EventData class, but there may be better
> locati= ons or a specific area within the EventData.
> >
> > Paul= Stoecker had suggested a "Detection" class as a consideration.
> >= ;
> -----------------------------------------------------------------= ---
> --------
> ------------------------
> >
> = > Kathleen thoughts related yet still with other indicators and the
&= gt; EventData Class.
> >
> > Is there a possible way to c= reate a new XML class which encompass
> combining the EventData, Dete= ction and base IODEF classes to simplify
> this
> issue?
> >
> >
> > C. Henry Adams
> > = chatlga2000@yahoo.com (Direct Email)
> > c= henryadams@biemediagroup.com
> >
> >
> > The= information contained herein is for the exclusive use of the
> > = original
> recipient. This information is granted for limited distrib= ution within
> the
> recipient's place of business for planning= purposes only. Further
> dissemination, whether private or public is= prohibited.
> > _______________________________________________> > mile mailing list
> > mile@ietf.org
> > https://www.ietf.org/mailman/listinfo/mile
> <= br>>
--1458340343-1531119564-1360698335=:82136-- From kathleen.moriarty@emc.com Tue Feb 12 12:57:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C0021F8BDD for ; Tue, 12 Feb 2013 12:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[AWL=-2.137, BAYES_40=-0.185, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3IFNrqCCyB0 for ; Tue, 12 Feb 2013 12:57:16 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7790E21F8B9E for ; Tue, 12 Feb 2013 12:57:16 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CKv7CW003863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 15:57:15 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 12 Feb 2013 15:56:53 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1CKuqML021781; Tue, 12 Feb 2013 15:56:52 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 12 Feb 2013 15:56:51 -0500 From: "Moriarty, Kathleen" To: "C. Henry Adams & BIE" , MILE IETF Date: Tue, 12 Feb 2013 15:56:50 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4JWa4fqKaIjOloRQG652AFNfIt7gAAkApg Message-ID: References: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CEBDF152MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:57:21 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CEBDF152MX15Acorpemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBzZWN0aW9uIDMuMTAuNCBvZiBSRkM1MDcwIGFzIGEgc3RhcnRpbmcgcG9pbnQu ICBXZSBjYW4gY2hhbmdlIGl0IGlmIGl0IG5lZWRzIHRvIGJlIGNoYW5nZWQuICBUaGUgdmFsdWUg aXMgZm9yIGEgY29uZmlkZW5jZSByYXRpbmcgb24gdGhlIGluZGljYXRvcnMgc2hhcmVkLiAgVGhl IGRlZmluaXRpb25zIG1heSBiZSBoZWxwZnVsIGZvciBhbnlvbmUgd2hvIHdhbnRzIHRvIHdvcmsg b24gdGhpcyBkaXNjdXNzaW9uLiAgSU9ERUYgaGFzIHZhcmlvdXMgbWFya2VycyB0aGF0IGNhbiBi ZSB1c2VkIGluIGEgY29tcGxpbWVudGFyeSB3YXkgd2l0aG91dCBjb25mbGF0aW5nIHRoZSBtYXJr ZXJzIG1lYW5pbmcuDQoNCkkgdGhpbmsgc29tZSBwZW9wbGUgdXNpbmcgSU9ERUYgZmluZCB0aGUg bnVtZXJpY2FsIHZhbHVlcyBtb3JlIGhlbHBmdWwsIGFuZCBpdCB3b3VsZCBiZSBnb29kIHRvIHVu ZGVyc3RhbmQgd2hhdCBwZW9wbGUgaGF2ZSBsZWFybmVkIGZyb20gdXNpbmcgdGhlIGN1cnJlbnQg c3RydWN0dXJlICh3aGF0IHdvcmtzL2RvZXMgbm90IHdvcmspLiAgVGhlIHNjYWxlcyBJIGhhdmUg c2VlbiBhcmUgMC0xMDAuICBUaGVyZSBpcyBvZiBjb3Vyc2UgYSBzdWJqZWN0aXZlIGVsZW1lbnQg dG8gYXNzaWduaW5nIGEgbnVtZXJpY2FsIHZhbHVlIHRvIHRoZSBjb25maWRlbmNlIGFuZCBpdCBt YXkgdmFyeSBmcm9tIGVudGl0eSB0byBlbnRpdHkuICBXaXRoIHRoaXMgdHlwZSBvZiByYXRpbmcg eW91IG1heSBuZWVkIHRvIGNvbnNpZGVyIHdobyBpdCBjYW1lIGZyb20gYW5kIGhvdyB0aGV5IHNj b3JlZCB0aGUgY29uZmlkZW5jZSByYXRpbmcgdG8gbWFwIHRvIHlvdXIgb3duIHJhdGluZy4gIEl0 IHdvdWxkIGJlIGdvb2QgdG8gaGVhciBtb3JlIHRob3VnaHRzIG9uIHRoaXMuDQoNClRoYW5rcywN CkthdGhsZWVuDQoNCkZyb206IEMuIEhlbnJ5IEFkYW1zICYgQklFIFttYWlsdG86Y2hhdGxnYTIw MDBAeWFob28uY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgMjo0NiBQTQ0K VG86IE1JTEUgSUVURg0KQ2M6IE1vcmlhcnR5LCBLYXRobGVlbjsgJ1Rha2VzaGkgVGFrYWhhc2hp JzsgU3RvZWNrZXIsIFBhdWwNClN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KDQoNClJlZ2FyZGlu ZyB0aGUgSU9DcyBvciBJbmRpY2F0b3JzIG9mIENvbXByb21pc2UsIENocmlzIG1hZGUgYSB2aXRh bCBwb2ludC4gIERpZmZlcmVudCBDb25maWRlbmNlIGxldmVscyB3aWxsIGNhdXNlIGNvbmZ1c2lv bi4gIEl0IGFwcGVhcnMgdGhhdCB0aGVyZSBtYXliZSBhIG5lZWQgZm9yIHNvbWUgdHlwZSBvZiBz aW1wbGlmaWVkIHN0YW5kYXJkaXphdGlvbiB0byBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIGFsbCBT aGFyaW5nIEdyb3VwcyBpbiB0aGlzIHJlZ2FyZC4NCg0KUGVyaGFwcyBudW1lcmljYWwgc2Nvcmlu ZyBzZXQgYXQgbG93ZXIgdmFsdWVzIHNob3VsZCBleHByZXNzIGxldmVscyBvZiB1cmdlbmN5Lg0K KCBpLmUuICAxID0gTGVzcyBMaWtlbHksICAgMiA9IFByb2JhYmxlLCAgMyA9IEEgQ29uY2Vybiwg IDQgPSAgVXJnZW50LCAgNSA9IEltbWluZW50ICkNCg0KVGhhbmtzLA0KQy4gSGVucnkgQWRhbXMN Cg0KDQoNCkkgc2VlIHNvbWUgY29uZnVzaW9uIGNvbWluZyBkb3duIHRoZSBwaWtlIGlmIHdlIHN0 YXJ0IHVzaW5nIENvbmZpZGVuY2UgdGhlDQp3YXkgaXQgaXMgc3VwcG9ydGVkLiBJZiBJIGFtIHVz aW5nIGxvdy9tZWQvaGlnaCBhbmQgc29tZW9uZSBzZW5kcyBtZSBhbiBJb0MNCndpdGggYSBzY29y ZSBvZiA3MCwgd2hhdCBkb2VzIHRoYXQgbWVhbiB0byBtZT8gV2hhdCBpZiBJIGFtIHVzaW5nIGEg c2NhbGUgb2YNCjEgdG8gNCBhbmQgc29tZW9uZSBlbHNlIGlzIG9uIGEgc2NhbGUgb2YgMSB0byA1 PyBXZSBsb3NlIHRoZSBhYmlsaXR5IHRvDQpkZXNjcmliZSBzb21ldGhpbmcgd2l0aCBhIGNvbnNp c3RlbnQgbGFuZ3VhZ2UuIEl0IHJlYWxseSBnZXRzIHVnbHkgd2hlbiB3ZQ0Kc3RvcmUgSW9DIGZy b20gbXVsdGlwbGUgc291cmNlcy4gSSBoYXZlIGNvbmZpZGVuY2UgdmFsdWVzIHRoYXQgYXJlIG51 bWVyaWMNCmFzIHdlbGwgYXMgdGV4dC4gIE1ha2VzIHNlYXJjaGluZyAvIHNvcnRpbmcgdmVyeSBw cm9ibGVtYXRpYy4NCg0KQXQgdGhpcyBwb2ludCB3ZSBoYXZlIHRvIHJvbGwgd2l0aCB3aGF0IHdl IGhhdmUuIEkgd291bGQgc3Ryb25nbHkgcmVjb21tZW5kDQp0aGF0IHdlIHJldmlzaXQgdGhpcyBh dCBzb21lIHBvaW50Lg0KDQpUaGFua3MsDQoNCi0tQ2hyaXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE1vcmlhcnR5LCBLYXRobGVlbg0KU2VudDogVHVlc2RheSwgRmVicnVh cnkgMTIsIDIwMTMgOTo1OSBBTQ0KVG86IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyAnVGFrZXNo aSBUYWthaGFzaGknOyBTdG9lY2tlciwgUGF1bDsgJ01JTEUNCklFVEYnDQpTdWJqZWN0OiBSRTog W21pbGVdIElPQ3MNCg0KSGkgQ2hyaXMgJiBUYWtlLA0KDQpJJ2xsIGp1c3QgZm9jdXMgb24gdGhl IGNvbmZpZGVuY2Ugc2NvcmluZy4gIFJpZ2h0IG5vdywgdGhlIHNjaGVtYSBhbGxvd3MgZm9yDQp5 b3UgdG8gZWl0aGVyIHVzZSBhIG51bWVyaWNhbCBzY29yZSBPUiB0aGUgcmF0aW5ncyBvZiBsb3cs IG1lZGl1bSwgYW5kIGhpZ2guDQpEaWZmZXJlbnQgc2hhcmluZyBncm91cHMgY2FuIGRlY2lkZSBo b3cgdGhleSB3YW50IHRvIHNoYXJlIHRoZSBkYXRhLiAgSWYNCnBlb3BsZSB3ZXJlIHRvIHVzZSB0 aGUgbnVtZXJpY2FsIHZhbHVlcywgSSBhZ3JlZSBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUN Cmd1aWRhbmNlLiAgVGhpcyBjb3VsZCBnbyBpbiB0aGUgSU9ERSBndWlkYW5jZSBkb2N1bWVudC4N Cg0KSSBoYXZlIHNlZW4gZXhhbXBsZXMgb2YgY3VycmVudCB1c2VycyB0aGF0IHVzZSBlYWNoIG9m IHRoZSBhcHByb2FjaGVzLCBzbw0Kd2UnbGwgbmVlZCB0byBrZWVwIHRoZSBvcHRpb24gZm9yIGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IGFuZCBpdCBpcyBuaWNlIHRvDQprZWVwIGluIGZsZXhpYmxl IG9wdGlvbnMgd2hlcmUgd2UgY2FuLg0KDQpUaGFuayB5b3UsDQpLYXRobGVlbg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXINClNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEzIDk6MjIgQU0NClRvOiAnVGFrZXNoaSBUYWthaGFz aGknOyBNb3JpYXJ0eSwgS2F0aGxlZW47IFN0b2Vja2VyLCBQYXVsOyAnTUlMRSBJRVRGJw0KU3Vi amVjdDogUkU6IFttaWxlXSBJT0NzDQoNClRoZSBudW1iZXIgb2YgaW5kaWNhdG9ycyB3b3VsZG4n dCBuZWNlc3NhcmlseSBkcml2ZSB0aGUgdXNlIG9mDQppbmRpY2F0b3Jfc2V0X2lkLiBUaGUgcHVy cG9zZSBpcyB0byBzaG93IHJlbGF0aW9uc2hpcC4gSWYgSSBzZW50IDMgSVANCmFkZHJlc3NlcyB0 aGF0IHdlcmUgdXNlZCBhcyBDMiBmb3IgMyBkaWZmZXJlbnQgY2FtcGFpZ25zIEkgd291bGQgaGF2 ZQ0Kc2VwYXJhdGUgaW5kaWNhdG9yX3NldF9pZHMsIGVhY2ggd2l0aCBvbmUgb2YgdGhlIDMgQzIg SVBzDQoNCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgYSBzaW1wbGUgbG93LCBtZWRpdW0sIGhpZ2gu IEkgdGhpbmsgaWYgd2UgYnJlYWsgaXQNCmRvd24gdG8gbW9yZSBsZXZlbHMgdGhhbiB0aGF0IHdl IHdvdWxkIG5lZWQgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiBzY29yaW5nLA0KcmF0aW5nLCBldGMu IEkgdGhpbmsgbW9zdCBwZW9wbGUgc2hvdWxkIGJlIGFibGUgdG8gdW5kZXJzdGFuZCBsb3cvbWVk L2hpZ2gNCndpdGhvdXQgaGF2aW5nIHRvIGhhdmUgYSBtYXRoZW1hdGljYWwgbWV0aG9kIGZvciBh cnJpdmluZyBhdCB0aGUgbGV2ZWwuDQoNCkxvdyAtIEkgYW0gbm90IHN1cmUNCk1lZGl1bSAtIEkg YW0gcmVhc29uYWJseSBzdXJlDQpIaWdoIC0gSSBhbSB2ZXJ5IHN1cmUNCg0KDQpUaGFua3MsDQoN Ci0tQ2hyaXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRha2VzaGkgVGFr YWhhc2hpIFttYWlsdG86dGFrZXNoaV90YWthaGFzaGlAbmljdC5nby5qcDxodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz10YWtlc2hpX3Rha2FoYXNoaUBuaWN0Lmdv LmpwPl0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEzIDQ6MjEgQU0NClRvOiBIYXJy aW5ndG9uLCBDaHJpc3RvcGhlcjsgTW9yaWFydHksIEthdGhsZWVuOyBTdG9lY2tlciwgUGF1bDsg J01JTEUgSUVURicNClN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KDQpSZWdhcmRpbmcgdGhlIGlu ZGljYXRvcl9zZXRfaWQsIEkgYWdyZWUsIGl0IGlzIHVzZWZ1bCB3aGVuIHdlIG5lZWQgdG8gZGVh bA0Kd2l0aCBsYXJnZSBzZXRzIG9mIGluZGljYXRvcnMuDQpTaW5jZSBpbmRpY2F0b3Jfc2V0X2lk IGF0dHJpYnV0ZSBpcyBvcHRpb25hbCAocmlnaHQ/KSwgaXQgY291bGQgYmUgb21pdHRlZA0KaWYg d2UgbmVlZCB0byBkZWFsIHdpdGggb25seSBzbWFsbCBudW1iZXIgb2YgaW5kaWNhdG9ycy4NCg0K UmVnYXJkaW5nIHRoZSB1c2UgY2FzZSwgSSBsaWtlIHRoZSBpZGVhIG9mIHVzaW5nIHRoZSBjb25m aWRlbmNlIGF0dHJpYnV0ZQ0KZm9yIHRoZSByZWFzb24gQ2hyaXMga2luZGx5IGRlc2NyaWJlZC4N Ckkgd291bGQgbGlrZSB0byBoZWFyIGEgYml0IG1vcmUgb24gdGhpczogaXMgaXQgZ29pbmcgdG8g YmUgbnVtZXJpY2FsPyBGb3INCmluc3RhbmNlLCAxIG1lYW5zICJubyBjb25maWRlbmNlIiB3aGls ZSA1IG1lYW5zICJzdHJvbmcgY29uZmlkZW5jZSIsIGV0Yz8NCg0KVGhhbmsgeW91Lg0KVGFrZQ0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFycmluZ3RvbiwgQ2hy aXN0b3BoZXIgW21haWx0bzpDaHJpc3RvcGhlci5IYXJyaW5ndG9uQGVtYy5jb208aHR0cDovL3Vz Lm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Q2hyaXN0b3BoZXIuSGFycmluZ3Rv bkBlbWMuY29tPl0NCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAwOCwgMjAxMyA0OjExIEFNDQo+ IFRvOiBNb3JpYXJ0eSwgS2F0aGxlZW47IFRha2VzaGkgVGFrYWhhc2hpOyBTdG9lY2tlciwgUGF1 bDsgJ01JTEUgSUVURicNCj4gU3ViamVjdDogUkU6IFttaWxlXSBJT0NzDQo+DQo+IFdpdGggcmVz cGVjdCB0byB0eWluZyB0aGluZ3MgYmFjayB0byB0aHJlYXQgYWN0b3JzLCBmcm9tIHdoYXQgSSBo YXZlDQo+IHNlZW4gYW5kIHVzZSB0aGlzIGlzIGEgZ2VuZXJhbGx5IGFjY2VwdGVkIGdyb3VwaW5n Og0KPg0KPiBJbmRpY2F0b3IgLS0+IEluZGljdG9yIFNldCAtLT4gQ2FtcGFpZ24gLS0+IFRocmVh dCBBY3Rvcg0KPg0KPiBDYW1wYWlnbiBhbmQgVGhyZWF0IEFjdG9yIGFyZSB3aGVyZSBoYXZpbmcg YSAiQ29uZmlkZW5jZSIgYXR0cmlidXRlDQo+IHdvdWxkIGJlIGJlbmVmaWNpYWwgYXMgbWFraW5n IHRob3NlIGFzc29jaWF0aW9ucyBpcyBub3QgYSBwZXJmZWN0DQo+IHNjaWVuY2UgYnkgYW55IG1l YW5zLg0KPg0KPiBUaGFua3MsDQo+DQo+IC0tQ2hyaXMNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTW9yaWFydHksIEthdGhsZWVuDQo+IFNlbnQ6IFRodXJzZGF5 LCBGZWJydWFyeSAwNywgMjAxMyAyOjAwIFBNDQo+IFRvOiBUYWtlc2hpIFRha2FoYXNoaTsgSGFy cmluZ3RvbiwgQ2hyaXN0b3BoZXI7IFN0b2Vja2VyLCBQYXVsOyAnTUlMRQ0KPiBJRVRGJw0KPiBT dWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4NCj4gSGkgVGFrZSAmIG90aGVycywNCj4NCj4gVGhh bmtzIGZvciBjaGltaW5nIGluLCBJJ3ZlIGJlZW4gdGFsa2luZyBhYm91dCB0aGlzIHdpdGggQ2hy aXMgYW5kIGENCj4gZmV3IG90aGVycyBvbiB0aGVpciB1c2UgY2FzZXMgYW5kIHdvdWxkIGxpa2Ug bW9yZSBvcGluaW9ucy4gIEknbGwNCj4gcHJvdmlkZSBhbiBvcHRpb24gYmVsb3cgZnJvbSB3aGF0 IHdlIGhhdmUgZGlzY3Vzc2VkIGZyb20gYSBDSVJDIHZpZXcNCj4gcG9pbnQuICBXZSBhcmUgYWxz byB3b25kZXJpbmcgaG93IHRvIGFsc28gcHJvdmlkZSBsb2dpYyBpbiBJT0RFRiB0aGF0DQo+IGNv dWxkIGNyb3NzIG92ZXIgaW50byBTQ0kgYXR0YWNoZWQgc2NoZW1hcyBvciBJT0RFRiBleHRlbnNp b25zICh0aGUNCj4gc29sdXRpb25zIG1heSBhbGwgdGllIHRvZ2V0aGVyIHdpdGggdGhpcyBkaXNj dXNzaW9uIC0gb3IgdGhlcmUgbWF5IGJlDQo+IGJldHRlci9tb3JlIGVsZWdhbnQgc29sdXRpb25z IG90aGVycyB3b3VsZCBsaWtlIHRvIHByb3Bvc2UpLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBUYWtlc2hpIFRha2FoYXNoaSBbbWFpbHRvOnRha2VzaGlfdGFrYWhh c2hpQG5pY3QuZ28uanA8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89dGFrZXNoaV90YWthaGFzaGlAbmljdC5nby5qcD5dDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDA1LCAyMDEzIDEyOjA0IFBNDQo+IFRvOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgU3Rv ZWNrZXIsIFBhdWw7IE1vcmlhcnR5LCBLYXRobGVlbjsgJ01JTEUNCj4gSUVURicNCj4gU3ViamVj dDogUkU6IFttaWxlXSBJT0NzDQo+DQo+ID4gSSBsaWtlIHRoaXMgZGlzY3Vzc2lvbi4NCj4gPiBJ IGFncmVlLCBpdCB3b3VsZCBiZSBnb29kIGlkZWEgdG8gaGF2ZSBpbmRpY2F0b3IgaWRlbnRpZmll cnMgaW5zaWRlDQo+ID4gdGhlIElPQy1yZWxhdGVkIGNsYXNzZXMuDQo+DQo+IEtNTTogQXQgdGhl IGNsYXNzIGxldmVsLCB3ZSBtYXkgaGF2ZSBzZXZlcmFsIGluZGljYXRvcnMgbGlzdGVkIHRoYXQN Cj4gc2hvdWxkIGJlIHZpZXdlZCBhcyBhIHNldCBhbmQgbWF5IGhhdmUgYW5vdGhlciBpbnN0YW5j ZSBvZiB0aGF0IHNhbWUNCj4gY2xhc3MgdGhhdCBpcyBhIHJlbGF0ZWQgaXNzdWUsIGJ1dCBhIHNl cGFyYXRlIHNldC4gIFdlIGNvdWxkIGFzIHlvdQ0KPiBzYXksIGxpc3QgdGhlIGluZGljYXRvciBJ RHMgY29ubmVjdGVkIHRocm91Z2ggdGhlIHJlZmVyZW5jZSBjbGFzcy4NCj4gVGhlIHNldCBJRHMg bWlnaHQgZ2l2ZSB1cyBvdGhlciB3YXlzIHRvIGdyb3VwIHRoZSB2YWx1ZXMgd2hlbiB3ZSBnZXQN Cj4gaW50byBsb2dpYyBhbmQgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHNldHMgb3IgaW5kaWNhdG9y cy4gIFRoaXMgY291bGQNCj4gYWxzbyBiZSBhIHdheSB0byBjb25uZWN0IGluZGljYXRvcnMgb3Ig c2V0cyBhY3Jvc3MgWE1MIGRvY3VtZW50cyB0aGF0DQo+IGNvdWxkIGhhdmUgYmVlbiBzaGFyZWQg cHJldmlvdXNseS4gIElmIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZg0KPiBpbmRpY2F0b3Jz IGluIHRoZSBzZXQsIHRoZW4gdGhpcyBiZWNvbWVzIHVzZWZ1bCwgZm9yIHNtYWxsZXIgc2V0cywg SQ0KPiBhZ3JlZSBpdCBkb2Vzbid0IG1ha2UgYXMgbXVjaCBzZW5zZS4NCj4NCj4gV2hhdCBkbyBv dGhlcnMgdGhpbms/DQo+DQo+ID4+IFRoZW4gZm9yIGluZGljYXRvcnMgbm90IGluY2x1ZGVkIGlu IHRoZSBiYXNlIHNjaGVtYSB0aGF0IG1heSBub3QNCj4gPj4gZml0IGludG8gYSBjYXRlZ29yeSBp biB0aGUgU0NJIGRyYWZ0LCBkbyB3ZSBjcmVhdGUgYSBwbGFjZSBmb3INCj4gPj4gdGhlc2Ugb2Zm IG9mIFNDSSBvciByaWdodCBvZmYgb2YgdGhlIElPREUgc2NoZW1hIGluIEV2ZW50RGF0YT8NCj4g Pj4gKG1vcmUgZGV0YWlscw0KPiBvbg0KPiA+PiB0aGlzIGluIG15IGZpcnN0IG1lc3NhZ2UpLg0K PiA+DQo+ID4gSWYgd2UgY291bGQgc2VlIGFueSBpbmRpY2F0b3Igb2YgY29tcHJvbWlzZSBhcyBj b21wdXRlciBldmVudA0KPiA+IHJlY29yZCwgd2UgY291bGQgdXNlIFNDSTpFdmVudFJlcG9ydCBj bGFzcyBhcyB0aGUgcGxhY2UgZm9yIHRoZQ0KPiA+IFhNTC1iYXNlZCBJT0NzIHRoYXQgY291bGRu J3QgZml0IGFueXdoZXJlIGVsc2UuDQo+DQo+IEtNTTogVGhhdCBzb3VuZHMgbGlrZSBhIGdvb2Qg aWRlYSB0byBtZS4gIFRoaXMgc2hvdWxkIGdvIGludG8gZ3VpZGFuY2UNCj4gaW4gdGhlIFNDSSBk cmFmdC4gIERvZXMgYW55b25lIGVsc2Ugd2FudCB0byB3ZWlnaCBpbj8NCj4NCj4gPg0KPiA+IEZv ciB0aGUgbm9uLVhNTCBJT0NzLCB3ZSBjb3VsZCB1c2UgUmVjb3JkRGF0YSBjbGFzcywgYXMgc3Vn Z2VzdGVkLg0KPiBLTU06IFNvdW5kcyBnb29kLCB0aGFua3MhDQo+DQo+ID4gSSBhZ3JlZSB0byBo YXZlIGluZGljYXRvcl91aWQsIGJ1dCBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBuZWVkcyBvZg0K PiA+IHRoZSBpbmRpY2F0b3Jfc2V0X2lkLg0KPiA+IEkgdW5kZXJzdGFuZCB3ZSBjb3VsZCBkbyBz b21lIGdyb3VwaW5nIG9mIGluZGl2aWR1YWwgaW5kaWNhdG9yX3VpZHMNCj4gPiBhbmQgaXRzIHVz YWJpbGl0eSwgYnV0IEkgYW0gbm90IHN1cmUgd2hldGhlciB3ZSBkbyBub3QgaGF2ZSBhbnkNCj4g PiBvdGhlciB3YXkgdG8gZXhwcmVzcyB0aGVzZSBncm91cGluZ3MuDQo+ID4gRm9yIGluc3RhbmNl LCAgYSBSZWZlcmVuY2UgY2xhc3MgcmVmZXJzIHRvIHNldmVyYWwgaW5kaWNhZHRvcl91aWRzLg0K PiBJbg0KPiA+IHRoaXMgY2FzZSwgdGhleSBjb3VsZCBiZSwgaW4gYSBzZW5zZSwgZ3JvdXBlZC4g SXNuJ3QgaXQgZW5vdWdoPw0KPg0KPiBLTU06IEl0IG1heSBiZSwgd2hhdCBkbyB5b3UgdGhpbmsg YWJvdXQgbGFyZ2Ugc2V0cyBvZiBpbmRpY2F0b3JzIG9yDQo+IHN1YnNlcXVlbnQgbWVzc2FnZXMg dGhhdCBhZGQgaW5kaWNhdG9ycyB0byBleGlzdGluZyBzZXRzPyAgV291bGQgdGhpcw0KPiBoYXBw ZW4/ICBXb3VsZCBpdCBiZSBlYXNpZXIgdG8gZXhwcmVzcyByZWxhdGlvbnNoaXBzIHdpdGggc2V0 cyBvZg0KPiBpbmRpY2F0b3JzIGluIGFkZGl0aW9uIHRvIGluZGl2aWR1YWwgaW5kaWNhdG9ycz8g IEJ5IHVzaW5nIHRoaXMsIGl0DQo+IGNvdWxkIGdpdmUgdXMgYSB1bmlxdWUgd2F5IHRvIGFsc28g cHJvdmlkZSB0aGUgbG9naWMgYW5kIHJlbGF0aW9uc2hpcHMNCj4gaW4gYSBuZXcgY2xhc3Mgb2Yg SU9ERUYgc28gd2UgZG9uJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBhZGRpbmcgaXQgaW50bw0KPiB0 aGUgY3VycmVudA0Kc3RydWN0dXJlLg0KPiBJZiB0aGVyZSBhcmUgYmV0dGVyIHdheXMgdG8gaGFu ZGxlIHRoYXQsIGFuZCBvdGhlcnMgY2FuIHByb3ZpZGUgc29tZQ0KPiBvcHRpb25zLCB0aGF0IHdv dWxkIGJlIGFwcHJlY2lhdGVkIQ0KPg0KPiBUaGFuayB5b3UsDQo+IEthdGhsZWVuDQo+DQo+ID4g SSB3b3VsZCBhcHByZWNpYXRlIGlmIGFueWJvZHkgY291bGQgc2hhcmUgZXhwZXJ0aXNlIG9uIHRo aXMuIFRob3VnaA0KPiBJDQo+ID4gdGhpbmsgSSBoYXZlIHJlYWQgYWxsIHRoZSBlbWFpbHMgaW4g dGhlIGxpc3QsIEkgbWlnaHQgaGF2ZQ0KPiA+IG1pcy11bmRlcnN0b29kIHNvbWUgcG9pbnRzLg0K PiA+DQo+ID4gQnkgdGhlIHdheSwgSSB0aGluayB0aGUgaW5kaWNhdG9yX3VpZHMgc2hvdWxkIGJl IGFkZGVkIHRvIHRoZSBTQ0kNCmNsYXNzZXMnDQo+ID4gYXR0cmlidXRlcyBzbyB0aGF0IHRoZXkg Y2FuIGJlIGNvcnJlbGF0ZWQgd2l0aCBhbm90aGVyIGluZm9ybWF0aW9uDQo+ID4gYXMNCj4gd2Vs bC4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+IFRha2UNCj4NCj4NCj4NCj4gRnJvbTogbWlsZS1ib3Vu Y2VzQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3Rv PW1pbGUtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmc8aHR0 cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZS1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmDQo+IE9mIEhhcnJpbmd0b24sIENocmlzdG9waGVyDQo+IFNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDEzIDQ6MjUgQU0NCj4gVG86IFN0b2Vja2VyLCBQYXVs OyBNb3JpYXJ0eSwgS2F0aGxlZW47IE1JTEUgSUVURg0KPiBTdWJqZWN0OiBSZTogW21pbGVdIElP Q3MNCj4NCj4gSSB0aGluayBzb21lIHNvcnQgb2YgZ3JvdXAgSUQgd291bGQgZG8gdGhlIHRyaWNr LiBXZSBhbHNvIG5lZWQgYQ0KPiBsb2dpY2FsIGFuZCAvIG9yIHNvbWV3aGVyZSB0byBzaG93IHJl bGF0aW9uc2hpcCBiZXR3ZWVuIGluZGljYXRvcnMuIElmDQo+IEkgZ2l2ZSB5b3UNCj4gMg0KPiBy ZWdpc3RyeSBrZXlzIGRvIHRoZXkgYm90aCBoYXZlIHRvIGJlIHByZXNlbnQgdG8gYmUgYW4gaW5k aWNhdGlvbiBvZg0KPiBjb21wcm9taXNlIG9yIGlzIGVpdGhlciBvbmUgYnkgdGhlbXNlbHZlcyBh biBpbmRpY2F0b3I/IEJvdGggd291bGQNCj4gaGF2ZSB0aGUgc2FtZSBncm91cCBJRCBzaW5jZSB0 aGV5IGFyZSByZWxhdGVkLg0KPg0KPiBUaGFua3MsDQo+IC0tQ2hyaXMNCj4NCj4gRnJvbTogU3Rv ZWNrZXIsIFBhdWwNCj4gU2VudDogU3VuZGF5LCBGZWJydWFyeSAwMywgMjAxMyA4OjI2IFBNDQo+ IFRvOiBNb3JpYXJ0eSwgS2F0aGxlZW47IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyBNSUxFIElF VEYNCj4gU3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQo+DQo+IFdoYXQgaWYgd2UgYWRkZWQgaW5k aWNhdG9yIGdyb3VwIElEIGFsb25nIHdpdGggdGhlIGluZGljYXRvcl91aWQ/DQo+IFRoaXMgd291 bGQgYWxsb3cgeW91IHRvIGdyb3VwIGluZGljYXRvcnMgdGhhdCBhcmUgcmVsYXRlZCBpbnRvIHRo ZQ0KPiBzYW1lIGdyb3VwIElELg0KPiAgV291bGQgdGhpcyByZXNvbHZlIHRoZSBpc3N1ZT8NCj4N Cj4gSXQgaXMgZWl0aGVyIHRoYXQgb3IgZ29pbmcgYmFjayB0byBhZGRpbmcgYSBEZXRlY3Rpb24g KG9yIEluZGljYXRvcnMpDQo+IGNsYXNzIHRoYXQgd2lsbCBzaG91bGQgYmUgdXNlZCB0byB0YWtl IGFsbCBvZiB0aGUgaW5kaWNhdG9ycyBwdXQgdGhlbQ0KPiBpbnRvIG9uZSBwbGFjZSBhbmQgaGF2 ZSB0aGUgYWJpbGl0eSB0byBncm91cCB0aGUgb25lcyB0aGF0IGdvDQo+IHRvZ2V0aGVyLiAgSSBk b24ndCBtZWFuIGEgcGxhY2UgdG8gcHV0IGluZGljYXRvcnMgdGhhdCBhcmUgbWlzc2luZw0KPiBm cm9tIElPREVGLkkgbWVhbiBhIHBsYWNlIGluIHRoZSBJT0RFRiBkb2N1bWVudCB3aGVyZSB5b3Ug cHV0IHRoZQ0KPiBpbmRpY2F0b3JzIHRoYXQgYXJlIHVzZWQgZm9yIGRldGVjdGlvbiBhbmQgcHJl dmVudGlvbiBvZiB0aGUgc2hhcmVkDQo+IEluY2lkZW50LiAgSSBkb24ndCBrbm93IHRoZSBhbnN3 ZXIgaGVyZSwgYnV0IHRoZXJlIGhhcyBnb3QgdG8gYmUgYQ0KPiBnb29kIHdheSBmb3IgaW5kaWNh dG9ycyB0byBiZSBpZGVudGlmaWVkIGFuZCBiZWluZyBhYmxlIHRvIGdyb3VwIHRoZW0NCj4gYXMg Q2hyaXMgaGFzIHN1Z2dlc3RlZCB3aXRob3V0IGJhc2ljYWxseSByZWNyZWF0aW5nIHNvbWV0aGlu Zw0KPiBjb21wbGljYXRlZCBsaWtlIFNUSVguDQo+DQo+IFBhdWwNCj4NCj4NCj4gUGF1bCBXLiBT dG9lY2tlciwgUGguRC4NCj4gU01DIExlYWQgQ29udGVudCBBcmNoaXRlY3QNCj4gUlNBLCBUaGUg U2VjdXJpdHkgRGl2aXNpb24gb2YgRU1DDQo+IGNlbGw6IDMwMi4zNzkuMzM3NSB8IGU6IHBhdWwu c3RvZWNrZXJAcnNhLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9z ZT90bz1wYXVsLnN0b2Vja2VyQHJzYS5jb20+DQo+DQo+DQo+IEZyb206IDxNb3JpYXJ0eT4sIEth dGhsZWVuIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlh aG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+Pg0KPiBEYXRl OiBTdW5kYXksIEZlYnJ1YXJ5IDMsIDIwMTMgNToxMSBQTQ0KPiBUbzogIkhhcnJpbmd0b24sIENo cmlzdG9waGVyIiA8Q2hyaXN0b3BoZXIuSGFycmluZ3RvbkBlbWMuY29tPGh0dHA6Ly91cy5tYzUz NC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPUNocmlzdG9waGVyLkhhcnJpbmd0b25AZW1j LmNvbT4+LCBNSUxFDQo+IElFVEYgPG1pbGVAaWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJlOiBb bWlsZV0gSU9Dcw0KPg0KPiBIaSBDaHJpcywNCj4NCj4gSSBhZ3JlZSwgd2UgaGF2ZSBzb21lIHdv cmsgdG8gZG8gaW4gdGhlIHVwZGF0ZWQgSU9ERUYsIFJGQzUwNzAtYmlzLg0KPg0KPiBUaGUgbGlz dCBoYXMgYWxyZWFkeSBzYWlkIHRoZXkgd291bGQgbGlrZSB0byBzZWUgaW5kaWNhdG9ycyBhZGRl ZCB0bw0KPiB0aGUgZGVmaW5pdGlvbnMgaW4gUkZDNTA3MC1iaXMsIHRvIGJlIG1vcmUgZXhwbGlj aXQgYWJvdXQgaW5jbHVkaW5nDQo+IGluZGljYXRvcnMgYW5kIHNldHMgb2YgaW5kaWNhdG9ycyBp biBJT0RFIGRvY3VtZW50cyBhcyBvcHBvc2VkIHRvDQo+ICdwYXJ0cyBvZiBhbiBpbmNpZGVudCBv ciB0aGUgdXNlZnVsIGluZm9ybWF0aW9uIG9uIGFuIGluY2lkZW50IGZvcg0KPiBzaGFyaW5nIHB1 cnBvc2VzLiAgSXQgd2FzIHdyaXR0ZW4gYmVmb3JlIHdlIHVzZWQgdGVybXMgbGlrZQ0KPiBpbmRp Y2F0b3JzLiAgV2l0aCB0aGF0IGluIG1pbmQsIFJvc2VsbGEgcHJvcG9zZWQgYSBudW1iZXIgb2Yg Y2hhbmdlcw0KPiBiYWNrIGluIEp1bHksIGJvdGggZm9yIGd1aWRhbmNlIGFuZCBmb3INCmZvcm1h dA0KPiB1cGRhdGVzLiAgSXQgbWF5IGhlbHAgdG8gaGF2ZSB0aGUgZmlyc3QgZHJhZnQgdHJ5IHRv IGFkZHJlc3MgYXQgbGVhc3QNCj4gc29tZSBvZiB0aGVzZSBpc3N1ZXMgc28gcGVvcGxlIGNhbiB1 bmRlcnN0YW5kIHRoZSBwcm9ibGVtcyBhbmQgYXQNCj4gbGVhc3QgYSBwcm9wb3NlZCBzb2x1dGlv bi4NCj4NCj4gQXMgeW91IHBvaW50IG91dCwgd2UgbmVlZCB0byBiZSBhYmxlIHRvIHNob3cgcmVs YXRpb25zaGlwcyBiZXR3ZWVuDQo+IHNldHMgb2YgaW5kaWNhdG9ycywgd2hlcmUgd2UgbWF5IGhh dmUgYSBmZXcgc2V0cyBvZiBpbmRpY2F0b3JzIHRoYXQNCj4gY291bGQgaGF2ZSBhIHJlbGF0aW9u c2hpcCB0byBlYWNoIG90aGVyIHdpdGhpbiBhIGRvY3VtZW50LiAgSW4gdGhlDQo+IEp1bHkgcHJl c2VudGF0aW9uLCBvbmUgb2YgdGhlIHF1ZXN0aW9ucyB3YXMgdG8gc2VlIGlmIHdlIHNob3VsZCBh ZGQNCj4gbmV3IGNhdGVnb3J5IGF0dHJpYnV0ZSB2YWx1ZXMgZm9yIHRoZSBTeXN0ZW0gY2xhc3Mg dGhhdCB3b3VsZCBjb25uZWN0DQo+IHRoZSBsaXN0IG9mIGluY2x1ZGVkIGluZGljYXRvcnMuICBJ IHRoaW5rIHdlIHNob3VsZCBzdGlsbCBrZWVwIHRoZQ0KPiBjb25jZXB0IG9mIGEgTm9kZSB0byBh IHNpbmdsZSBub2RlLCBidXQgcGVyaGFwcyB3aXRoaW4gU3lzdGVtLCBsaXN0DQo+IG11bHRpcGxl IHNldHMgb2YgTm9kZXMgdGhhdCBtYXkgYmUgb25lIHR5cGUgb2YgYXR0YWNrLiAgUm9zZWxsYSBo YWQNCj4gc3VnZ2VzdGVkIHB1bGxpbmcgZm9yd2FyZCB0aGUgIkZyYXVkVHlwZSIgZnJvbSBSRkM1 OTAxLCB0aGlzIHdvdWxkDQo+IGhlbHAgc29sdmUgdGhlIGlzc3VlIGFzIE5vZGVSb2xlIHZhbHVl cyB3b3VsZCBjb21wbGltZW50IGFuIEF0dGFja1R5cGUNCj4gKEZyYXVkVHlwZSB2YWx1ZXMgY291 bGQgYmUgaW5jbHVkZWQgaW4gQXR0YWNrVHlwZSBvciBzb21lIGJyb2FkZXINCj4gdGVybSkuICBJ dCBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgdGhlIEZyYXVkVHlwZXMsIHBsdXMgYXR0cmlidXRlIHZh bHVlcw0KPiBsaWtlICJDMi1zZXJ2ZXIiLCAic2lua2hvbGUiLCAgIk1hbHdhcmVEaXN0cmlidXRp b24iIGZvciBhZGRlZCBjb250ZXh0DQo+IHNvIHlvdSBrbm93IHdoYXQgdG8gZG8gd2l0aCB0aGUg cmVjZWl2ZWQgc2V0IG9mIGluZGljYXRvcnMuDQo+DQo+IEkgYW0gcHJvcG9zaW5nIHRoYXQgd2Ug Y2hhbmdlIElPREVGIHRvIGluY2x1ZGUgbXVsdGlwbGUgc2V0cyBvZg0KaW5kaWNhdG9ycywNCj4g YWRkIGFuIEF0dGFja1R5cGUgYXR0cmlidXRlIChvciBzb21lIG90aGVyIG5hbWUpLCBhIG1ldGhv ZCB0byBjb25uZWN0DQo+IGluZGljYXRvcnMgYW5kIGluZGljYXRvciBzZXRzIHdpdGhpbiBhbiBJ T0RFRiB1c2luZyBhbiBhdHRyaWJ1dGUgb2YNCj4gaW5kaWNhdG9yX3VpZCAob3Igc29tZSBvdGhl ciBuYW1lKSB3aXRoIGEgc3RyaW5nIHZhbHVlIHRvIG1ha2UgdGhlDQo+IGNvbm5lY3Rpb24gcG9p bnRzLCBhbmQgYWRkIGEgZmV3IGluZGljYXRvcnMgdGhhdCBhcmUgY29tbW9ubHkgc2hhcmVkDQo+ IGludG8gdGhlIGJhc2UgSU9ERUYuDQo+DQo+IEJhY2sgaW4gSnVseSwgd2UgdGFsa2VkIGFib3V0 IGFkZGluZyBSZWdpc3RyeSBLZXkvVmFsdWUgcGFpcnMgYW5kDQo+IGhhc2hlcyB0byB0aGUgbWFp biBJT0RFRiBkb2N1bWVudCAodHJ5aW5nIHRvIHNlZSBpZiB0aGlzIHdpbGwgaGVscA0KPiBDaHJp cyBiZWxvdykuICBXaGF0IGlmIHdlIGFkZGVkIHRoZSBSZWdpc3RyeSBLZXkvVmFsdWUgcGFpcnMg YXMgYQ0KPiBjbGFzcyBvZmYgb2YgUmVjb3JkRGF0YSwgdXNpbmcgYSBzaW1pbGFyIHN0cnVjdHVy ZSB0byB3aGF0IGlzIGluDQo+IFJGQzU5MDEsIGFuZCBhbHNvIGFkZGVkIHRoZSBhYmlsaXR5IHRv IGluY2x1ZGUgaGFzaGVzIGluIFJlY29yZERhdGE/DQo+IEkgdGhpbmsgaWYgd2UgdGhlbiBoYWQg dGhlIGluZGljYXRvcl91aWQgYXQgdGhlIFJlY29yZERhdGEgbGV2ZWwsIHdlDQo+IGNvdWxkIGNv bm5lY3QgYSBzZXQgd2l0aGluIHRoYXQgc3RydWN0dXJlIGFuZCByZXBlYXQgdGhlIHN0cnVjdHVy ZSBmb3INCj4gb3RoZXIgc2V0cyBpbiB0aGUgc2FtZSB3YXkgd2Ugd291bGQgZG8gd2l0aCBOb2Rl IGluc2lkZSBvZiB0aGUgU3lzdGVtDQo+IGNsYXNzLCB1c2luZyB0aGUgaW5kaWNhdG9yX3VpZCB0 byB0aWUgdGhlIHNldCB0b2dldGhlci4gIFRoZW4gYXQgdGhlDQo+IG1vcmUgc3BlY2lmaWMgbGV2 ZWwgZm9yIHRoZSBoYXNoLCByZWdpc3RyeSBLZXkvdmFsdWUsIElQLCBldGMuIHVzZSBhbg0KPiBp bmRpY2F0b3JfdWlkIGlmIHdlIG5lZWRlZCB0aGVtIG1hcmtlZCBhdCB0aGlzIGxldmVsIGFzIHdl bGw/ICBNYXliZQ0KPiB3ZSB3YW50IGluZGljYXRvcl9zZXQgYXQgdGhlIGhpZ2hlciBsZXZlbD8g IEknZCBsaWtlIHNvbWUgb3BpbmlvbnMgb24NCj4gdGhpcyBhcHByb2FjaC4gICsxIGlmIHlvdSBh Z3JlZSwgc3VnZ2VzdGlvbnMgaWYgeW91IGhhdmUgb3RoZXIgaWRlYXMNCj4gdGhhdCBtYXkgd29y ayBiZXR0ZXIuDQo+DQo+IFdlJ2xsIGFsc28gbmVlZCB0byB3b3JyeSBhYm91dCBtYXJraW5nIHRo ZSBpbmRpY2F0b3JzIHRvIHByZXZlbnQNCj4gZm9yd2FyZCBzaGFyaW5nIHdoZW4gbm90IHBlcm1p dHRlZC4gIFdlIG1heSB3YW50IHRvIHVzZSB0aGVzZSB2YWx1ZXMNCj4gb3Igc29tZXRoaW5nIGVs c2UuDQo+DQo+IFRoYW5rIHlvdSENCj4gS2F0aGxlZW4NCj4NCj4gRnJvbTogSGFycmluZ3Rvbiwg Q2hyaXN0b3BoZXINCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAwMSwgMjAxMyAxMjowMSBQTQ0K PiBUbzogTW9yaWFydHksIEthdGhsZWVuOyBNSUxFIElFVEYNCj4gU3ViamVjdDogUkU6IFttaWxl XSBJT0NzDQo+DQo+IEkgdGhpbmsgd2UgaGF2ZSBhIGJpZ2dlciByZWxhdGlvbnNoaXAgaXNzdWUg dG8gYWRkcmVzcy4gTGV0IHVzZSB0aGUNCj4gV2F0Y2hsaXN0IFVzZSBDYXNlLiBBIGJ1bmNoIG9m IGluZGljYXRvcnMgYXJlIHNlbnQgaW4gb25lIG1lc3NhZ2UuIEluDQo+IHRoYXQgbWVzc2FnZSB3 ZSBjb3VsZCBoYXZlIGdyb3VwaW5ncyBvZiBpbmRpY2F0b3JzIHRoYXQgd2UgbmVlZCB0bw0KPiBz aG93IGFyZQ0KPiByZWxhdGVkOg0KPg0KPiBUd28gb3IgbW9yZSBpbmRpY2F0b3JzIG9mIGRpZmZl cmVudCB0eXBlIHRoYXQgcmVsYXRlIHRvIHRoZSBzYW1lIHRocmVhdDoNCj4gICAgICAgIFRoZSBm aWxlIGhhc2ggb2YgYSBtYWxpY2lvdXMgZmlsZSBhbmQgdGhlIFVSTCBvZiB0aGUgQzIgdGhhdA0K PiB0aGUgZmlsZSB1c2VzLiBFaXRoZXIgb3IgYm90aCBtYXkgYmUgcHJlc2VudCB0byBpbmRpY2F0 ZSBhIGNvbXByb21pc2UuDQo+DQo+IFR3byBvciBtb3JlIGluZGljYXRvcnMgb2YgdGhlIHNhbWUg dHlwZSB0aGF0IHJlbGF0ZSB0byB0aGUgc2FtZSB0aHJlYXQ6DQo+ICAgICAgICAyIGRpZmZlcmVu dCByZWdpc3RyeSB2YWx1ZXMgZm9yIHRoZSBzYW1lIHJlZ2lzdHJ5IGtleS4gSWYNCj4gZWl0aGVy IHZhbHVlIGlzIHByZXNlbnQgaXQgaXMgYSBjb21wcm9taXNlIGluZGljYXRvciBidXQgYm90aCB3 aWxsIG5vdA0KPiBiZQ0KcHJlc2VudC4NCj4NCj4gVGhlIHByb2JsZW0gY29tcG91bmRzIGl0c2Vs ZiB2ZXJ5IHF1aWNrbHkuIENvbnNpZGVyIHRoZSBzY2VuYXJpbyB3aGVyZQ0KPiBib3RoIGdyb3Vw aW5ncyBhYm92ZSBhcmUgcGFydCBvZiB0aGUgc2FtZSB0aHJlYXQuIEkgbmVlZCB0byBzaG93IHRo YXQNCj4gbG9naWNhbCBncm91cGluZ3Mgb2YgSW5kaWNhdG9ycyBhcmUgcmVsYXRlZCBhcyB3ZWxs LiBXZSBjYW4ndCBzZW5kDQo+IG11bHRpcGxlIElPREVGIG1lc3NhZ2VzIGZvciB0aGlzIGZyb20g d2hhdCBJIHJlbWVtYmVyIHJlYWRpbmcuDQo+DQo+IFRoZSBsYXN0IG9uZSBJIGNhbiB0aGluayBv ZiB3b3VsZCBiZSB3aGVuIHlvdSBoYXZlIDIgZGlmZmVyZW50DQo+IGluZGljYXRvcnMgdGhhdCBy ZXByZXNlbnQgdGhlIHNhbWUgaW5kaWNhdG9yLiBJdCdzIG5vdCB1bmNvbW1vbiB0bw0KPiBzZW5k IGJvdGggdGhlDQo+IE1ENQ0KPiBhbmQgU0hBMSBoYXNoIG9mIGEgbWFsaWNpb3VzIGZpbGUuIFRo ZSBpbmRpY2F0b3IgaXMgdGhlIGZpbGUgYnV0IHRoZQ0KPiBJT0NzIGFyZSB0aGUgMiBoYXNoIHZh bHVlcy4gSG93IGRvIHdlIHNob3cgdGhleSBhcmUgcmVsYXRlZD8gSWYgd2UgdXNlDQo+IGEgdW5p cXVlIEluaWRjYXRvciBJRCBmb3IgZWFjaCBoYXNoIHZhbHVlIHRoZXJlIG5lZWRzIHRvIGJlIGEg aGlnaGVyDQo+IGxldmVsDQpncm91cGluZy4NCj4NCj4gVGhvdWdodHM/DQo+DQo+IFRoYW5rcywN Cj4NCj4gLS1DaHJpcw0KPg0KPiBDaHJpc3RvcGhlciBIYXJyaW5ndG9uDQo+IENvbnN1bHRpbmcg U2VjdXJpdHkgRW5naW5lZXINCj4gR1NPIC0gQ3JpdGljYWwgSW5jaWRlbnQgUmVzcG9uc2UgQ2Vu dGVyIEVNQyAtIFdoZXJlIEluZm9ybWF0aW9uIExpdmVzDQo+IDE3NCBNaWRkbGVzZXggVHVybnBp a2UNCj4gQmVkZm9yZCwgTUEgMDE3MzANCj4gNzgxLTUxNS01ODYyICh3b3JrKQ0KPiA2MDMtNTgz LTE1ODUgKGNlbGwpDQo+DQo+IEZyb206IG1pbGUtYm91bmNlc0BpZXRmLm9yZzxodHRwOi8vdXMu bWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9v LmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPiBP ZiBNb3JpYXJ0eSwgS2F0aGxlZW4NCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAwMSwgMjAxMyAx MToyOCBBTQ0KPiBUbzogTUlMRSBJRVRGDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPg0K PiBBbGwgLQ0KPg0KPiBJJ2QgbGlrZSB5b3VyIGlucHV0IGFuZCB3aWxsIHJlZm9jdXMgdGhlIHRo cmVhZCB0byBnZXQgb3BpbmlvbnMgZnJvbQ0KPiB0aGUgbGlzdCBvbiBvcHRpb25zIHRvIGhlbHAg c29sdmUgdGhlIHByb2JsZW1zIHJhaXNlZCBpbiBteSBtZXNzYWdlDQo+IGFuZCBhZGRpdGlvbmFs bHkgaW4gUGF1bCdzIG1lc3NhZ2UuDQo+DQo+IEludGVyZXN0aW5nIHBvaW50LCBDLiBIZW5yeS4g IE91ciBvYmplY3RpdmUgaGVyZSBpcyB0byBoYXZlIG1hY2hpbmUNCj4gYXV0b21hdGVkIGV4Y2hh bmdlcywgc28gd2UgcmVseSBvbiBlbmNyeXB0aW9uIHJhdGhlciB0aGFuIG9iZnVzY2F0aW9uDQo+ IHRvIGFjaGlldmUgdGhlIG5lY2Vzc2FyeSBsZXZlbCBvZiBjb25maWRlbnRpYWxpdHkuDQo+DQo+ IFBhdWwgbWVudGlvbmVkIHRoZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGluZGljYXRvcnMgb2YgY29t cHJvbWlzZSBmcm9tDQo+IGNvbnRleHQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYWxzbyBpbmNsdWRl IElQIGFkZHJlc3Mgb3Igb3RoZXIgZGF0YQ0KPiB0aGF0IGNvdWxkIGJlIGluZGljYXRvcnMuICBU aGUgcXVlc3Rpb24gSSByYWlzZWQgd2FzIG9uIGhvdyB0byBjb25uZWN0DQo+IHNldHMgb2YgaW5k aWNhdG9ycyBpbiB0aGUgc2FtZSBJT0RFRiBkb2N1bWVudCwgYXNzdW1pbmcgdGhlIGFiaWxpdHkg dG8NCj4gaGF2ZSB3YXRjaGxpc3RzIHRoYXQgY291bGQgaGF2ZSBzZXZlcmFsIHNldHMgb2YgaW5k aWNhdG9ycyBpbmNsdWRlZCwNCj4gYXMgd2VsbCBhcyB0byBjb25uZWN0IGluZGljYXRvcnMgdGhh dCBtYXkgYmUgaW5jbHVkZWQgaW4gZW1iZWRkZWQNCj4gc2NoZW1hcy4NCj4NCj4gSWYgd2UgYWRk IGFuIGF0dHJpYnV0ZSBvbiBhbGwgb2YgdGhlIHJlbGV2YW50IGluZGljYXRvcnMsIGxldCdzIHNh eQ0KPiAnaW5kaWNhdG9yLXVpZCcgaG93IGRvIHdlIG1hcmsgdGhlIGluZGljYXRvcnM/ICBEbyB3 ZSB1c2UgdGhpcyB0byBtYXJrDQo+IHdobyBzZW50IHRoZSBpbmRpY2F0b3IgYXMgd2VsbCBzbyB0 aGF0IHdlIGNhbiBwcmV2ZW50IGZvcndhcmQgc2hhcmluZw0KPiB3aGVuIGl0IGlzIG5vdCBwZXJt aXR0ZWQgb3IgaGFuZGxlIHRoYXQgc2VwYXJhdGVseT8NCj4NCj4gVGhlbiBmb3IgaW5kaWNhdG9y cyBub3QgaW5jbHVkZWQgaW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IG5vdCBmaXQNCj4gaW50 byBhIGNhdGVnb3J5IGluIHRoZSBTQ0kgZHJhZnQsIGRvIHdlIGNyZWF0ZSBhIHBsYWNlIGZvciB0 aGVzZSBvZmYNCj4gb2YgU0NJIG9yIHJpZ2h0IG9mZiBvZiB0aGUgSU9ERSBzY2hlbWEgaW4gRXZl bnREYXRhPyAobW9yZSBkZXRhaWxzIG9uDQo+IHRoaXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuDQo+ DQo+IENvbW1lbnRzIGFuZCBxdWVzdGlvbnMgZW5jb3VyYWdlZCB0byBmaWd1cmUgb3V0IHRoZSBy aWdodCB0ZWNobmljYWwNCj4gc29sdXRpb24gdG8gaGF2ZSB0aGlzIG1hY2hpbmUgYXV0b21hdGFi bGUuDQo+DQo+IFRoYW5rIHlvdSwNCj4gS2F0aGxlZW4NCj4NCj4gRnJvbTogbWlsZS1ib3VuY2Vz QGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1p bGUtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmc8aHR0cDov L3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZS1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmDQo+IE9mIEMuDQo+IEhlbnJ5IEFkYW1zICYgQklFDQo+IFNlbnQ6IE1v bmRheSwgSmFudWFyeSAyOCwgMjAxMyAxMToyNSBQTQ0KPiBUbzogTUlMRSBJRVRGDQo+IFN1Ympl Y3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPg0KPiBUZW1wb3JhbCBEZXBlbmRlbmN5IHNvdW5kcyBpbnRl cmVzdGluZy4gIEkgcmVtZW1iZXIgd2hlbiBJIGZpcnN0IHJhbg0KPiBhY3Jvc3MgdGhpcyBwYXJ0 aWN1bGFyIGNyYWZ0LCBhbiBleHBlcmllbmNlZCBjb2xsZWFndWUgYXNrZWQgbWUgYQ0KPiBwZWN1 bGlhciBxdWVzdGlvbi4gIEhlIHNhaWQsICIgSG93IGRvIHlvdSBzdG9wIHNvbWVvbmUgZnJvbSB0 cmFja2luZw0KPiB0aGUgSVAgQWRkcmVzcyB0byB5b3VyIGNvbXB1dGVyPyINCj4NCj4gSSByZXBs aWVkLCAiSSBkb24ndCBrbm93LCBob3c/Ig0KPg0KPiBUaGVuIGhlIHNhaWQsICJDdXQgdGhlIGRv Zy1nb25lIHRoaW5nIG9mZiAgYW5kIHRoZSBtb2RlbSB0aGF0IGl0IGlzDQo+IGNvbm5lY3RlZC0g d2hpY2ggaXMgY29uc3RhbnRseSBvbiEiICAgTE9MDQo+DQo+IEhlcmUncyBteSBwb2ludCAoSHlw b3RoZXRpY2FsIFNpdHVhdGlvbikgOiAgVGhlcmUgaXMgYSAxc3QgUmVzcG9uZGVyDQo+IHNlYXJj aGluZyBhIE5laWdoYm9yaG9vZCBmb3IgU3Vydml2b3JzIHdoaWNoIHdlcmUgaGl0IGJ5IGEgRGlz YXN0ZXIgb3INCj4gbGV0J3MganVzdCBzYXkgIkxpdmUiIFRlcnJvcmlzdCBTaXR1YXRpb24uICBI ZSAvb3IgU2hlIG5lZWRzIHRvDQo+IGNvbW11bmljYXRpb24gYmFjayB0byBvdGhlciBPZmZpY2lh bHMgdGhhdCBoZSAvb3Igc29tZWhvdyBpcyBpbg0KPiBEYW5nZXIuICBUaGUgZGV2aWNlIHVzZWQg dG8gY29tbXVuaWNhdGUgaGFzIGJlZW4gY2FwdHVyZWQgYnkgdGhlIGdyZWF0DQo+IG1pbmRzIG9m IHRoZSBlbmVteS4gIEl0J3Mgb25seSBhIG1hdHRlciBvZiB0aW1lIGJlZm9yZSB0aGV5IHV0aWxp emUNCj4gcmV2ZXJzZSBlbmdpbmVlcmluZyB0byBmaWd1cmUgb3V0IGhvdyBpdCBmdW5jdGlvbnMu ICBIb3dldmVyLCB0aGVpcg0KPiBwcmlkZSBjb21lcyBiZWZvcmUgYSBmYWxsIHdoZW4gc2Vla2lu ZyB0aGUgbG9jYXRpb24gb2Ygb3RoZXIgc2ltaWxhcg0KPiBkZXZpY2VzIHRvIGF0dGFjay4gIFdo eT8gUGVyaGFwcyB0aGUgbGVzcyB0aG91Z2h0IG9mIGNvbmNlcHRzIHRoYXQNCj4gbWFrZXMgdGhl IGRldmljZSBmdW5jdGlvbiBwcm9wZXJseSwgc2F2ZXMgdGhlIGRheSBieSBkaXNndWlzZSBvcg0K PiBjdXR0aW5nIGl0IG9mZiAoZmlndXJhdGl2ZWx5IHNwZWFraW5nKS4NCj4NCj4gSnVzdCBhIHZp c2lvbmFyeSB0aG91Z2h0Lg0KPg0KPiBDLiBIZW5yeSBBZGFtcw0KPiBjaGVucnlhZGFtc0BiaWVt ZWRpYWdyb3VwLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90 bz1jaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbT4NCj4gaHR0cDovL2JpZW1lZGlhZ3JvdXAu Y29tDQo+DQo+DQo+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUNCj4gb3JpZ2luYWwgcmVjaXBpZW50LiBUaGlzIGluZm9ybWF0 aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQNCj4gZGlzdHJpYnV0aW9uIHdpdGhpbiB0aGUgcmVj aXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nDQo+IHB1cnBvc2VzIG9ubHku IEZ1cnRoZXIgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBwcml2YXRlIG9yIHB1YmxpYyBpcw0KPiBw cm9oaWJpdGVkLg0KPg0KPiAtLS0gT24gTW9uLCAxLzI4LzEzLCBEYXZlIE1pc2VsbCA8ZGF2aWQu bWlzZWxsQGJjcy5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89ZGF2aWQubWlzZWxsQGJjcy5vcmc+PiB3cm90ZToNCj4NCj4gRnJvbTogRGF2ZSBNaXNlbGwg PGRhdmlkLm1pc2VsbEBiY3Mub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9j b21wb3NlP3RvPWRhdmlkLm1pc2VsbEBiY3Mub3JnPj4NCj4gU3ViamVjdDogUmU6IFttaWxlXSBJ T0NzDQo+IFRvOiAiQy4gSGVucnkgQWRhbXMgJiBCSUUiIDxjaGF0bGdhMjAwMEB5YWhvby5jb208 aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBA eWFob28uY29tPj4NCj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzLCA5OjI1IFBNIFVJ RCBjb3VsZCBiZSBtaXJyb3JlZCB3aXRoIEROUw0KPiBTRUMgYSBwZW1hbmVudCBhbmQgdGVtcG9y YWwga2V5LCB3aXRoIGEgdGVtcG9yYWwgSWQ/DQo+DQo+IFlvdXJzIEZhaXRoZnVsbHksDQo+DQo+ IERhdmUgTWlzZWxsIE1TYyBDSVNTUA0KPiBTaWxlbnRDaXJjbGUgIGRzbQ0KPiAwNzcxMCAzODAw NDQNCj4gZGF2aWQubWlzZWxsQGJjcy5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89ZGF2aWQubWlzZWxsQGJjcy5vcmc+DQo+DQo+DQo+IE9uIDI5IEphbiAy MDEzLCBhdCAwMDozOSwgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlhaG9vLmNv bTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAw MEB5YWhvby5jb20+Pg0KPiB3cm90ZToNCj4NCj4gPiBTZXJpYWxpemF0aW9uIG9mIGEgcGFydGlj dWxhciBMaXN0cyBvZiBYTUwgQ2xhc3NlcyBpbiBhIHVuaXF1ZSB3YXkNCj4gPiB3YXMNCj4gY2xv c2VseSByZWxhdGVkIHRvIHdoYXQgSSBhdHRlbXB0ZWQgdG8gZXhwcmVzcyB3aGVuIEkgc3RhdGVk LA0KPiAiY29uc2lkZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBlYXJzIHRvIGJlIGlsbG9naWNhbCBp biBicmlsbGlhbnQgbWluZHMNCj4gaW4gc29tZSBpbnN0YW5jZXMuIg0KPiA+DQo+ID4gSG93ZXZl ciwgSSBzZWUgRHIuIFN0b2Vja2VyJ3MgcG9pbnQgYSBsaXR0bGUgY2xlYXJlci4gIEhvd2V2ZXIs IGl0DQo+ID4gd291bGQNCj4gYmUgbmljZSBpZiB0aGUgVUlEIHdhcyBpbiBzb21lIHdheSBkaXNn dWlzZWQgZnJvbSB0aG9zZSB3aG8gc3R1ZHkgdGhpcw0KPiBTZWN1cml0eSBBcnQgRm9ybSBpbiBh IG5lZ2F0aXZlIHdheS4NCj4gPg0KPiA+IEMuIEhlbnJ5IEFkYW1zDQo+ID4gY2hhdGxnYTIwMDBA eWFob28uY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNo YXRsZ2EyMDAwQHlhaG9vLmNvbT4gKERpcmVjdCBFbWFpbCkgY2hlbnJ5YWRhbXNAYmllbWVkaWFn cm91cC5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hl bnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20+DQo+ID4NCj4gPg0KPiA+IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUNCj4gPiBv cmlnaW5hbA0KPiByZWNpcGllbnQuIFRoaXMgaW5mb3JtYXRpb24gaXMgZ3JhbnRlZCBmb3IgbGlt aXRlZCBkaXN0cmlidXRpb24gd2l0aGluDQo+IHRoZQ0KPiByZWNpcGllbnQncyBwbGFjZSBvZiBi dXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlcg0KPiBkaXNzZW1pbmF0 aW9uLCB3aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuDQo+ID4NCj4gPiBS ZTogW21pbGVdIElPQ3MNCj4gPg0KPiA+IFN1bmRheSwgSmFudWFyeSAyNywgMjAxMyA4OjUyIFBN DQo+ID4gRnJvbToNCj4gPiAiU3RvZWNrZXIsIFBhdWwiIDxQYXVsLlN0b2Vja2VyQHJzYS5jb208 aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89UGF1bC5TdG9lY2tl ckByc2EuY29tPj4NCj4gPiBUbzoNCj4gPiAibWlsZUBpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnPiIgPG1pbGVAaWV0Zi5v cmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRm Lm9yZz4+DQo+ID4gSSB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgdGhpcyBmcm9tIGEgc2xpZ2h0bHkg ZGlmZmVyZW50DQo+ID4gcGVyc3BlY3RpdmXFoGxldCdzIHNheSBJIGdldCBhbiBYTUwgZG9jdW1l bnQgdGhhdCB0ZWxscyBtZSBhYm91dCBhbg0KPiA+IGluY2lkZW50LiAgVGhpcyBkb2N1bWVudCBo YXMgc291cmNlIElQIGFuZCBkZXN0aW5hdGlvbiBJUCB0aGF0IGlzDQo+ID4gYmVpbmcgc2hhcmVk LiAgSG93ZXZlciwgd2hhdCBJIGRvbid0IGtub3cgaXMgd2hpY2ggSVAgYWRkcmVzcyBpcyBteQ0K PiA+IGluZGljYXRvciBhbmQgd2hpY2ggaXMganVzdCBhIGNvbnRleHR1YWwgcGllY2Ugb2YgaW5m b3JtYXRpb24uICBUaGlzDQo+ID4gbWVhbnMgdGhhdCBteSBkZXRlY3Rpb24gcHJvZHVjdCBpc24n dCBnb2luZyB0byBrbm93IHdoaWNoIG9uZSB0byB1c2UNCj4gPiBlaXRoZXIsIGJlY2F1c2UgdGhl cmUgaXMgbm90aGluZyB0byB0ZWxsIG1lIHdoaWNoIElQIGlzIHRoZSBvbmUsIGV2ZW4NCj4gPiBp ZiB0aGUgcm9sZXMgYXJlIHNldCBpdCBzdGlsbCBtaWdodCBub3QgYmUgZW5vdWdoIHRvIHRlbGwg bXkgc3lzdGVtDQo+IHdoaWNoDQo+IG9uZSBJIHNob3VsZCB1c2UgYXMgdGhlIGluZGljYXRvci4N Cj4gPg0KPiA+IElmIHdlIGhhZCBzb21ldGhpbmcgbGlrZSBpbmRpY2F0b3JfaWQgYXMgYW4gYXR0 cmlidXRlLCBpdCB3b3VsZCBhbGxvdw0KPiA+IHVzIHRvIGVhc2lseSBpZGVudGlmeSBpbmRpY2F0 b3JzIGZyb20gY29udGV4dHVhbCBkYXRhLiAgSSBkbyBhZG1pdCB0bw0KPiA+IGJlaW5nIGJpYXNl ZCBhcyBJIGhhdmUgc3BlbnQgbXVjaCBvZiBteSBjYXJlZXIgd29ya2luZyBvbiB0aGUNCj4gPiBt b25pdG9yaW5nIGFuZCBkZXRlY3Rpb24gc2lkZSBvZiB0aGVzZSB0aGluZ3MsIHNvIEkgYW0ganVz dCB0aGlua2luZw0KPiA+IG9mIHdheXMgdG8gbWFrZSBpdCB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGlu ZGljYXRvcnMgYXJlIGluIHRoZSBYTUwNCj4gPiBkb2N1bWVudCBhbmQgdGhlIG90aGVyIGRhdGEg dGhhdCBtYXkgYmUgaW1wb3J0YW50IGFzIEkgaW52ZXN0aWdhdGUNCj4gPiBhY3Rpdml0eSB0aGF0 IEkgaGF2ZSBkZXRlY3RlZCBvZmYgb2YgdGhvc2UgaW5kaWNhdG9ycy4NCj4gPg0KPiA+DQo+ID4g SSBkaWQgc3VnZ2VzdCB0aGUgZGV0ZWN0aW9uIGNsYXNzLCBidXQgSSB0aGluayB3ZSBtYXkgZ2V0 IG1vcmUNCj4gPiBmbGV4aWJpbGl0eSB3aXRoIHRoZSBpbmRpY2F0b3JfdWlkLiAgT25lIHRoaW5n IHRoYXQgSSBoYXZlbid0DQo+ID4gY29uc2lkZXJlZCBpcyB0aGUgVUlEIHBvcnRpb24gb2YgdGhp c8WgaG93IGRvIHdlIHVzZSB0aGF0IFVJRD8gIEhvdyBpcw0KPiA+IHRoZSBVSUQgY3JlYXRlZD8g IEFyZSB0aGVyZSBzdGFuZGFyZHMgZm9yIFVJRHM/DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ ID4gUGF1bA0KPiA+DQo+ID4NCj4gPg0KPiA+IFBhdWwgVy4gU3RvZWNrZXIsIFBoLkQuDQo+ID4g U01DIExlYWQgQ29udGVudCBBcmNoaXRlY3QNCj4gPiBSU0EsIFRoZSBTZWN1cml0eSBEaXZpc2lv biBvZiBFTUMNCj4gPiBjZWxsOiAzMDIuMzc5LjMzNzUgfCBlOiBwYXVsLnN0b2Vja2VyQHJzYS5j b208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89cGF1bC5zdG9l Y2tlckByc2EuY29tPg0KPiA+DQo+ID4gLS0tIE9uIFNhdCwgMS8yNi8xMywgQy4gSGVucnkgQWRh bXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhv by5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+PiB3cm90ZToNCj4gPg0K PiA+IEZyb206IEMuIEhlbnJ5IEFkYW1zICYgQklFIDxjaGF0bGdhMjAwMEB5YWhvby5jb208aHR0 cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFo b28uY29tPj4NCj4gPiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4gPiBUbzogIkthdGhsZWVu TW9yaWFydHkiIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPGh0dHA6Ly91cy5tYzUzNC5tYWls LnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+Pg0KPiA+ IENjOiBtaWxlQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21w b3NlP3RvPW1pbGVAaWV0Zi5vcmc+DQo+ID4gRGF0ZTogU2F0dXJkYXksIEphbnVhcnkgMjYsIDIw MTMsIDY6MTcgUE0NCj4gPg0KPiA+IEdyZWV0aW5ncyBLYXRobGVlbiwNCj4gPg0KPiA+IFlvdXIg bG9naWMgc3RpbXVsYXRlcyBteSB2aXNpb25hcnkgYnJhaW4gYmVjYXVzZSBJJ20gYW1hemVkIGF0 IHRoZQ0KPiA+IG1hbnkNCj4gYXZlbnVlcyB5b3UgcmV2aWV3IHdpdGggdGhpcyBhcHByb2FjaCBh dCBvbmNlLiAgSG93ZXZlciwgIGNvdWxkIHlvdSBzaGFyZQ0KPiBhDQo+IGZldyBhZHZhbnRhZ2Vz IGFuZCBkaXNhZHZhbnRhZ2VzIHRvIHRoZSBsYXR0ZXI/DQo+ID4NCj4gPg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiAtLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gIndlIGNvdWxkIGNvbnRpbnVlIHRvIGdyb3VwIGl0ZW1zIGluIGxvZ2ljYWwg cGxhY2VzIGFzIGlzIGRvbmUgbm93IGluDQo+IElPREVGIGFuZCB0aGVuIGhhdmUgdGhlIGV4dGVu c2lvbiBwb2ludCBmb3IgY29tYmluZWQgaW5kaWNhdG9ycyB2aWEgU0NJLiINCj4gPg0KPiA+DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gWW91IHBvaW50ZWQgb3V0IHdoYXQgeW91IGNvbnNp ZGVyIHRvIGJlIGxvZ2ljYWwgcGxhY2VzLCBidXQgaWYgSQ0KPiA+IHdhbnRlZCB0bw0KPiBwcm90 ZWN0IGluZm9ybWF0aW9uIGZyb20gcGFydGllcyBjYXBhYmxlIG9mIGFzY2VydGFpbmluZyBpdCBm cm9tIHlvdXINCj4gbG9naWNhbCBwbGFjZXMsIHBlcmhhcHMgd2Ugc2hvdWxkIGFsc28gY29uc2lk ZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBlYXJzDQo+IHRvDQo+IGJlIGlsbG9naWNhbCBpbiBicmls bGlhbnQgbWluZHMgaW4gc29tZSBpbnN0YW5jZXMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gQy4gSGVu cnkgQWRhbXMNCj4gPiBjaGF0bGdhMjAwMEB5YWhvby5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tPiAoRGlyZWN0IEVt YWlsKQ0KPiA+IGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPGh0dHA6Ly91cy5tYzUzNC5t YWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29t Pg0KPiA+DQo+ID4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiA+IG9yaWdpbmFsDQo+IHJlY2lwaWVudC4gVGhpcyBpbmZv cm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW4NCj4gdGhl DQo+IHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBv bmx5LiBGdXJ0aGVyDQo+IGRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMg aXMgcHJvaGliaXRlZC4NCj4gPg0KPiA+IC0tLSBPbiBTYXQsIDEvMjYvMTMsIE1vcmlhcnR5LCBL YXRobGVlbiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55 YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPj4NCj4gd3Jv dGU6DQo+ID4NCj4gPiBGcm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4gPGthdGhsZWVuLm1vcmlhcnR5 QGVtYy5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89a2F0 aGxlZW4ubW9yaWFydHlAZW1jLmNvbT4+DQo+ID4gU3ViamVjdDogUkU6IFttaWxlXSBJT0NzDQo+ ID4gVG86ICJDLiBIZW5yeSBBZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRw Oi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhv by5jb20+PiwgIm1pbGVAaWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4iDQo+IDxtaWxlQGlldGYub3JnPGh0dHA6Ly91cy5t YzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+Pg0KPiA+IERh dGU6IFNhdHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzLCAxMDoxMyBBTQ0KPiA+DQo+ID4gSGVsbG8g Qy4gSGVucnkgJiBvdGhlcnMsDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRha2luZyBhIGxvb2sgYXQg dGhpcy4gIFdlIGhhdmUgYSBmZXcgY29uc2lkZXJhdGlvbnMgaW4NCj4gPiB0aGlzDQo+IGVtYWls IHRocmVhZCBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aG91Z2h0cyBvbiAoYW5kIHRoZXJlIG1heSBi ZSBtb3JlIG9uY2UNCj4gUkZDNTA3MC1iaXMgaXMgYWN0aXZlbHkgZWRpdGVkKS4NCj4gPg0KPiA+ IFRoZSBBZGRpdGlvbmFsRGF0YSBjbGFzcyBhbmQgdGhlIFJlY29yZEl0ZW0gY2xhc3MgYm90aCBh bGxvdyBmb3INCj4gPiBub24tWE1MDQo+IGV4dGVuc2lvbnMuICBXaGVyZSB5b3UgcGxhY2UgdGhl IGV4dGVuc2lvbnMgc2hvdWxkIGJlIHNwZWNpZmljIHRvIHRoZQ0KPiBsb2dpY2FsIGdyb3VwaW5n IG9mIHRoZSBwYXJlbnQgZWxlbWVudHMgc28geW91IGNhbiB1bmRlcnN0YW5kIG1vcmUgYWJvdXQN Cj4gdGhlDQo+IGluY2x1ZGVkIGRhdGEgaW4gbW9zdCBjYXNlcy4NCj4gPg0KPiA+IFRoZSBJbXBh Y3QgY2xhc3MgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBjb250ZXh0IGluZm9ybWF0aW9uIG9uIHRo ZQ0KPiBpbmNsdWRlZCBkYXRhIG9mIHRoZSByZXBvcnQgYW5kIGFsc28gY2FuIGluY2x1ZGUgYSBj b25maWRlbmNlIHJhdGluZyBvbg0KPiB0aGUNCj4gcmVwb3J0IGFzIGEgd2hvbGUuICBFeHRlbnNp b25zIHJlbGF0ZWQgdG8gaW1wYWN0IHdvdWxkIGJlIG9uZSBsZXZlbCBoaWdoZXINCj4gKGF0IHRo ZSBtb21lbnQpIGluIHRoZSBBc3Nlc3NtZW50IGNsYXNzIHVzaW5nIHRoZSBBZGRpdGlvbmFsRGF0 YSBleHRlbnNpb24NCj4gcG9pbnQuDQo+ID4NCj4gPiBUYWtlIGFza2VkIGFib3V0IGluY2x1ZGlu ZyB2dWxuZXJhYmlsaXR5IGluZm9ybWF0aW9uLCBJIHdvdWxkIHRoaW5rDQo+ID4gdGhhdA0KPiB3 b3VsZCBmaXQgdW5kZXIgdGhlIFZ1bG5lcmFiaWxpdHkgZXh0ZW5zaW9uIHBvaW50IG9mIHRoZSBT Q0kgZHJhZnQgaW4NCj4gdGhlDQo+IE1ldGhvZCBjbGFzcy4gIEhlIGRpZCBhc2sgYWJvdXQgbm9u LVhNTC4gIFJlY29yZEl0ZW0gb3IgQWRkaXRpb25hbERhdGENCj4gZG8NCj4gYWxsb3cgZm9yIG5v bi1YTUwgZXh0ZW5zaW9uIHBvaW50cywgd2UgY291bGQgZWl0aGVyIGhhdmUgdGhlIFNDSSBkcmFm dA0KPiBoYW5kbGUgdGhlc2UgYXMgd2VsbCBvciBoYXZlIHRoZSBleHRlbnNpb25zIHRoYXQgYXJl IG5vbi1YTUwgY29tZSBkaXJlY3RseQ0KPiBvZmYgdGhlIEFkZGl0aW9uYWxEYXRhIG9yIFJlY29y ZEl0ZW0gY2xhc3NlcyBhY2NvcmRpbmcgdG8gd2hhdCBtYWtlcyBzZW5zZQ0KPiBmcm9tIGEgbG9n aWNhbCBzdGFuZHBvaW50Lg0KPiA+DQo+ID4gQXMgZm9yIG15IHF1ZXN0aW9uLCBpdCB3YXMgdHdv LWZvbGQuDQo+ID4NCj4gPiBJbmRpY2F0b3IgYmFzZWQgc2NoZW1hcyBoYXZlIGEgcmVmZXJlbmNl IG51bWJlciBvciBhIEdVSUQgZm9yIHRoZQ0KPiA+IHZhcmlvdXMNCj4gaW5kaWNhdG9ycyB0aGV5 IHNoYXJlLiAgSWYgd2UgYXJlIGV4dGVuZGluZyB0byBlbWJlZCBvdGhlciBzY2hlbWFzIHRoYXQN Cj4gaW5jbHVkZSBzdWNoIHJlZmVyZW5jZSBvciBHVUlEIGlkZW50aWZpZXJzLCBkbyB3ZSB3YW50 IHRvIGFkZCBhbiBhdHRyaWJ1dGUNCj4gdG8gdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gSU9ERUYg dGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzPyAgSXMgdGhpcyBlbm91Z2gNCj4gdG8gbWFrZSB0aGUg Y29ubmVjdGlvbnMgb3IgaXMgc29tZXRoaW5nIGVsc2UgZWxzZSBuZWVkZWQ/ICBXZSBjb3VsZCBh ZGQNCj4gc29tZXRoaW5nIGxpa2UgYW4gSW5kaWNhdG9yX0lEIGluIFJGQzUwNzAtYmlzIHdoaWNo IHdvdWxkIHRoZW4gY29ycmVsYXRlDQo+IHRvDQo+IHRoZSByZWZlcmVuY2Ugb3IgR1VJRCBpZGVu dGlmaWVycy4NCj4gPg0KPiA+IFRoZW4gdGhlIG90aGVyIHF1ZXN0aW9uIHdhcyBvbiBob3cgdG8g aW5jbHVkZSBpbmRpY2F0b3JzIHRoYXQgYXJlIG5vdA0KPiA+IGluDQo+IHRoZSBiYXNlIHNjaGVt YSB0aGF0IG1heSBiZSByZWxhdGVkIG9yIGhhdmUgbGFuZ3VhZ2Ugd2l0aCAiYW5kIiAib3IiIHRv DQo+IHNwZWNpZnkgdGhlIHJlbGF0aW9uc2hpcHMuICBJbiBzb21lIGNhc2VzLCB5b3Ugd2lsbCB3 YW50IHRvIGdyb3VwIHRoZXNlDQo+IGluZGljdG9ycyBpbiBvbmUgZXh0ZW5zaW9uIHBvaW50LCB3 aGVyZSB0aGV5IG1heSBmaXQgbG9naWNhbGx5IGluIG11bHRpcGxlDQo+IHBsYWNlcyBpZiB0aGUg cmVsYXRpb25zaGlwcyBkaWQgbm90IG5lZWQgdG8gYmUgc2hvd24gaW4gdGhlIGRhdGENCj4gZm9y bWF0LiAgSWYNCj4gd2UgaGF2ZSBjYXNlcyBsaWtlIHRoaXMgd2hlcmUgeW91IG5lZWQgbW9yZSBj b21wbGV4IHJlcHJlc2VudGF0aW9ucywNCj4gc2hvdWxkDQo+IHdlIHVzZSBvbmUgZXh0ZW5zaW9u IHBvaW50IHZpYSB0aGUgU0NJIGRyYWZ0IG9mZiBvZiB0aGUgRXZlbnREYXRhIGNsYXNzDQo+IEFk ZGl0aW9uYWxEYXRhIGV4dGVuc2lvbiBwb2ludD8gIE9waW5pb25zIGFyZSBuZWVkZWQgaGVyZS4u Li4NCj4gPg0KPiA+IEEgZmV3IHBlb3BsZSBoYXZlIG1lbnRpb25lZCB3YW50aW5nIHRvIGluY2x1 ZGUgc29tZSBjb21tb25seSBzaGFyZWQNCj4gaW5kaWN0b3JzIGludG8gdGhlIGJhc2UgSU9ERUYg ZG9jdW1lbnQuICBXZSBjb3VsZCBoYXZlIGEgY2F0Y2gtYWxsIGNsYXNzDQo+IHRoYXQgZG9lcyB0 aGlzIGFuZCBoYXMgYW4gZXh0ZW5zaW9uIHBvaW50IG9mZiBvZiBpdCBpbiBFdmVudERhdGEgb3Ig d2UNCj4gY291bGQNCj4gY29udGludWUgdG8gZ3JvdXAgaXRlbXMgaW4gbG9naWNhbCBwbGFjZXMg YXMgaXMgZG9uZSBub3cgaW4gSU9ERUYgYW5kDQo+IHRoZW4NCj4gaGF2ZSB0aGUgZXh0ZW5zaW9u IHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZpYSBTQ0kuICBJIHRoaW5rIEkgbGlrZQ0K PiB0aGUgbGF0dGVyIGFwcHJvYWNoLg0KPiA+DQo+ID4gVGhhbmsgeW91LA0KPiA+IEthdGhsZWVu DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206 IG1pbGUtYm91bmNlc0BpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMv Y29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmc+IFttaWxlLWJvdW5jZXNAaWV0Zi5vcmc8 aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZS1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEMuDQo+ID4gSGVucnkNCj4gQWRhbXMgJiBCSUUgW2No YXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29t cG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+XQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBKYW51 YXJ5IDI2LCAyMDEzIDM6MDUgQU0NCj4gPiBUbzogbWlsZUBpZXRmLm9yZzxodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnPg0KPiA+IENjOiBD LiBIZW5yeSBBZGFtcw0KPiA+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPiA+DQo+ID4gR3Jl ZXRpbmdzIEV2ZXJ5b25lLA0KPiA+DQo+ID4gVGFrZSBtZW50aW9uZWQgdHdvIHR5cGVzIG9mIGlu ZGljYXRvcnMgYmFzZWQgb24gdGhlIDoNCj4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IDEpIElmIHRoZSBpbmRpY2F0b3JzIGFy ZSBzb21ldGhpbmcgbGlrZSBhbiBYTUwtYmFzZWQgYWxlcnQvd2FybmluZyBvZg0KPiA+IGluZm9y bWF0aW9uIGxlYWthZ2UsIGl0IGNvdWxkIGJlIGFuIGV2ZW50IHRoYXQgYXJlIGNvbnZleWVkIGlu IHRoZQ0KPiA+IFNDSSdzIEV2ZW50UmVwb3J0IGNsYXNzLCBJTUhPLg0KPiA+DQo+ID4gMikgSWYg dGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGluZyBsaWtlIGFuIG5vbi1YTUwgb25lcywgSSBndWVz cyBpdA0KPiA+IGNvdWxkDQo+IGJlDQo+ID4gY29udmV5ZWQgd2l0aG91dCB1c2luZyBTQ0kgZHJh ZnQuDQo+ID4gRm9yIGluc3RhbmNlLCB3ZSBjb3VsZCB1c2UgSW1wYWN0IGNsYXNzIG9mIHRoZSBi YXNlIElPREVGIHRvIGNvbnZleQ0KPiA+IHRoZSBpbmRpY2F0b3JzLg0KPiA+IFdlIGNvdWxkIGZv ciBpbnN0YW5jZSBleHRlbmQgdGhlIGxpc3Qgb2YgaW5kaWNhdG9ycyBvZiB0aGUgSW1wYWN0DQo+ ID4gY2xhc3MsDQo+IGlmDQo+ID4gbmVlZGVkLg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0t LS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBJbiBkb2luZyBzbyBo ZSBwb2ludGVkIG91dCB0aGUgIkltcGFjdCBDbGFzcyINCj4gPg0KPiA+IFdoZXJlYXMsIEthdGhs ZWVuIHN0YXRlZCwNCj4gPg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBGb3IgdGhlIGRpc2N1c3Npb24gYmVsb3csIEkgd2Fz IHRoaW5raW5nIG1vcmUgb2YgY29tYmluZWQgc2V0IHdpdGgNCj4gcmVsYXRpb25zaGlwcyB0aGF0 IG1heSBiZSBpbmNsdWRlZCBpbiBhIHNpbmdsZSBleHRlbnNpb24gcG9pbnQsIHNvIHRoYXQncw0K PiB3aHkgSSB3YXMgdGhpbmtpbmcgYWJvdXQgdGhlIEV2ZW50RGF0YSBjbGFzcywgYnV0IHRoZXJl IG1heSBiZSBiZXR0ZXINCj4gbG9jYXRpb25zIG9yIGEgc3BlY2lmaWMgYXJlYSB3aXRoaW4gdGhl IEV2ZW50RGF0YS4NCj4gPg0KPiA+IFBhdWwgU3RvZWNrZXIgaGFkIHN1Z2dlc3RlZCBhICJEZXRl Y3Rpb24iIGNsYXNzIGFzIGEgY29uc2lkZXJhdGlvbi4NCj4gPg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAt LS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IEthdGhsZWVuIHRo b3VnaHRzIHJlbGF0ZWQgeWV0IHN0aWxsIHdpdGggb3RoZXIgaW5kaWNhdG9ycyBhbmQgdGhlDQo+ IEV2ZW50RGF0YSBDbGFzcy4NCj4gPg0KPiA+IElzIHRoZXJlIGEgcG9zc2libGUgd2F5IHRvIGNy ZWF0ZSBhIG5ldyBYTUwgY2xhc3Mgd2hpY2ggZW5jb21wYXNzDQo+IGNvbWJpbmluZyB0aGUgRXZl bnREYXRhLCBEZXRlY3Rpb24gYW5kIGJhc2UgSU9ERUYgY2xhc3NlcyB0byBzaW1wbGlmeQ0KPiB0 aGlzDQo+IGlzc3VlPw0KPiA+DQo+ID4NCj4gPiBDLiBIZW5yeSBBZGFtcw0KPiA+IGNoYXRsZ2Ey MDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90 bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+IChEaXJlY3QgRW1haWwpDQo+ID4gY2hlbnJ5YWRhbXNA YmllbWVkaWFncm91cC5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBv c2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20+DQo+ID4NCj4gPg0KPiA+IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUNCj4gPiBvcmlnaW5hbA0KPiByZWNpcGllbnQuIFRoaXMgaW5mb3JtYXRpb24gaXMgZ3JhbnRl ZCBmb3IgbGltaXRlZCBkaXN0cmlidXRpb24gd2l0aGluDQo+IHRoZQ0KPiByZWNpcGllbnQncyBw bGFjZSBvZiBidXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlcg0KPiBk aXNzZW1pbmF0aW9uLCB3aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuDQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBt aWxlIG1haWxpbmcgbGlzdA0KPiA+IG1pbGVAaWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCj4NCj4NCg0KDQo= --_000_F5063677821E3B4F81ACFB7905573F24CEBDF152MX15Acorpemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5QbGVhc2Ugc2VlIHNlY3Rpb24gMy4xMC40IG9mIFJGQzUwNzAgYXMgYSBzdGFy dGluZyBwb2ludC7CoCBXZSBjYW4gY2hhbmdlIGl0IGlmIGl0IG5lZWRzIHRvIGJlIGNoYW5nZWQu wqAgVGhlIHZhbHVlIGlzIGZvciBhIGNvbmZpZGVuY2UgcmF0aW5nIG9uIHRoZSBpbmRpY2F0b3Jz IHNoYXJlZC7CoCBUaGUgZGVmaW5pdGlvbnMgbWF5IGJlIGhlbHBmdWwgZm9yIGFueW9uZSB3aG8g d2FudHMgdG8gd29yayBvbiB0aGlzIGRpc2N1c3Npb24uwqAgSU9ERUYgaGFzIHZhcmlvdXMgbWFy a2VycyB0aGF0IGNhbiBiZSB1c2VkIGluIGEgY29tcGxpbWVudGFyeSB3YXkgd2l0aG91dCBjb25m bGF0aW5nIHRoZSBtYXJrZXJzIG1lYW5pbmcuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHRoaW5rIHNv bWUgcGVvcGxlIHVzaW5nIElPREVGIGZpbmQgdGhlIG51bWVyaWNhbCB2YWx1ZXMgbW9yZSBoZWxw ZnVsLCBhbmQgaXQgd291bGQgYmUgZ29vZCB0byB1bmRlcnN0YW5kIHdoYXQgcGVvcGxlIGhhdmUg bGVhcm5lZCBmcm9tIHVzaW5nIHRoZSBjdXJyZW50IHN0cnVjdHVyZSAod2hhdCB3b3Jrcy9kb2Vz IG5vdCB3b3JrKS7CoCBUaGUgc2NhbGVzIEkgaGF2ZSBzZWVuIGFyZSAwLTEwMC7CoCBUaGVyZSBp cyBvZiBjb3Vyc2UgYSBzdWJqZWN0aXZlIGVsZW1lbnQgdG8gYXNzaWduaW5nIGEgbnVtZXJpY2Fs IHZhbHVlIHRvIHRoZSBjb25maWRlbmNlIGFuZCBpdCBtYXkgdmFyeSBmcm9tIGVudGl0eSB0byBl bnRpdHkuwqAgV2l0aCB0aGlzIHR5cGUgb2YgcmF0aW5nIHlvdSBtYXkgbmVlZCB0byBjb25zaWRl ciB3aG8gaXQgY2FtZSBmcm9tIGFuZCBob3cgdGhleSBzY29yZWQgdGhlIGNvbmZpZGVuY2UgcmF0 aW5nIHRvIG1hcCB0byB5b3VyIG93biByYXRpbmcuwqAgSXQgd291bGQgYmUgZ29vZCB0byBoZWFy IG1vcmUgdGhvdWdodHMgb24gdGhpcy7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gQy4gSGVucnkgQWRhbXMgJmFtcDsgQklFIFttYWlsdG86Y2hhdGxnYTIwMDBA eWFob28uY29tXSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEzIDI6 NDYgUE08YnI+PGI+VG86PC9iPiBNSUxFIElFVEY8YnI+PGI+Q2M6PC9iPiBNb3JpYXJ0eSwgS2F0 aGxlZW47ICdUYWtlc2hpIFRha2FoYXNoaSc7IFN0b2Vja2VyLCBQYXVsPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJs ZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCB2YWxpZ249dG9w IHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5S ZWdhcmRpbmcgdGhlIElPQ3Mgb3IgSW5kaWNhdG9ycyBvZiBDb21wcm9taXNlLCBDaHJpcyBtYWRl IGEgdml0YWwgcG9pbnQuJm5ic3A7IERpZmZlcmVudCBDb25maWRlbmNlIGxldmVscyB3aWxsIGNh dXNlIGNvbmZ1c2lvbi4mbmJzcDsgSXQgYXBwZWFycyB0aGF0IHRoZXJlIG1heWJlIGEgbmVlZCBm b3Igc29tZSB0eXBlIG9mIHNpbXBsaWZpZWQgc3RhbmRhcmRpemF0aW9uIHRvIGJlIGVzdGFibGlz aGVkIGJldHdlZW4gYWxsIFNoYXJpbmcgR3JvdXBzIGluIHRoaXMgcmVnYXJkLjxicj48YnI+UGVy aGFwcyBudW1lcmljYWwgc2NvcmluZyBzZXQgYXQgbG93ZXIgdmFsdWVzIHNob3VsZCBleHByZXNz IGxldmVscyBvZiB1cmdlbmN5Ljxicj4oIGkuZS4mbmJzcDsgMSA9IExlc3MgTGlrZWx5LCAmbmJz cDsgMiA9IFByb2JhYmxlLCZuYnNwOyAzID0gQSBDb25jZXJuLCZuYnNwOyA0ID0mbmJzcDsgVXJn ZW50LCZuYnNwOyA1ID0gSW1taW5lbnQgKTxicj48YnI+VGhhbmtzLDxicj5DLiBIZW5yeSBBZGFt czxicj48YnI+PGJyPjxicj5JIHNlZSBzb21lIGNvbmZ1c2lvbiBjb21pbmcgZG93biB0aGUgcGlr ZSBpZiB3ZSBzdGFydCB1c2luZyBDb25maWRlbmNlIHRoZTxicj53YXkgaXQgaXMgc3VwcG9ydGVk LiBJZiBJIGFtIHVzaW5nIGxvdy9tZWQvaGlnaCBhbmQgc29tZW9uZSBzZW5kcyBtZSBhbiBJb0M8 YnI+d2l0aCBhIHNjb3JlIG9mIDcwLCB3aGF0IGRvZXMgdGhhdCBtZWFuIHRvIG1lPyBXaGF0IGlm IEkgYW0gdXNpbmcgYSBzY2FsZSBvZjxicj4xIHRvIDQgYW5kIHNvbWVvbmUgZWxzZSBpcyBvbiBh IHNjYWxlIG9mIDEgdG8gNT8gV2UgbG9zZSB0aGUgYWJpbGl0eSB0bzxicj5kZXNjcmliZSBzb21l dGhpbmcgd2l0aCBhIGNvbnNpc3RlbnQgbGFuZ3VhZ2UuIEl0IHJlYWxseSBnZXRzIHVnbHkgd2hl biB3ZTxicj5zdG9yZSBJb0MgZnJvbSBtdWx0aXBsZSBzb3VyY2VzLiBJIGhhdmUgY29uZmlkZW5j ZSB2YWx1ZXMgdGhhdCBhcmUgbnVtZXJpYzxicj5hcyB3ZWxsIGFzIHRleHQuJm5ic3A7IE1ha2Vz IHNlYXJjaGluZyAvIHNvcnRpbmcgdmVyeSBwcm9ibGVtYXRpYy4gPGJyPjxicj5BdCB0aGlzIHBv aW50IHdlIGhhdmUgdG8gcm9sbCB3aXRoIHdoYXQgd2UgaGF2ZS4gSSB3b3VsZCBzdHJvbmdseSBy ZWNvbW1lbmQ8YnI+dGhhdCB3ZSByZXZpc2l0IHRoaXMgYXQgc29tZSBwb2ludC4gPGJyPjxicj5U aGFua3MsPGJyPjxicj4tLUNocmlzPGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj5Gcm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4gPGJyPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEy LCAyMDEzIDk6NTkgQU08YnI+VG86IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyAnVGFrZXNoaSBU YWthaGFzaGknOyBTdG9lY2tlciwgUGF1bDsgJ01JTEU8YnI+SUVURic8YnI+U3ViamVjdDogUkU6 IFttaWxlXSBJT0NzPGJyPjxicj5IaSBDaHJpcyAmYW1wOyBUYWtlLDxicj48YnI+SSdsbCBqdXN0 IGZvY3VzIG9uIHRoZSBjb25maWRlbmNlIHNjb3JpbmcuJm5ic3A7IFJpZ2h0IG5vdywgdGhlIHNj aGVtYSBhbGxvd3MgZm9yPGJyPnlvdSB0byBlaXRoZXIgdXNlIGEgbnVtZXJpY2FsIHNjb3JlIE9S IHRoZSByYXRpbmdzIG9mIGxvdywgbWVkaXVtLCBhbmQgaGlnaC48YnI+RGlmZmVyZW50IHNoYXJp bmcgZ3JvdXBzIGNhbiBkZWNpZGUgaG93IHRoZXkgd2FudCB0byBzaGFyZSB0aGUgZGF0YS4mbmJz cDsgSWY8YnI+cGVvcGxlIHdlcmUgdG8gdXNlIHRoZSBudW1lcmljYWwgdmFsdWVzLCBJIGFncmVl IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZTxicj5ndWlkYW5jZS4mbmJzcDsgVGhpcyBjb3Vs ZCBnbyBpbiB0aGUgSU9ERSBndWlkYW5jZSBkb2N1bWVudC48YnI+PGJyPkkgaGF2ZSBzZWVuIGV4 YW1wbGVzIG9mIGN1cnJlbnQgdXNlcnMgdGhhdCB1c2UgZWFjaCBvZiB0aGUgYXBwcm9hY2hlcywg c288YnI+d2UnbGwgbmVlZCB0byBrZWVwIHRoZSBvcHRpb24gZm9yIGJhY2t3YXJkcyBjb21wYXRp YmlsaXR5IGFuZCBpdCBpcyBuaWNlIHRvPGJyPmtlZXAgaW4gZmxleGlibGUgb3B0aW9ucyB3aGVy ZSB3ZSBjYW4uPGJyPjxicj5UaGFuayB5b3UsPGJyPkthdGhsZWVuPGJyPjxicj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlciA8YnI+U2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgOToyMiBBTTxicj5UbzogJ1Rha2VzaGkgVGFr YWhhc2hpJzsgTW9yaWFydHksIEthdGhsZWVuOyBTdG9lY2tlciwgUGF1bDsgJ01JTEUgSUVURic8 YnI+U3ViamVjdDogUkU6IFttaWxlXSBJT0NzPGJyPjxicj5UaGUgbnVtYmVyIG9mIGluZGljYXRv cnMgd291bGRuJ3QgbmVjZXNzYXJpbHkgZHJpdmUgdGhlIHVzZSBvZjxicj5pbmRpY2F0b3Jfc2V0 X2lkLiBUaGUgcHVycG9zZSBpcyB0byBzaG93IHJlbGF0aW9uc2hpcC4gSWYgSSBzZW50IDMgSVA8 YnI+YWRkcmVzc2VzIHRoYXQgd2VyZSB1c2VkIGFzIEMyIGZvciAzIGRpZmZlcmVudCBjYW1wYWln bnMgSSB3b3VsZCBoYXZlPGJyPnNlcGFyYXRlIGluZGljYXRvcl9zZXRfaWRzLCBlYWNoIHdpdGgg b25lIG9mIHRoZSAzIEMyIElQczxicj48YnI+TXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSBhIHNpbXBs ZSBsb3csIG1lZGl1bSwgaGlnaC4gSSB0aGluayBpZiB3ZSBicmVhayBpdDxicj5kb3duIHRvIG1v cmUgbGV2ZWxzIHRoYW4gdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24g c2NvcmluZyw8YnI+cmF0aW5nLCBldGMuIEkgdGhpbmsgbW9zdCBwZW9wbGUgc2hvdWxkIGJlIGFi bGUgdG8gdW5kZXJzdGFuZCBsb3cvbWVkL2hpZ2g8YnI+d2l0aG91dCBoYXZpbmcgdG8gaGF2ZSBh IG1hdGhlbWF0aWNhbCBtZXRob2QgZm9yIGFycml2aW5nIGF0IHRoZSBsZXZlbC4gPGJyPjxicj5M b3cgLSBJIGFtIG5vdCBzdXJlPGJyPk1lZGl1bSAtIEkgYW0gcmVhc29uYWJseSBzdXJlPGJyPkhp Z2ggLSBJIGFtIHZlcnkgc3VyZSA8YnI+PGJyPjxicj5UaGFua3MsPGJyPjxicj4tLUNocmlzPGJy Pjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBUYWtlc2hpIFRha2FoYXNo aSBbbWFpbHRvOjxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21w b3NlP3RvPXRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanAiPnRha2VzaGlfdGFrYWhhc2hpQG5p Y3QuZ28uanA8L2E+XSA8YnI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgNDoyMSBB TTxicj5UbzogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7IE1vcmlhcnR5LCBLYXRobGVlbjsgU3Rv ZWNrZXIsIFBhdWw7ICdNSUxFIElFVEYnPGJyPlN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dczxicj48 YnI+UmVnYXJkaW5nIHRoZSBpbmRpY2F0b3Jfc2V0X2lkLCBJIGFncmVlLCBpdCBpcyB1c2VmdWwg d2hlbiB3ZSBuZWVkIHRvIGRlYWw8YnI+d2l0aCBsYXJnZSBzZXRzIG9mIGluZGljYXRvcnMuPGJy PlNpbmNlIGluZGljYXRvcl9zZXRfaWQgYXR0cmlidXRlIGlzIG9wdGlvbmFsIChyaWdodD8pLCBp dCBjb3VsZCBiZSBvbWl0dGVkPGJyPmlmIHdlIG5lZWQgdG8gZGVhbCB3aXRoIG9ubHkgc21hbGwg bnVtYmVyIG9mIGluZGljYXRvcnMuPGJyPjxicj5SZWdhcmRpbmcgdGhlIHVzZSBjYXNlLCBJIGxp a2UgdGhlIGlkZWEgb2YgdXNpbmcgdGhlIGNvbmZpZGVuY2UgYXR0cmlidXRlPGJyPmZvciB0aGUg cmVhc29uIENocmlzIGtpbmRseSBkZXNjcmliZWQuPGJyPkkgd291bGQgbGlrZSB0byBoZWFyIGEg Yml0IG1vcmUgb24gdGhpczogaXMgaXQgZ29pbmcgdG8gYmUgbnVtZXJpY2FsPyBGb3I8YnI+aW5z dGFuY2UsIDEgbWVhbnMgJnF1b3Q7bm8gY29uZmlkZW5jZSZxdW90OyB3aGlsZSA1IG1lYW5zICZx dW90O3N0cm9uZyBjb25maWRlbmNlJnF1b3Q7LCBldGM/PGJyPjxicj5UaGFuayB5b3UuPGJyPlRh a2U8YnI+PGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgRnJv bTogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXIgW21haWx0bzo8YSBocmVmPSJodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1DaHJpc3RvcGhlci5IYXJyaW5ndG9uQGVt Yy5jb20iPkNocmlzdG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbTwvYT5dPGJyPiZndDsgU2VudDog RnJpZGF5LCBGZWJydWFyeSAwOCwgMjAxMyA0OjExIEFNPGJyPiZndDsgVG86IE1vcmlhcnR5LCBL YXRobGVlbjsgVGFrZXNoaSBUYWthaGFzaGk7IFN0b2Vja2VyLCBQYXVsOyAnTUlMRSBJRVRGJzxi cj4mZ3Q7IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dczxicj4mZ3Q7IDxicj4mZ3Q7IFdpdGggcmVz cGVjdCB0byB0eWluZyB0aGluZ3MgYmFjayB0byB0aHJlYXQgYWN0b3JzLCBmcm9tIHdoYXQgSSBo YXZlIDxicj4mZ3Q7IHNlZW4gYW5kIHVzZSB0aGlzIGlzIGEgZ2VuZXJhbGx5IGFjY2VwdGVkIGdy b3VwaW5nOjxicj4mZ3Q7IDxicj4mZ3Q7IEluZGljYXRvciAtLSZndDsgSW5kaWN0b3IgU2V0IC0t Jmd0OyBDYW1wYWlnbiAtLSZndDsgVGhyZWF0IEFjdG9yPGJyPiZndDsgPGJyPiZndDsgQ2FtcGFp Z24gYW5kIFRocmVhdCBBY3RvciBhcmUgd2hlcmUgaGF2aW5nIGEgJnF1b3Q7Q29uZmlkZW5jZSZx dW90OyBhdHRyaWJ1dGUgPGJyPiZndDsgd291bGQgYmUgYmVuZWZpY2lhbCBhcyBtYWtpbmcgdGhv c2UgYXNzb2NpYXRpb25zIGlzIG5vdCBhIHBlcmZlY3QgPGJyPiZndDsgc2NpZW5jZSBieSBhbnkg bWVhbnMuPGJyPiZndDsgPGJyPiZndDsgVGhhbmtzLDxicj4mZ3Q7IDxicj4mZ3Q7IC0tQ2hyaXM8 YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4m Z3Q7IEZyb206IE1vcmlhcnR5LCBLYXRobGVlbjxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBGZWJy dWFyeSAwNywgMjAxMyAyOjAwIFBNPGJyPiZndDsgVG86IFRha2VzaGkgVGFrYWhhc2hpOyBIYXJy aW5ndG9uLCBDaHJpc3RvcGhlcjsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFIDxicj4mZ3Q7IElFVEYn PGJyPiZndDsgU3ViamVjdDogUkU6IFttaWxlXSBJT0NzPGJyPiZndDsgPGJyPiZndDsgSGkgVGFr ZSAmYW1wOyBvdGhlcnMsPGJyPiZndDsgPGJyPiZndDsgVGhhbmtzIGZvciBjaGltaW5nIGluLCBJ J3ZlIGJlZW4gdGFsa2luZyBhYm91dCB0aGlzIHdpdGggQ2hyaXMgYW5kIGEgPGJyPiZndDsgZmV3 IG90aGVycyBvbiB0aGVpciB1c2UgY2FzZXMgYW5kIHdvdWxkIGxpa2UgbW9yZSBvcGluaW9ucy4m bmJzcDsgSSdsbCA8YnI+Jmd0OyBwcm92aWRlIGFuIG9wdGlvbiBiZWxvdyBmcm9tIHdoYXQgd2Ug aGF2ZSBkaXNjdXNzZWQgZnJvbSBhIENJUkMgdmlldyA8YnI+Jmd0OyBwb2ludC4mbmJzcDsgV2Ug YXJlIGFsc28gd29uZGVyaW5nIGhvdyB0byBhbHNvIHByb3ZpZGUgbG9naWMgaW4gSU9ERUYgdGhh dCA8YnI+Jmd0OyBjb3VsZCBjcm9zcyBvdmVyIGludG8gU0NJIGF0dGFjaGVkIHNjaGVtYXMgb3Ig SU9ERUYgZXh0ZW5zaW9ucyAodGhlIDxicj4mZ3Q7IHNvbHV0aW9ucyBtYXkgYWxsIHRpZSB0b2dl dGhlciB3aXRoIHRoaXMgZGlzY3Vzc2lvbiAtIG9yIHRoZXJlIG1heSBiZSA8YnI+Jmd0OyBiZXR0 ZXIvbW9yZSBlbGVnYW50IHNvbHV0aW9ucyBvdGhlcnMgd291bGQgbGlrZSB0byBwcm9wb3NlKS48 YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206 IFRha2VzaGkgVGFrYWhhc2hpIFttYWlsdG86PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89dGFrZXNoaV90YWthaGFzaGlAbmljdC5nby5qcCI+dGFr ZXNoaV90YWthaGFzaGlAbmljdC5nby5qcDwvYT5dPGJyPiZndDsgU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMDUsIDIwMTMgMTI6MDQgUE08YnI+Jmd0OyBUbzogSGFycmluZ3RvbiwgQ2hyaXN0b3Bo ZXI7IFN0b2Vja2VyLCBQYXVsOyBNb3JpYXJ0eSwgS2F0aGxlZW47ICdNSUxFIDxicj4mZ3Q7IElF VEYnPGJyPiZndDsgU3ViamVjdDogUkU6IFttaWxlXSBJT0NzPGJyPiZndDsgPGJyPiZndDsgJmd0 OyBJIGxpa2UgdGhpcyBkaXNjdXNzaW9uLjxicj4mZ3Q7ICZndDsgSSBhZ3JlZSwgaXQgd291bGQg YmUgZ29vZCBpZGVhIHRvIGhhdmUgaW5kaWNhdG9yIGlkZW50aWZpZXJzIGluc2lkZSA8YnI+Jmd0 OyAmZ3Q7IHRoZSBJT0MtcmVsYXRlZCBjbGFzc2VzLjxicj4mZ3Q7IDxicj4mZ3Q7IEtNTTogQXQg dGhlIGNsYXNzIGxldmVsLCB3ZSBtYXkgaGF2ZSBzZXZlcmFsIGluZGljYXRvcnMgbGlzdGVkIHRo YXQgPGJyPiZndDsgc2hvdWxkIGJlIHZpZXdlZCBhcyBhIHNldCBhbmQgbWF5IGhhdmUgYW5vdGhl ciBpbnN0YW5jZSBvZiB0aGF0IHNhbWUgPGJyPiZndDsgY2xhc3MgdGhhdCBpcyBhIHJlbGF0ZWQg aXNzdWUsIGJ1dCBhIHNlcGFyYXRlIHNldC4mbmJzcDsgV2UgY291bGQgYXMgeW91IDxicj4mZ3Q7 IHNheSwgbGlzdCB0aGUgaW5kaWNhdG9yIElEcyBjb25uZWN0ZWQgdGhyb3VnaCB0aGUgcmVmZXJl bmNlIGNsYXNzLiZuYnNwOyA8YnI+Jmd0OyBUaGUgc2V0IElEcyBtaWdodCBnaXZlIHVzIG90aGVy IHdheXMgdG8gZ3JvdXAgdGhlIHZhbHVlcyB3aGVuIHdlIGdldCA8YnI+Jmd0OyBpbnRvIGxvZ2lj IGFuZCByZWxhdGlvbnNoaXBzIGJldHdlZW4gc2V0cyBvciBpbmRpY2F0b3JzLiZuYnNwOyBUaGlz IGNvdWxkIDxicj4mZ3Q7IGFsc28gYmUgYSB3YXkgdG8gY29ubmVjdCBpbmRpY2F0b3JzIG9yIHNl dHMgYWNyb3NzIFhNTCBkb2N1bWVudHMgdGhhdCA8YnI+Jmd0OyBjb3VsZCBoYXZlIGJlZW4gc2hh cmVkIHByZXZpb3VzbHkuJm5ic3A7IElmIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiA8YnI+ Jmd0OyBpbmRpY2F0b3JzIGluIHRoZSBzZXQsIHRoZW4gdGhpcyBiZWNvbWVzIHVzZWZ1bCwgZm9y IHNtYWxsZXIgc2V0cywgSSA8YnI+Jmd0OyBhZ3JlZSBpdCBkb2Vzbid0IG1ha2UgYXMgbXVjaCBz ZW5zZS48YnI+Jmd0OyA8YnI+Jmd0OyBXaGF0IGRvIG90aGVycyB0aGluaz88YnI+Jmd0OyA8YnI+ Jmd0OyAmZ3Q7Jmd0OyBUaGVuIGZvciBpbmRpY2F0b3JzIG5vdCBpbmNsdWRlZCBpbiB0aGUgYmFz ZSBzY2hlbWEgdGhhdCBtYXkgbm90IDxicj4mZ3Q7ICZndDsmZ3Q7IGZpdCBpbnRvIGEgY2F0ZWdv cnkgaW4gdGhlIFNDSSBkcmFmdCwgZG8gd2UgY3JlYXRlIGEgcGxhY2UgZm9yIDxicj4mZ3Q7ICZn dDsmZ3Q7IHRoZXNlIG9mZiBvZiBTQ0kgb3IgcmlnaHQgb2ZmIG9mIHRoZSBJT0RFIHNjaGVtYSBp biBFdmVudERhdGE/IDxicj4mZ3Q7ICZndDsmZ3Q7IChtb3JlIGRldGFpbHM8YnI+Jmd0OyBvbjxi cj4mZ3Q7ICZndDsmZ3Q7IHRoaXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuPGJyPiZndDsgJmd0Ozxi cj4mZ3Q7ICZndDsgSWYgd2UgY291bGQgc2VlIGFueSBpbmRpY2F0b3Igb2YgY29tcHJvbWlzZSBh cyBjb21wdXRlciBldmVudCA8YnI+Jmd0OyAmZ3Q7IHJlY29yZCwgd2UgY291bGQgdXNlIFNDSTpF dmVudFJlcG9ydCBjbGFzcyBhcyB0aGUgcGxhY2UgZm9yIHRoZSA8YnI+Jmd0OyAmZ3Q7IFhNTC1i YXNlZCBJT0NzIHRoYXQgY291bGRuJ3QgZml0IGFueXdoZXJlIGVsc2UuPGJyPiZndDsgPGJyPiZn dDsgS01NOiBUaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCBpZGVhIHRvIG1lLiZuYnNwOyBUaGlzIHNo b3VsZCBnbyBpbnRvIGd1aWRhbmNlIDxicj4mZ3Q7IGluIHRoZSBTQ0kgZHJhZnQuJm5ic3A7IERv ZXMgYW55b25lIGVsc2Ugd2FudCB0byB3ZWlnaCBpbj88YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0OyBGb3IgdGhlIG5vbi1YTUwgSU9Dcywgd2UgY291bGQgdXNlIFJlY29yZERhdGEg Y2xhc3MsIGFzIHN1Z2dlc3RlZC48YnI+Jmd0OyBLTU06IFNvdW5kcyBnb29kLCB0aGFua3MhPGJy PiZndDsgPGJyPiZndDsgJmd0OyBJIGFncmVlIHRvIGhhdmUgaW5kaWNhdG9yX3VpZCwgYnV0IEkg YW0gbm90IHN1cmUgYWJvdXQgdGhlIG5lZWRzIG9mIDxicj4mZ3Q7ICZndDsgdGhlIGluZGljYXRv cl9zZXRfaWQuPGJyPiZndDsgJmd0OyBJIHVuZGVyc3RhbmQgd2UgY291bGQgZG8gc29tZSBncm91 cGluZyBvZiBpbmRpdmlkdWFsIGluZGljYXRvcl91aWRzIDxicj4mZ3Q7ICZndDsgYW5kIGl0cyB1 c2FiaWxpdHksIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgd2UgZG8gbm90IGhhdmUgYW55IDxi cj4mZ3Q7ICZndDsgb3RoZXIgd2F5IHRvIGV4cHJlc3MgdGhlc2UgZ3JvdXBpbmdzLjxicj4mZ3Q7 ICZndDsgRm9yIGluc3RhbmNlLCZuYnNwOyBhIFJlZmVyZW5jZSBjbGFzcyByZWZlcnMgdG8gc2V2 ZXJhbCBpbmRpY2FkdG9yX3VpZHMuPGJyPiZndDsgSW48YnI+Jmd0OyAmZ3Q7IHRoaXMgY2FzZSwg dGhleSBjb3VsZCBiZSwgaW4gYSBzZW5zZSwgZ3JvdXBlZC4gSXNuJ3QgaXQgZW5vdWdoPzxicj4m Z3Q7IDxicj4mZ3Q7IEtNTTogSXQgbWF5IGJlLCB3aGF0IGRvIHlvdSB0aGluayBhYm91dCBsYXJn ZSBzZXRzIG9mIGluZGljYXRvcnMgb3IgPGJyPiZndDsgc3Vic2VxdWVudCBtZXNzYWdlcyB0aGF0 IGFkZCBpbmRpY2F0b3JzIHRvIGV4aXN0aW5nIHNldHM/Jm5ic3A7IFdvdWxkIHRoaXMgPGJyPiZn dDsgaGFwcGVuPyZuYnNwOyBXb3VsZCBpdCBiZSBlYXNpZXIgdG8gZXhwcmVzcyByZWxhdGlvbnNo aXBzIHdpdGggc2V0cyBvZiA8YnI+Jmd0OyBpbmRpY2F0b3JzIGluIGFkZGl0aW9uIHRvIGluZGl2 aWR1YWwgaW5kaWNhdG9ycz8mbmJzcDsgQnkgdXNpbmcgdGhpcywgaXQgPGJyPiZndDsgY291bGQg Z2l2ZSB1cyBhIHVuaXF1ZSB3YXkgdG8gYWxzbyBwcm92aWRlIHRoZSBsb2dpYyBhbmQgcmVsYXRp b25zaGlwcyA8YnI+Jmd0OyBpbiBhIG5ldyBjbGFzcyBvZiBJT0RFRiBzbyB3ZSBkb24ndCBoYXZl IHRvIHdvcnJ5IGFib3V0IGFkZGluZyBpdCBpbnRvIDxicj4mZ3Q7IHRoZSBjdXJyZW50PGJyPnN0 cnVjdHVyZS48YnI+Jmd0OyBJZiB0aGVyZSBhcmUgYmV0dGVyIHdheXMgdG8gaGFuZGxlIHRoYXQs IGFuZCBvdGhlcnMgY2FuIHByb3ZpZGUgc29tZSA8YnI+Jmd0OyBvcHRpb25zLCB0aGF0IHdvdWxk IGJlIGFwcHJlY2lhdGVkITxicj4mZ3Q7IDxicj4mZ3Q7IFRoYW5rIHlvdSw8YnI+Jmd0OyBLYXRo bGVlbjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgSSB3b3VsZCBhcHByZWNpYXRlIGlmIGFueWJvZHkg Y291bGQgc2hhcmUgZXhwZXJ0aXNlIG9uIHRoaXMuIFRob3VnaDxicj4mZ3Q7IEk8YnI+Jmd0OyAm Z3Q7IHRoaW5rIEkgaGF2ZSByZWFkIGFsbCB0aGUgZW1haWxzIGluIHRoZSBsaXN0LCBJIG1pZ2h0 IGhhdmUgPGJyPiZndDsgJmd0OyBtaXMtdW5kZXJzdG9vZCBzb21lIHBvaW50cy48YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBCeSB0aGUgd2F5LCBJIHRoaW5rIHRoZSBpbmRpY2F0b3JfdWlkcyBz aG91bGQgYmUgYWRkZWQgdG8gdGhlIFNDSTxicj5jbGFzc2VzJzxicj4mZ3Q7ICZndDsgYXR0cmli dXRlcyBzbyB0aGF0IHRoZXkgY2FuIGJlIGNvcnJlbGF0ZWQgd2l0aCBhbm90aGVyIGluZm9ybWF0 aW9uIDxicj4mZ3Q7ICZndDsgYXM8YnI+Jmd0OyB3ZWxsLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAm Z3Q7IFRoYW5rczxicj4mZ3Q7ICZndDsgVGFrZTxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxi cj4mZ3Q7IEZyb206IDxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9j b21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZyI+bWlsZS1ib3VuY2VzQGlldGYub3JnPC9h PiBbbWFpbHRvOjxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21w b3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZyI+bWlsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIDxicj4mZ3Q7IE9mIEhhcnJpbmd0b24sIENocmlzdG9waGVyPGJyPiZndDsgU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMDUsIDIwMTMgNDoyNSBBTTxicj4mZ3Q7IFRvOiBTdG9lY2tl ciwgUGF1bDsgTW9yaWFydHksIEthdGhsZWVuOyBNSUxFIElFVEY8YnI+Jmd0OyBTdWJqZWN0OiBS ZTogW21pbGVdIElPQ3M8YnI+Jmd0OyA8YnI+Jmd0OyBJIHRoaW5rIHNvbWUgc29ydCBvZiBncm91 cCBJRCB3b3VsZCBkbyB0aGUgdHJpY2suIFdlIGFsc28gbmVlZCBhIDxicj4mZ3Q7IGxvZ2ljYWwg YW5kIC8gb3Igc29tZXdoZXJlIHRvIHNob3cgcmVsYXRpb25zaGlwIGJldHdlZW4gaW5kaWNhdG9y cy4gSWYgPGJyPiZndDsgSSBnaXZlIHlvdTxicj4mZ3Q7IDI8YnI+Jmd0OyByZWdpc3RyeSBrZXlz IGRvIHRoZXkgYm90aCBoYXZlIHRvIGJlIHByZXNlbnQgdG8gYmUgYW4gaW5kaWNhdGlvbiBvZiA8 YnI+Jmd0OyBjb21wcm9taXNlIG9yIGlzIGVpdGhlciBvbmUgYnkgdGhlbXNlbHZlcyBhbiBpbmRp Y2F0b3I/IEJvdGggd291bGQgPGJyPiZndDsgaGF2ZSB0aGUgc2FtZSBncm91cCBJRCBzaW5jZSB0 aGV5IGFyZSByZWxhdGVkLjxicj4mZ3Q7IDxicj4mZ3Q7IFRoYW5rcyw8YnI+Jmd0OyAtLUNocmlz PGJyPiZndDsgPGJyPiZndDsgRnJvbTogU3RvZWNrZXIsIFBhdWw8YnI+Jmd0OyBTZW50OiBTdW5k YXksIEZlYnJ1YXJ5IDAzLCAyMDEzIDg6MjYgUE08YnI+Jmd0OyBUbzogTW9yaWFydHksIEthdGhs ZWVuOyBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgTUlMRSBJRVRGPGJyPiZndDsgU3ViamVjdDog UmU6IFttaWxlXSBJT0NzPGJyPiZndDsgPGJyPiZndDsgV2hhdCBpZiB3ZSBhZGRlZCBpbmRpY2F0 b3IgZ3JvdXAgSUQgYWxvbmcgd2l0aCB0aGUgaW5kaWNhdG9yX3VpZD8mbmJzcDsgPGJyPiZndDsg VGhpcyB3b3VsZCBhbGxvdyB5b3UgdG8gZ3JvdXAgaW5kaWNhdG9ycyB0aGF0IGFyZSByZWxhdGVk IGludG8gdGhlIDxicj4mZ3Q7IHNhbWUgZ3JvdXAgSUQuPGJyPiZndDsmbmJzcDsgV291bGQgdGhp cyByZXNvbHZlIHRoZSBpc3N1ZT88YnI+Jmd0OyA8YnI+Jmd0OyBJdCBpcyBlaXRoZXIgdGhhdCBv ciBnb2luZyBiYWNrIHRvIGFkZGluZyBhIERldGVjdGlvbiAob3IgSW5kaWNhdG9ycykgPGJyPiZn dDsgY2xhc3MgdGhhdCB3aWxsIHNob3VsZCBiZSB1c2VkIHRvIHRha2UgYWxsIG9mIHRoZSBpbmRp Y2F0b3JzIHB1dCB0aGVtIDxicj4mZ3Q7IGludG8gb25lIHBsYWNlIGFuZCBoYXZlIHRoZSBhYmls aXR5IHRvIGdyb3VwIHRoZSBvbmVzIHRoYXQgZ28gPGJyPiZndDsgdG9nZXRoZXIuJm5ic3A7IEkg ZG9uJ3QgbWVhbiBhIHBsYWNlIHRvIHB1dCBpbmRpY2F0b3JzIHRoYXQgYXJlIG1pc3NpbmcgPGJy PiZndDsgZnJvbSBJT0RFRi5JIG1lYW4gYSBwbGFjZSBpbiB0aGUgSU9ERUYgZG9jdW1lbnQgd2hl cmUgeW91IHB1dCB0aGUgPGJyPiZndDsgaW5kaWNhdG9ycyB0aGF0IGFyZSB1c2VkIGZvciBkZXRl Y3Rpb24gYW5kIHByZXZlbnRpb24gb2YgdGhlIHNoYXJlZCA8YnI+Jmd0OyBJbmNpZGVudC4mbmJz cDsgSSBkb24ndCBrbm93IHRoZSBhbnN3ZXIgaGVyZSwgYnV0IHRoZXJlIGhhcyBnb3QgdG8gYmUg YSA8YnI+Jmd0OyBnb29kIHdheSBmb3IgaW5kaWNhdG9ycyB0byBiZSBpZGVudGlmaWVkIGFuZCBi ZWluZyBhYmxlIHRvIGdyb3VwIHRoZW0gPGJyPiZndDsgYXMgQ2hyaXMgaGFzIHN1Z2dlc3RlZCB3 aXRob3V0IGJhc2ljYWxseSByZWNyZWF0aW5nIHNvbWV0aGluZyA8YnI+Jmd0OyBjb21wbGljYXRl ZCBsaWtlIFNUSVguPGJyPiZndDsgPGJyPiZndDsgUGF1bDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4m Z3Q7IFBhdWwgVy4gU3RvZWNrZXIsIFBoLkQuPGJyPiZndDsgU01DIExlYWQgQ29udGVudCBBcmNo aXRlY3Q8YnI+Jmd0OyBSU0EsIFRoZSBTZWN1cml0eSBEaXZpc2lvbiBvZiBFTUM8YnI+Jmd0OyBj ZWxsOiAzMDIuMzc5LjMzNzUgfCBlOiA8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhv by5jb20vbWMvY29tcG9zZT90bz1wYXVsLnN0b2Vja2VyQHJzYS5jb20iPnBhdWwuc3RvZWNrZXJA cnNhLmNvbTwvYT48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBGcm9tOiAmbHQ7TW9yaWFydHkm Z3Q7LCBLYXRobGVlbiAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSI+a2F0aGxlZW4ubW9yaWFy dHlAZW1jLmNvbTwvYT4mZ3Q7PGJyPiZndDsgRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAzLCAyMDEz IDU6MTEgUE08YnI+Jmd0OyBUbzogJnF1b3Q7SGFycmluZ3RvbiwgQ2hyaXN0b3BoZXImcXVvdDsg Jmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3Rv PUNocmlzdG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbSI+Q2hyaXN0b3BoZXIuSGFycmluZ3RvbkBl bWMuY29tPC9hPiZndDssIE1JTEUgPGJyPiZndDsgSUVURiAmbHQ7PGEgaHJlZj0iaHR0cDovL3Vz Lm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPiZndDsgU3ViamVjdDogUmU6IFttaWxlXSBJT0NzPGJyPiZndDsg PGJyPiZndDsgSGkgQ2hyaXMsPGJyPiZndDsgPGJyPiZndDsgSSBhZ3JlZSwgd2UgaGF2ZSBzb21l IHdvcmsgdG8gZG8gaW4gdGhlIHVwZGF0ZWQgSU9ERUYsIFJGQzUwNzAtYmlzLjxicj4mZ3Q7IDxi cj4mZ3Q7IFRoZSBsaXN0IGhhcyBhbHJlYWR5IHNhaWQgdGhleSB3b3VsZCBsaWtlIHRvIHNlZSBp bmRpY2F0b3JzIGFkZGVkIHRvIDxicj4mZ3Q7IHRoZSBkZWZpbml0aW9ucyBpbiBSRkM1MDcwLWJp cywgdG8gYmUgbW9yZSBleHBsaWNpdCBhYm91dCBpbmNsdWRpbmcgPGJyPiZndDsgaW5kaWNhdG9y cyBhbmQgc2V0cyBvZiBpbmRpY2F0b3JzIGluIElPREUgZG9jdW1lbnRzIGFzIG9wcG9zZWQgdG8g PGJyPiZndDsgJ3BhcnRzIG9mIGFuIGluY2lkZW50IG9yIHRoZSB1c2VmdWwgaW5mb3JtYXRpb24g b24gYW4gaW5jaWRlbnQgZm9yIDxicj4mZ3Q7IHNoYXJpbmcgcHVycG9zZXMuJm5ic3A7IEl0IHdh cyB3cml0dGVuIGJlZm9yZSB3ZSB1c2VkIHRlcm1zIGxpa2UgPGJyPiZndDsgaW5kaWNhdG9ycy4m bmJzcDsgV2l0aCB0aGF0IGluIG1pbmQsIFJvc2VsbGEgcHJvcG9zZWQgYSBudW1iZXIgb2YgY2hh bmdlcyA8YnI+Jmd0OyBiYWNrIGluIEp1bHksIGJvdGggZm9yIGd1aWRhbmNlIGFuZCBmb3I8YnI+ Zm9ybWF0PGJyPiZndDsgdXBkYXRlcy4mbmJzcDsgSXQgbWF5IGhlbHAgdG8gaGF2ZSB0aGUgZmly c3QgZHJhZnQgdHJ5IHRvIGFkZHJlc3MgYXQgbGVhc3QgPGJyPiZndDsgc29tZSBvZiB0aGVzZSBp c3N1ZXMgc28gcGVvcGxlIGNhbiB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtcyBhbmQgYXQgPGJyPiZn dDsgbGVhc3QgYSBwcm9wb3NlZCBzb2x1dGlvbi48YnI+Jmd0OyA8YnI+Jmd0OyBBcyB5b3UgcG9p bnQgb3V0LCB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gc2hvdyByZWxhdGlvbnNoaXBzIGJldHdlZW4g PGJyPiZndDsgc2V0cyBvZiBpbmRpY2F0b3JzLCB3aGVyZSB3ZSBtYXkgaGF2ZSBhIGZldyBzZXRz IG9mIGluZGljYXRvcnMgdGhhdCA8YnI+Jmd0OyBjb3VsZCBoYXZlIGEgcmVsYXRpb25zaGlwIHRv IGVhY2ggb3RoZXIgd2l0aGluIGEgZG9jdW1lbnQuJm5ic3A7IEluIHRoZSA8YnI+Jmd0OyBKdWx5 IHByZXNlbnRhdGlvbiwgb25lIG9mIHRoZSBxdWVzdGlvbnMgd2FzIHRvIHNlZSBpZiB3ZSBzaG91 bGQgYWRkIDxicj4mZ3Q7IG5ldyBjYXRlZ29yeSBhdHRyaWJ1dGUgdmFsdWVzIGZvciB0aGUgU3lz dGVtIGNsYXNzIHRoYXQgd291bGQgY29ubmVjdCA8YnI+Jmd0OyB0aGUgbGlzdCBvZiBpbmNsdWRl ZCBpbmRpY2F0b3JzLiZuYnNwOyBJIHRoaW5rIHdlIHNob3VsZCBzdGlsbCBrZWVwIHRoZSA8YnI+ Jmd0OyBjb25jZXB0IG9mIGEgTm9kZSB0byBhIHNpbmdsZSBub2RlLCBidXQgcGVyaGFwcyB3aXRo aW4gU3lzdGVtLCBsaXN0IDxicj4mZ3Q7IG11bHRpcGxlIHNldHMgb2YgTm9kZXMgdGhhdCBtYXkg YmUgb25lIHR5cGUgb2YgYXR0YWNrLiZuYnNwOyBSb3NlbGxhIGhhZCA8YnI+Jmd0OyBzdWdnZXN0 ZWQgcHVsbGluZyBmb3J3YXJkIHRoZSAmcXVvdDtGcmF1ZFR5cGUmcXVvdDsgZnJvbSBSRkM1OTAx LCB0aGlzIHdvdWxkIDxicj4mZ3Q7IGhlbHAgc29sdmUgdGhlIGlzc3VlIGFzIE5vZGVSb2xlIHZh bHVlcyB3b3VsZCBjb21wbGltZW50IGFuIEF0dGFja1R5cGUgPGJyPiZndDsgKEZyYXVkVHlwZSB2 YWx1ZXMgY291bGQgYmUgaW5jbHVkZWQgaW4gQXR0YWNrVHlwZSBvciBzb21lIGJyb2FkZXIgPGJy PiZndDsgdGVybSkuJm5ic3A7IEl0IG1heSBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGUgRnJhdWRUeXBl cywgcGx1cyBhdHRyaWJ1dGUgdmFsdWVzIDxicj4mZ3Q7IGxpa2UgJnF1b3Q7QzItc2VydmVyJnF1 b3Q7LCAmcXVvdDtzaW5raG9sZSZxdW90OywmbmJzcDsgJnF1b3Q7TWFsd2FyZURpc3RyaWJ1dGlv biZxdW90OyBmb3IgYWRkZWQgY29udGV4dCA8YnI+Jmd0OyBzbyB5b3Uga25vdyB3aGF0IHRvIGRv IHdpdGggdGhlIHJlY2VpdmVkIHNldCBvZiBpbmRpY2F0b3JzLjxicj4mZ3Q7IDxicj4mZ3Q7IEkg YW0gcHJvcG9zaW5nIHRoYXQgd2UgY2hhbmdlIElPREVGIHRvIGluY2x1ZGUgbXVsdGlwbGUgc2V0 cyBvZjxicj5pbmRpY2F0b3JzLDxicj4mZ3Q7IGFkZCBhbiBBdHRhY2tUeXBlIGF0dHJpYnV0ZSAo b3Igc29tZSBvdGhlciBuYW1lKSwgYSBtZXRob2QgdG8gY29ubmVjdCA8YnI+Jmd0OyBpbmRpY2F0 b3JzIGFuZCBpbmRpY2F0b3Igc2V0cyB3aXRoaW4gYW4gSU9ERUYgdXNpbmcgYW4gYXR0cmlidXRl IG9mIDxicj4mZ3Q7IGluZGljYXRvcl91aWQgKG9yIHNvbWUgb3RoZXIgbmFtZSkgd2l0aCBhIHN0 cmluZyB2YWx1ZSB0byBtYWtlIHRoZSA8YnI+Jmd0OyBjb25uZWN0aW9uIHBvaW50cywgYW5kIGFk ZCBhIGZldyBpbmRpY2F0b3JzIHRoYXQgYXJlIGNvbW1vbmx5IHNoYXJlZCA8YnI+Jmd0OyBpbnRv IHRoZSBiYXNlIElPREVGLjxicj4mZ3Q7IDxicj4mZ3Q7IEJhY2sgaW4gSnVseSwgd2UgdGFsa2Vk IGFib3V0IGFkZGluZyBSZWdpc3RyeSBLZXkvVmFsdWUgcGFpcnMgYW5kIDxicj4mZ3Q7IGhhc2hl cyB0byB0aGUgbWFpbiBJT0RFRiBkb2N1bWVudCAodHJ5aW5nIHRvIHNlZSBpZiB0aGlzIHdpbGwg aGVscCA8YnI+Jmd0OyBDaHJpcyBiZWxvdykuJm5ic3A7IFdoYXQgaWYgd2UgYWRkZWQgdGhlIFJl Z2lzdHJ5IEtleS9WYWx1ZSBwYWlycyBhcyBhIDxicj4mZ3Q7IGNsYXNzIG9mZiBvZiBSZWNvcmRE YXRhLCB1c2luZyBhIHNpbWlsYXIgc3RydWN0dXJlIHRvIHdoYXQgaXMgaW4gPGJyPiZndDsgUkZD NTkwMSwgYW5kIGFsc28gYWRkZWQgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBoYXNoZXMgaW4gUmVj b3JkRGF0YT8mbmJzcDsgPGJyPiZndDsgSSB0aGluayBpZiB3ZSB0aGVuIGhhZCB0aGUgaW5kaWNh dG9yX3VpZCBhdCB0aGUgUmVjb3JkRGF0YSBsZXZlbCwgd2UgPGJyPiZndDsgY291bGQgY29ubmVj dCBhIHNldCB3aXRoaW4gdGhhdCBzdHJ1Y3R1cmUgYW5kIHJlcGVhdCB0aGUgc3RydWN0dXJlIGZv ciA8YnI+Jmd0OyBvdGhlciBzZXRzIGluIHRoZSBzYW1lIHdheSB3ZSB3b3VsZCBkbyB3aXRoIE5v ZGUgaW5zaWRlIG9mIHRoZSBTeXN0ZW0gPGJyPiZndDsgY2xhc3MsIHVzaW5nIHRoZSBpbmRpY2F0 b3JfdWlkIHRvIHRpZSB0aGUgc2V0IHRvZ2V0aGVyLiZuYnNwOyBUaGVuIGF0IHRoZSA8YnI+Jmd0 OyBtb3JlIHNwZWNpZmljIGxldmVsIGZvciB0aGUgaGFzaCwgcmVnaXN0cnkgS2V5L3ZhbHVlLCBJ UCwgZXRjLiB1c2UgYW4gPGJyPiZndDsgaW5kaWNhdG9yX3VpZCBpZiB3ZSBuZWVkZWQgdGhlbSBt YXJrZWQgYXQgdGhpcyBsZXZlbCBhcyB3ZWxsPyZuYnNwOyBNYXliZSA8YnI+Jmd0OyB3ZSB3YW50 IGluZGljYXRvcl9zZXQgYXQgdGhlIGhpZ2hlciBsZXZlbD8mbmJzcDsgSSdkIGxpa2Ugc29tZSBv cGluaW9ucyBvbiA8YnI+Jmd0OyB0aGlzIGFwcHJvYWNoLiZuYnNwOyArMSBpZiB5b3UgYWdyZWUs IHN1Z2dlc3Rpb25zIGlmIHlvdSBoYXZlIG90aGVyIGlkZWFzIDxicj4mZ3Q7IHRoYXQgbWF5IHdv cmsgYmV0dGVyLjxicj4mZ3Q7IDxicj4mZ3Q7IFdlJ2xsIGFsc28gbmVlZCB0byB3b3JyeSBhYm91 dCBtYXJraW5nIHRoZSBpbmRpY2F0b3JzIHRvIHByZXZlbnQgPGJyPiZndDsgZm9yd2FyZCBzaGFy aW5nIHdoZW4gbm90IHBlcm1pdHRlZC4mbmJzcDsgV2UgbWF5IHdhbnQgdG8gdXNlIHRoZXNlIHZh bHVlcyA8YnI+Jmd0OyBvciBzb21ldGhpbmcgZWxzZS48YnI+Jmd0OyA8YnI+Jmd0OyBUaGFuayB5 b3UhPGJyPiZndDsgS2F0aGxlZW48YnI+Jmd0OyA8YnI+Jmd0OyBGcm9tOiBIYXJyaW5ndG9uLCBD aHJpc3RvcGhlcjxicj4mZ3Q7IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMTMgMTI6MDEg UE08YnI+Jmd0OyBUbzogTW9yaWFydHksIEthdGhsZWVuOyBNSUxFIElFVEY8YnI+Jmd0OyBTdWJq ZWN0OiBSRTogW21pbGVdIElPQ3M8YnI+Jmd0OyA8YnI+Jmd0OyBJIHRoaW5rIHdlIGhhdmUgYSBi aWdnZXIgcmVsYXRpb25zaGlwIGlzc3VlIHRvIGFkZHJlc3MuIExldCB1c2UgdGhlIDxicj4mZ3Q7 IFdhdGNobGlzdCBVc2UgQ2FzZS4gQSBidW5jaCBvZiBpbmRpY2F0b3JzIGFyZSBzZW50IGluIG9u ZSBtZXNzYWdlLiBJbiA8YnI+Jmd0OyB0aGF0IG1lc3NhZ2Ugd2UgY291bGQgaGF2ZSBncm91cGlu Z3Mgb2YgaW5kaWNhdG9ycyB0aGF0IHdlIG5lZWQgdG8gPGJyPiZndDsgc2hvdyBhcmU8YnI+Jmd0 OyByZWxhdGVkOjxicj4mZ3Q7IDxicj4mZ3Q7IFR3byBvciBtb3JlIGluZGljYXRvcnMgb2YgZGlm ZmVyZW50IHR5cGUgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUgdGhyZWF0Ojxicj4mZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBmaWxlIGhhc2ggb2YgYSBtYWxpY2lvdXMgZmlsZSBh bmQgdGhlIFVSTCBvZiB0aGUgQzIgdGhhdCA8YnI+Jmd0OyB0aGUgZmlsZSB1c2VzLiBFaXRoZXIg b3IgYm90aCBtYXkgYmUgcHJlc2VudCB0byBpbmRpY2F0ZSBhIGNvbXByb21pc2UuPGJyPiZndDsg PGJyPiZndDsgVHdvIG9yIG1vcmUgaW5kaWNhdG9ycyBvZiB0aGUgc2FtZSB0eXBlIHRoYXQgcmVs YXRlIHRvIHRoZSBzYW1lIHRocmVhdDo8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAyIGRpZmZlcmVudCByZWdpc3RyeSB2YWx1ZXMgZm9yIHRoZSBzYW1lIHJlZ2lzdHJ5IGtleS4g SWYgPGJyPiZndDsgZWl0aGVyIHZhbHVlIGlzIHByZXNlbnQgaXQgaXMgYSBjb21wcm9taXNlIGlu ZGljYXRvciBidXQgYm90aCB3aWxsIG5vdCA8YnI+Jmd0OyBiZTxicj5wcmVzZW50Ljxicj4mZ3Q7 IDxicj4mZ3Q7IFRoZSBwcm9ibGVtIGNvbXBvdW5kcyBpdHNlbGYgdmVyeSBxdWlja2x5LiBDb25z aWRlciB0aGUgc2NlbmFyaW8gd2hlcmUgPGJyPiZndDsgYm90aCBncm91cGluZ3MgYWJvdmUgYXJl IHBhcnQgb2YgdGhlIHNhbWUgdGhyZWF0LiBJIG5lZWQgdG8gc2hvdyB0aGF0IDxicj4mZ3Q7IGxv Z2ljYWwgZ3JvdXBpbmdzIG9mIEluZGljYXRvcnMgYXJlIHJlbGF0ZWQgYXMgd2VsbC4gV2UgY2Fu J3Qgc2VuZCA8YnI+Jmd0OyBtdWx0aXBsZSBJT0RFRiBtZXNzYWdlcyBmb3IgdGhpcyBmcm9tIHdo YXQgSSByZW1lbWJlciByZWFkaW5nLjxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBsYXN0IG9uZSBJIGNh biB0aGluayBvZiB3b3VsZCBiZSB3aGVuIHlvdSBoYXZlIDIgZGlmZmVyZW50IDxicj4mZ3Q7IGlu ZGljYXRvcnMgdGhhdCByZXByZXNlbnQgdGhlIHNhbWUgaW5kaWNhdG9yLiBJdCdzIG5vdCB1bmNv bW1vbiB0byA8YnI+Jmd0OyBzZW5kIGJvdGggdGhlPGJyPiZndDsgTUQ1PGJyPiZndDsgYW5kIFNI QTEgaGFzaCBvZiBhIG1hbGljaW91cyBmaWxlLiBUaGUgaW5kaWNhdG9yIGlzIHRoZSBmaWxlIGJ1 dCB0aGUgPGJyPiZndDsgSU9DcyBhcmUgdGhlIDIgaGFzaCB2YWx1ZXMuIEhvdyBkbyB3ZSBzaG93 IHRoZXkgYXJlIHJlbGF0ZWQ/IElmIHdlIHVzZSA8YnI+Jmd0OyBhIHVuaXF1ZSBJbmlkY2F0b3Ig SUQgZm9yIGVhY2ggaGFzaCB2YWx1ZSB0aGVyZSBuZWVkcyB0byBiZSBhIGhpZ2hlciA8YnI+Jmd0 OyBsZXZlbDxicj5ncm91cGluZy48YnI+Jmd0OyA8YnI+Jmd0OyBUaG91Z2h0cz88YnI+Jmd0OyA8 YnI+Jmd0OyBUaGFua3MsPGJyPiZndDsgPGJyPiZndDsgLS1DaHJpczxicj4mZ3Q7IDxicj4mZ3Q7 IENocmlzdG9waGVyIEhhcnJpbmd0b248YnI+Jmd0OyBDb25zdWx0aW5nIFNlY3VyaXR5IEVuZ2lu ZWVyPGJyPiZndDsgR1NPIC0gQ3JpdGljYWwgSW5jaWRlbnQgUmVzcG9uc2UgQ2VudGVyIEVNQyAt IFdoZXJlIEluZm9ybWF0aW9uIExpdmVzPGJyPiZndDsgMTc0IE1pZGRsZXNleCBUdXJucGlrZTxi cj4mZ3Q7IEJlZGZvcmQsIE1BIDAxNzMwPGJyPiZndDsgNzgxLTUxNS01ODYyICh3b3JrKTxicj4m Z3Q7IDYwMy01ODMtMTU4NSAoY2VsbCk8YnI+Jmd0OyA8YnI+Jmd0OyBGcm9tOiA8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNA aWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJodHRw Oi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0 Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiA8YnI+Jmd0OyBPZiBN b3JpYXJ0eSwgS2F0aGxlZW48YnI+Jmd0OyBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAxLCAyMDEz IDExOjI4IEFNPGJyPiZndDsgVG86IE1JTEUgSUVURjxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbbWls ZV0gSU9Dczxicj4mZ3Q7IDxicj4mZ3Q7IEFsbCAtPGJyPiZndDsgPGJyPiZndDsgSSdkIGxpa2Ug eW91ciBpbnB1dCBhbmQgd2lsbCByZWZvY3VzIHRoZSB0aHJlYWQgdG8gZ2V0IG9waW5pb25zIGZy b20gPGJyPiZndDsgdGhlIGxpc3Qgb24gb3B0aW9ucyB0byBoZWxwIHNvbHZlIHRoZSBwcm9ibGVt cyByYWlzZWQgaW4gbXkgbWVzc2FnZSA8YnI+Jmd0OyBhbmQgYWRkaXRpb25hbGx5IGluIFBhdWwn cyBtZXNzYWdlLjxicj4mZ3Q7IDxicj4mZ3Q7IEludGVyZXN0aW5nIHBvaW50LCBDLiBIZW5yeS4m bmJzcDsgT3VyIG9iamVjdGl2ZSBoZXJlIGlzIHRvIGhhdmUgbWFjaGluZSA8YnI+Jmd0OyBhdXRv bWF0ZWQgZXhjaGFuZ2VzLCBzbyB3ZSByZWx5IG9uIGVuY3J5cHRpb24gcmF0aGVyIHRoYW4gb2Jm dXNjYXRpb24gPGJyPiZndDsgdG8gYWNoaWV2ZSB0aGUgbmVjZXNzYXJ5IGxldmVsIG9mIGNvbmZp ZGVudGlhbGl0eS48YnI+Jmd0OyA8YnI+Jmd0OyBQYXVsIG1lbnRpb25lZCB0aGUgbmVlZCB0byBk aXN0aW5ndWlzaCBpbmRpY2F0b3JzIG9mIGNvbXByb21pc2UgZnJvbSA8YnI+Jmd0OyBjb250ZXh0 IGluZm9ybWF0aW9uIHRoYXQgbWF5IGFsc28gaW5jbHVkZSBJUCBhZGRyZXNzIG9yIG90aGVyIGRh dGEgPGJyPiZndDsgdGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzLiZuYnNwOyBUaGUgcXVlc3Rpb24g SSByYWlzZWQgd2FzIG9uIGhvdyB0byBjb25uZWN0IDxicj4mZ3Q7IHNldHMgb2YgaW5kaWNhdG9y cyBpbiB0aGUgc2FtZSBJT0RFRiBkb2N1bWVudCwgYXNzdW1pbmcgdGhlIGFiaWxpdHkgdG8gPGJy PiZndDsgaGF2ZSB3YXRjaGxpc3RzIHRoYXQgY291bGQgaGF2ZSBzZXZlcmFsIHNldHMgb2YgaW5k aWNhdG9ycyBpbmNsdWRlZCwgPGJyPiZndDsgYXMgd2VsbCBhcyB0byBjb25uZWN0IGluZGljYXRv cnMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4gZW1iZWRkZWQgPGJyPiZndDsgc2NoZW1hcy48YnI+ Jmd0OyA8YnI+Jmd0OyBJZiB3ZSBhZGQgYW4gYXR0cmlidXRlIG9uIGFsbCBvZiB0aGUgcmVsZXZh bnQgaW5kaWNhdG9ycywgbGV0J3Mgc2F5IDxicj4mZ3Q7ICdpbmRpY2F0b3ItdWlkJyBob3cgZG8g d2UgbWFyayB0aGUgaW5kaWNhdG9ycz8mbmJzcDsgRG8gd2UgdXNlIHRoaXMgdG8gbWFyayA8YnI+ Jmd0OyB3aG8gc2VudCB0aGUgaW5kaWNhdG9yIGFzIHdlbGwgc28gdGhhdCB3ZSBjYW4gcHJldmVu dCBmb3J3YXJkIHNoYXJpbmcgPGJyPiZndDsgd2hlbiBpdCBpcyBub3QgcGVybWl0dGVkIG9yIGhh bmRsZSB0aGF0IHNlcGFyYXRlbHk/PGJyPiZndDsgPGJyPiZndDsgVGhlbiBmb3IgaW5kaWNhdG9y cyBub3QgaW5jbHVkZWQgaW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IG5vdCBmaXQgPGJyPiZn dDsgaW50byBhIGNhdGVnb3J5IGluIHRoZSBTQ0kgZHJhZnQsIGRvIHdlIGNyZWF0ZSBhIHBsYWNl IGZvciB0aGVzZSBvZmYgPGJyPiZndDsgb2YgU0NJIG9yIHJpZ2h0IG9mZiBvZiB0aGUgSU9ERSBz Y2hlbWEgaW4gRXZlbnREYXRhPyAobW9yZSBkZXRhaWxzIG9uIDxicj4mZ3Q7IHRoaXMgaW4gbXkg Zmlyc3QgbWVzc2FnZSkuPGJyPiZndDsgPGJyPiZndDsgQ29tbWVudHMgYW5kIHF1ZXN0aW9ucyBl bmNvdXJhZ2VkIHRvIGZpZ3VyZSBvdXQgdGhlIHJpZ2h0IHRlY2huaWNhbCA8YnI+Jmd0OyBzb2x1 dGlvbiB0byBoYXZlIHRoaXMgbWFjaGluZSBhdXRvbWF0YWJsZS48YnI+Jmd0OyA8YnI+Jmd0OyBU aGFuayB5b3UsPGJyPiZndDsgS2F0aGxlZW48YnI+Jmd0OyA8YnI+Jmd0OyBGcm9tOiA8YSBocmVm PSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5j ZXNAaWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNA aWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiA8YnI+Jmd0OyBP ZiBDLjxicj4mZ3Q7IEhlbnJ5IEFkYW1zICZhbXA7IEJJRTxicj4mZ3Q7IFNlbnQ6IE1vbmRheSwg SmFudWFyeSAyOCwgMjAxMyAxMToyNSBQTTxicj4mZ3Q7IFRvOiBNSUxFIElFVEY8YnI+Jmd0OyBT dWJqZWN0OiBSZTogW21pbGVdIElPQ3M8YnI+Jmd0OyA8YnI+Jmd0OyBUZW1wb3JhbCBEZXBlbmRl bmN5IHNvdW5kcyBpbnRlcmVzdGluZy4mbmJzcDsgSSByZW1lbWJlciB3aGVuIEkgZmlyc3QgcmFu IDxicj4mZ3Q7IGFjcm9zcyB0aGlzIHBhcnRpY3VsYXIgY3JhZnQsIGFuIGV4cGVyaWVuY2VkIGNv bGxlYWd1ZSBhc2tlZCBtZSBhIDxicj4mZ3Q7IHBlY3VsaWFyIHF1ZXN0aW9uLiZuYnNwOyBIZSBz YWlkLCAmcXVvdDsgSG93IGRvIHlvdSBzdG9wIHNvbWVvbmUgZnJvbSB0cmFja2luZyA8YnI+Jmd0 OyB0aGUgSVAgQWRkcmVzcyB0byB5b3VyIGNvbXB1dGVyPyZxdW90Ozxicj4mZ3Q7IDxicj4mZ3Q7 IEkgcmVwbGllZCwgJnF1b3Q7SSBkb24ndCBrbm93LCBob3c/JnF1b3Q7PGJyPiZndDsgPGJyPiZn dDsgVGhlbiBoZSBzYWlkLCAmcXVvdDtDdXQgdGhlIGRvZy1nb25lIHRoaW5nIG9mZiZuYnNwOyBh bmQgdGhlIG1vZGVtIHRoYXQgaXQgaXM8YnI+Jmd0OyBjb25uZWN0ZWQtIHdoaWNoIGlzIGNvbnN0 YW50bHkgb24hJnF1b3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7TE9MPGJyPiZndDsgPGJyPiZndDsgSGVy ZSdzIG15IHBvaW50IChIeXBvdGhldGljYWwgU2l0dWF0aW9uKSA6Jm5ic3A7IFRoZXJlIGlzIGEg MXN0IFJlc3BvbmRlciA8YnI+Jmd0OyBzZWFyY2hpbmcgYSBOZWlnaGJvcmhvb2QgZm9yIFN1cnZp dm9ycyB3aGljaCB3ZXJlIGhpdCBieSBhIERpc2FzdGVyIG9yIDxicj4mZ3Q7IGxldCdzIGp1c3Qg c2F5ICZxdW90O0xpdmUmcXVvdDsgVGVycm9yaXN0IFNpdHVhdGlvbi4mbmJzcDsgSGUgL29yIFNo ZSBuZWVkcyB0byA8YnI+Jmd0OyBjb21tdW5pY2F0aW9uIGJhY2sgdG8gb3RoZXIgT2ZmaWNpYWxz IHRoYXQgaGUgL29yIHNvbWVob3cgaXMgaW4gPGJyPiZndDsgRGFuZ2VyLiZuYnNwOyBUaGUgZGV2 aWNlIHVzZWQgdG8gY29tbXVuaWNhdGUgaGFzIGJlZW4gY2FwdHVyZWQgYnkgdGhlIGdyZWF0IDxi cj4mZ3Q7IG1pbmRzIG9mIHRoZSBlbmVteS4mbmJzcDsgSXQncyBvbmx5IGEgbWF0dGVyIG9mIHRp bWUgYmVmb3JlIHRoZXkgdXRpbGl6ZSA8YnI+Jmd0OyByZXZlcnNlIGVuZ2luZWVyaW5nIHRvIGZp Z3VyZSBvdXQgaG93IGl0IGZ1bmN0aW9ucy4mbmJzcDsgSG93ZXZlciwgdGhlaXIgPGJyPiZndDsg cHJpZGUgY29tZXMgYmVmb3JlIGEgZmFsbCB3aGVuIHNlZWtpbmcgdGhlIGxvY2F0aW9uIG9mIG90 aGVyIHNpbWlsYXIgPGJyPiZndDsgZGV2aWNlcyB0byBhdHRhY2suJm5ic3A7IFdoeT8gUGVyaGFw cyB0aGUgbGVzcyB0aG91Z2h0IG9mIGNvbmNlcHRzIHRoYXQgPGJyPiZndDsgbWFrZXMgdGhlIGRl dmljZSBmdW5jdGlvbiBwcm9wZXJseSwgc2F2ZXMgdGhlIGRheSBieSBkaXNndWlzZSBvciA8YnI+ Jmd0OyBjdXR0aW5nIGl0IG9mZiAoZmlndXJhdGl2ZWx5IHNwZWFraW5nKS48YnI+Jmd0OyA8YnI+ Jmd0OyBKdXN0IGEgdmlzaW9uYXJ5IHRob3VnaHQuPGJyPiZndDsgPGJyPiZndDsgQy4gSGVucnkg QWRhbXM8YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMv Y29tcG9zZT90bz1jaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbSI+Y2hlbnJ5YWRhbXNAYmll bWVkaWFncm91cC5jb208L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cDovL2JpZW1lZGlhZ3JvdXAu Y29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2JpZW1lZGlhZ3JvdXAuY29tPC9hPjxicj4mZ3Q7 IDxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgPGJyPiZndDsgb3JpZ2luYWwgcmVjaXBpZW50LiBU aGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgPGJyPiZndDsgZGlzdHJpYnV0 aW9uIHdpdGhpbiB0aGUgcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5n IDxicj4mZ3Q7IHB1cnBvc2VzIG9ubHkuIEZ1cnRoZXIgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBw cml2YXRlIG9yIHB1YmxpYyBpcyA8YnI+Jmd0OyBwcm9oaWJpdGVkLjxicj4mZ3Q7IDxicj4mZ3Q7 IC0tLSBPbiBNb24sIDEvMjgvMTMsIERhdmUgTWlzZWxsICZsdDs8YSBocmVmPSJodHRwOi8vdXMu bWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1kYXZpZC5taXNlbGxAYmNzLm9yZyI+ ZGF2aWQubWlzZWxsQGJjcy5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0OyA8YnI+Jmd0OyBGcm9t OiBEYXZlIE1pc2VsbCAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89ZGF2aWQubWlzZWxsQGJjcy5vcmciPmRhdmlkLm1pc2VsbEBiY3Mub3Jn PC9hPiZndDs8YnI+Jmd0OyBTdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8YnI+Jmd0OyBUbzogJnF1 b3Q7Qy4gSGVucnkgQWRhbXMgJmFtcDsgQklFJnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMu bWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20i PmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvYT4mZ3Q7PGJyPiZndDsgRGF0ZTogTW9uZGF5LCBKYW51 YXJ5IDI4LCAyMDEzLCA5OjI1IFBNIFVJRCBjb3VsZCBiZSBtaXJyb3JlZCB3aXRoIEROUyA8YnI+ Jmd0OyBTRUMgYSBwZW1hbmVudCBhbmQgdGVtcG9yYWwga2V5LCB3aXRoIGEgdGVtcG9yYWwgSWQ/ PGJyPiZndDsgPGJyPiZndDsgWW91cnMgRmFpdGhmdWxseSw8YnI+Jmd0OyA8YnI+Jmd0OyBEYXZl IE1pc2VsbCBNU2MgQ0lTU1A8YnI+Jmd0OyBTaWxlbnRDaXJjbGUmbmJzcDsgZHNtPGJyPiZndDsg MDc3MTAgMzgwMDQ0PGJyPiZndDsgPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28u Y29tL21jL2NvbXBvc2U/dG89ZGF2aWQubWlzZWxsQGJjcy5vcmciPmRhdmlkLm1pc2VsbEBiY3Mu b3JnPC9hPjxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDI5IEphbiAyMDEzLCBhdCAwMDoz OSwgQy4gSGVucnkgQWRhbXMgJmFtcDsgQklFICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20iPmNoYXRs Z2EyMDAwQHlhaG9vLmNvbTwvYT4mZ3Q7PGJyPiZndDsgd3JvdGU6PGJyPiZndDsgPGJyPiZndDsg Jmd0OyBTZXJpYWxpemF0aW9uIG9mIGEgcGFydGljdWxhciBMaXN0cyBvZiBYTUwgQ2xhc3NlcyBp biBhIHVuaXF1ZSB3YXkgPGJyPiZndDsgJmd0OyB3YXM8YnI+Jmd0OyBjbG9zZWx5IHJlbGF0ZWQg dG8gd2hhdCBJIGF0dGVtcHRlZCB0byBleHByZXNzIHdoZW4gSSBzdGF0ZWQsIDxicj4mZ3Q7ICZx dW90O2NvbnNpZGVyIHRvIGEgZGVncmVlIHdoYXQgYXBwZWFycyB0byBiZSBpbGxvZ2ljYWwgaW4g YnJpbGxpYW50IG1pbmRzIDxicj4mZ3Q7IGluIHNvbWUgaW5zdGFuY2VzLiZxdW90Ozxicj4mZ3Q7 ICZndDs8YnI+Jmd0OyAmZ3Q7IEhvd2V2ZXIsIEkgc2VlIERyLiBTdG9lY2tlcidzIHBvaW50IGEg bGl0dGxlIGNsZWFyZXIuJm5ic3A7IEhvd2V2ZXIsIGl0IDxicj4mZ3Q7ICZndDsgd291bGQ8YnI+ Jmd0OyBiZSBuaWNlIGlmIHRoZSBVSUQgd2FzIGluIHNvbWUgd2F5IGRpc2d1aXNlZCBmcm9tIHRo b3NlIHdobyBzdHVkeSB0aGlzIDxicj4mZ3Q7IFNlY3VyaXR5IEFydCBGb3JtIGluIGEgbmVnYXRp dmUgd2F5Ljxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEMuIEhlbnJ5IEFkYW1zPGJyPiZndDsg Jmd0OyA8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90 bz1jaGF0bGdhMjAwMEB5YWhvby5jb20iPmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvYT4gKERpcmVj dCBFbWFpbCkgPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBv c2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20iPmNoZW5yeWFkYW1zQGJpZW1lZGlh Z3JvdXAuY29tPC9hPjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlPGJyPiZndDsgJmd0OyBvcmlnaW5hbDxicj4mZ3Q7IHJlY2lwaWVudC4gVGhpcyBpbmZvcm1h dGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW48YnI+Jmd0OyB0 aGU8YnI+Jmd0OyByZWNpcGllbnQncyBwbGFjZSBvZiBidXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVy cG9zZXMgb25seS4gRnVydGhlcjxicj4mZ3Q7IGRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0 ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBSZTog W21pbGVdIElPQ3M8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBTdW5kYXksIEphbnVhcnkgMjcs IDIwMTMgODo1MiBQTTxicj4mZ3Q7ICZndDsgRnJvbTo8YnI+Jmd0OyAmZ3Q7ICZxdW90O1N0b2Vj a2VyLCBQYXVsJnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5j b20vbWMvY29tcG9zZT90bz1QYXVsLlN0b2Vja2VyQHJzYS5jb20iPlBhdWwuU3RvZWNrZXJAcnNh LmNvbTwvYT4mZ3Q7PGJyPiZndDsgJmd0OyBUbzo8YnI+Jmd0OyAmZ3Q7ICZxdW90OzxhIGhyZWY9 Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5v cmciPm1pbGVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnIj5taWxlQGlldGYub3Jn PC9hPiZndDs8YnI+Jmd0OyAmZ3Q7IEkgd291bGQgbGlrZSB0byBsb29rIGF0IHRoaXMgZnJvbSBh IHNsaWdodGx5IGRpZmZlcmVudDxicj4mZ3Q7ICZndDsgcGVyc3BlY3RpdmXFoGxldCdzIHNheSBJ IGdldCBhbiBYTUwgZG9jdW1lbnQgdGhhdCB0ZWxscyBtZSBhYm91dCBhbjxicj4mZ3Q7ICZndDsg aW5jaWRlbnQuJm5ic3A7IFRoaXMgZG9jdW1lbnQgaGFzIHNvdXJjZSBJUCBhbmQgZGVzdGluYXRp b24gSVAgdGhhdCBpczxicj4mZ3Q7ICZndDsgYmVpbmcgc2hhcmVkLiZuYnNwOyBIb3dldmVyLCB3 aGF0IEkgZG9uJ3Qga25vdyBpcyB3aGljaCBJUCBhZGRyZXNzIGlzIG15PGJyPiZndDsgJmd0OyBp bmRpY2F0b3IgYW5kIHdoaWNoIGlzIGp1c3QgYSBjb250ZXh0dWFsIHBpZWNlIG9mIGluZm9ybWF0 aW9uLiZuYnNwOyBUaGlzPGJyPiZndDsgJmd0OyBtZWFucyB0aGF0IG15IGRldGVjdGlvbiBwcm9k dWN0IGlzbid0IGdvaW5nIHRvIGtub3cgd2hpY2ggb25lIHRvIHVzZTxicj4mZ3Q7ICZndDsgZWl0 aGVyLCBiZWNhdXNlIHRoZXJlIGlzIG5vdGhpbmcgdG8gdGVsbCBtZSB3aGljaCBJUCBpcyB0aGUg b25lLCBldmVuPGJyPiZndDsgJmd0OyBpZiB0aGUgcm9sZXMgYXJlIHNldCBpdCBzdGlsbCBtaWdo dCBub3QgYmUgZW5vdWdoIHRvIHRlbGwgbXkgc3lzdGVtPGJyPiZndDsgd2hpY2g8YnI+Jmd0OyBv bmUgSSBzaG91bGQgdXNlIGFzIHRoZSBpbmRpY2F0b3IuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDsgSWYgd2UgaGFkIHNvbWV0aGluZyBsaWtlIGluZGljYXRvcl9pZCBhcyBhbiBhdHRyaWJ1dGUs IGl0IHdvdWxkIGFsbG93PGJyPiZndDsgJmd0OyB1cyB0byBlYXNpbHkgaWRlbnRpZnkgaW5kaWNh dG9ycyBmcm9tIGNvbnRleHR1YWwgZGF0YS4mbmJzcDsgSSBkbyBhZG1pdCB0bzxicj4mZ3Q7ICZn dDsgYmVpbmcgYmlhc2VkIGFzIEkgaGF2ZSBzcGVudCBtdWNoIG9mIG15IGNhcmVlciB3b3JraW5n IG9uIHRoZTxicj4mZ3Q7ICZndDsgbW9uaXRvcmluZyBhbmQgZGV0ZWN0aW9uIHNpZGUgb2YgdGhl c2UgdGhpbmdzLCBzbyBJIGFtIGp1c3QgdGhpbmtpbmc8YnI+Jmd0OyAmZ3Q7IG9mIHdheXMgdG8g bWFrZSBpdCB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGluZGljYXRvcnMgYXJlIGluIHRoZSBYTUw8YnI+ Jmd0OyAmZ3Q7IGRvY3VtZW50IGFuZCB0aGUgb3RoZXIgZGF0YSB0aGF0IG1heSBiZSBpbXBvcnRh bnQgYXMgSSBpbnZlc3RpZ2F0ZTxicj4mZ3Q7ICZndDsgYWN0aXZpdHkgdGhhdCBJIGhhdmUgZGV0 ZWN0ZWQgb2ZmIG9mIHRob3NlIGluZGljYXRvcnMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8 YnI+Jmd0OyAmZ3Q7IEkgZGlkIHN1Z2dlc3QgdGhlIGRldGVjdGlvbiBjbGFzcywgYnV0IEkgdGhp bmsgd2UgbWF5IGdldCBtb3JlPGJyPiZndDsgJmd0OyBmbGV4aWJpbGl0eSB3aXRoIHRoZSBpbmRp Y2F0b3JfdWlkLiZuYnNwOyBPbmUgdGhpbmcgdGhhdCBJIGhhdmVuJ3Q8YnI+Jmd0OyAmZ3Q7IGNv bnNpZGVyZWQgaXMgdGhlIFVJRCBwb3J0aW9uIG9mIHRoaXPFoGhvdyBkbyB3ZSB1c2UgdGhhdCBV SUQ/Jm5ic3A7IEhvdyBpczxicj4mZ3Q7ICZndDsgdGhlIFVJRCBjcmVhdGVkPyZuYnNwOyBBcmUg dGhlcmUgc3RhbmRhcmRzIGZvciBVSURzPzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFJlZ2Fy ZHMsPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgUGF1bDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgUGF1bCBXLiBTdG9lY2tlciwgUGguRC48YnI+ Jmd0OyAmZ3Q7IFNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0PGJyPiZndDsgJmd0OyBSU0EsIFRo ZSBTZWN1cml0eSBEaXZpc2lvbiBvZiBFTUM8YnI+Jmd0OyAmZ3Q7IGNlbGw6IDMwMi4zNzkuMzM3 NSB8IGU6IDxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3Nl P3RvPXBhdWwuc3RvZWNrZXJAcnNhLmNvbSI+cGF1bC5zdG9lY2tlckByc2EuY29tPC9hPjxicj4m Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IC0tLSBPbiBTYXQsIDEvMjYvMTMsIEMuIEhlbnJ5IEFkYW1z ICZhbXA7IEJJRSAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tIj5jaGF0bGdhMjAwMEB5YWhvby5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBGcm9tOiBDLiBIZW5yeSBB ZGFtcyAmYW1wOyBCSUUgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNv bS9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbSI+Y2hhdGxnYTIwMDBAeWFob28u Y29tPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dczxicj4mZ3Q7 ICZndDsgVG86ICZxdW90O0thdGhsZWVuTW9yaWFydHkmcXVvdDsgJmx0OzxhIGhyZWY9Imh0dHA6 Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5 QGVtYy5jb20iPmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb208L2E+Jmd0Ozxicj4mZ3Q7ICZndDsg Q2M6IDxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3Rv PW1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+PGJyPiZndDsgJmd0OyBEYXRlOiBTYXR1 cmRheSwgSmFudWFyeSAyNiwgMjAxMywgNjoxNyBQTTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 IEdyZWV0aW5ncyBLYXRobGVlbiw8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBZb3VyIGxvZ2lj IHN0aW11bGF0ZXMgbXkgdmlzaW9uYXJ5IGJyYWluIGJlY2F1c2UgSSdtIGFtYXplZCBhdCB0aGU8 YnI+Jmd0OyAmZ3Q7IG1hbnk8YnI+Jmd0OyBhdmVudWVzIHlvdSByZXZpZXcgd2l0aCB0aGlzIGFw cHJvYWNoIGF0IG9uY2UuJm5ic3A7IEhvd2V2ZXIsJm5ic3A7IGNvdWxkIHlvdSBzaGFyZTxicj4m Z3Q7IGE8YnI+Jmd0OyBmZXcgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyB0byB0aGUgbGF0 dGVyPzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0 OyAtLS0tLS0tLTxicj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+Jmd0OyAmZ3Q7ICZxdW90O3dlIGNvdWxkIGNvbnRpbnVlIHRvIGdyb3VwIGl0 ZW1zIGluIGxvZ2ljYWwgcGxhY2VzIGFzIGlzIGRvbmUgbm93IGluPGJyPiZndDsgSU9ERUYgYW5k IHRoZW4gaGF2ZSB0aGUgZXh0ZW5zaW9uIHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZp YSBTQ0kuJnF1b3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4mZ3Q7IC0tLS0tLS0tPGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgWW91IHBvaW50ZWQgb3V0 IHdoYXQgeW91IGNvbnNpZGVyIHRvIGJlIGxvZ2ljYWwgcGxhY2VzLCBidXQgaWYgSTxicj4mZ3Q7 ICZndDsgd2FudGVkIHRvPGJyPiZndDsgcHJvdGVjdCBpbmZvcm1hdGlvbiBmcm9tIHBhcnRpZXMg Y2FwYWJsZSBvZiBhc2NlcnRhaW5pbmcgaXQgZnJvbSB5b3VyPGJyPiZndDsgbG9naWNhbCBwbGFj ZXMsIHBlcmhhcHMgd2Ugc2hvdWxkIGFsc28gY29uc2lkZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBl YXJzPGJyPiZndDsgdG88YnI+Jmd0OyBiZSBpbGxvZ2ljYWwgaW4gYnJpbGxpYW50IG1pbmRzIGlu IHNvbWUgaW5zdGFuY2VzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxi cj4mZ3Q7ICZndDsgQy4gSGVucnkgQWRhbXM8YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly91 cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNv bSI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPiAoRGlyZWN0IEVtYWlsKTxicj4mZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hl bnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20iPmNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29t PC9hPjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGU8YnI+Jmd0OyAmZ3Q7IG9yaWdp bmFsPGJyPiZndDsgcmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxp bWl0ZWQgZGlzdHJpYnV0aW9uIHdpdGhpbjxicj4mZ3Q7IHRoZTxicj4mZ3Q7IHJlY2lwaWVudCdz IHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyPGJy PiZndDsgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBwcml2YXRlIG9yIHB1YmxpYyBpcyBwcm9oaWJp dGVkLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IC0tLSBPbiBTYXQsIDEvMjYvMTMsIE1vcmlh cnR5LCBLYXRobGVlbiAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSI+a2F0aGxlZW4ubW9yaWFy dHlAZW1jLmNvbTwvYT4mZ3Q7PGJyPiZndDsgd3JvdGU6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDsgRnJvbTogTW9yaWFydHksIEthdGhsZWVuICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tIj5r YXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJF OiBbbWlsZV0gSU9Dczxicj4mZ3Q7ICZndDsgVG86ICZxdW90O0MuIEhlbnJ5IEFkYW1zICZhbXA7 IEJJRSZxdW90OyAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tIj5jaGF0bGdhMjAwMEB5YWhvby5jb208 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mcXVvdDs8YnI+Jmd0 OyAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPiZndDsgJmd0OyBEYXRl OiBTYXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMywgMTA6MTMgQU08YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBIZWxsbyBDLiBIZW5yeSAmYW1wOyBvdGhlcnMsPGJyPiZndDsgJmd0Ozxicj4mZ3Q7 ICZndDsgVGhhbmtzIGZvciB0YWtpbmcgYSBsb29rIGF0IHRoaXMuJm5ic3A7IFdlIGhhdmUgYSBm ZXcgY29uc2lkZXJhdGlvbnMgaW48YnI+Jmd0OyAmZ3Q7IHRoaXM8YnI+Jmd0OyBlbWFpbCB0aHJl YWQgSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhvdWdodHMgb24gKGFuZCB0aGVyZSBtYXkgYmUgbW9y ZSBvbmNlPGJyPiZndDsgUkZDNTA3MC1iaXMgaXMgYWN0aXZlbHkgZWRpdGVkKS48YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBUaGUgQWRkaXRpb25hbERhdGEgY2xhc3MgYW5kIHRoZSBSZWNvcmRJ dGVtIGNsYXNzIGJvdGggYWxsb3cgZm9yPGJyPiZndDsgJmd0OyBub24tWE1MPGJyPiZndDsgZXh0 ZW5zaW9ucy4mbmJzcDsgV2hlcmUgeW91IHBsYWNlIHRoZSBleHRlbnNpb25zIHNob3VsZCBiZSBz cGVjaWZpYyB0byB0aGU8YnI+Jmd0OyBsb2dpY2FsIGdyb3VwaW5nIG9mIHRoZSBwYXJlbnQgZWxl bWVudHMgc28geW91IGNhbiB1bmRlcnN0YW5kIG1vcmUgYWJvdXQ8YnI+Jmd0OyB0aGU8YnI+Jmd0 OyBpbmNsdWRlZCBkYXRhIGluIG1vc3QgY2FzZXMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsg VGhlIEltcGFjdCBjbGFzcyBjYW4gYmUgdXNlZCB0byBwcm92aWRlIGNvbnRleHQgaW5mb3JtYXRp b24gb24gdGhlPGJyPiZndDsgaW5jbHVkZWQgZGF0YSBvZiB0aGUgcmVwb3J0IGFuZCBhbHNvIGNh biBpbmNsdWRlIGEgY29uZmlkZW5jZSByYXRpbmcgb248YnI+Jmd0OyB0aGU8YnI+Jmd0OyByZXBv cnQgYXMgYSB3aG9sZS4mbmJzcDsgRXh0ZW5zaW9ucyByZWxhdGVkIHRvIGltcGFjdCB3b3VsZCBi ZSBvbmUgbGV2ZWwgaGlnaGVyPGJyPiZndDsgKGF0IHRoZSBtb21lbnQpIGluIHRoZSBBc3Nlc3Nt ZW50IGNsYXNzIHVzaW5nIHRoZSBBZGRpdGlvbmFsRGF0YSBleHRlbnNpb248YnI+Jmd0OyBwb2lu dC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUYWtlIGFza2VkIGFib3V0IGluY2x1ZGluZyB2 dWxuZXJhYmlsaXR5IGluZm9ybWF0aW9uLCBJIHdvdWxkIHRoaW5rPGJyPiZndDsgJmd0OyB0aGF0 PGJyPiZndDsgd291bGQgZml0IHVuZGVyIHRoZSBWdWxuZXJhYmlsaXR5IGV4dGVuc2lvbiBwb2lu dCBvZiB0aGUgU0NJIGRyYWZ0IGluPGJyPiZndDsgdGhlPGJyPiZndDsgTWV0aG9kIGNsYXNzLiZu YnNwOyBIZSBkaWQgYXNrIGFib3V0IG5vbi1YTUwuJm5ic3A7IFJlY29yZEl0ZW0gb3IgQWRkaXRp b25hbERhdGE8YnI+Jmd0OyBkbzxicj4mZ3Q7IGFsbG93IGZvciBub24tWE1MIGV4dGVuc2lvbiBw b2ludHMsIHdlIGNvdWxkIGVpdGhlciBoYXZlIHRoZSBTQ0kgZHJhZnQ8YnI+Jmd0OyBoYW5kbGUg dGhlc2UgYXMgd2VsbCBvciBoYXZlIHRoZSBleHRlbnNpb25zIHRoYXQgYXJlIG5vbi1YTUwgY29t ZSBkaXJlY3RseTxicj4mZ3Q7IG9mZiB0aGUgQWRkaXRpb25hbERhdGEgb3IgUmVjb3JkSXRlbSBj bGFzc2VzIGFjY29yZGluZyB0byB3aGF0IG1ha2VzIHNlbnNlPGJyPiZndDsgZnJvbSBhIGxvZ2lj YWwgc3RhbmRwb2ludC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBBcyBmb3IgbXkgcXVlc3Rp b24sIGl0IHdhcyB0d28tZm9sZC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBJbmRpY2F0b3Ig YmFzZWQgc2NoZW1hcyBoYXZlIGEgcmVmZXJlbmNlIG51bWJlciBvciBhIEdVSUQgZm9yIHRoZTxi cj4mZ3Q7ICZndDsgdmFyaW91czxicj4mZ3Q7IGluZGljYXRvcnMgdGhleSBzaGFyZS4mbmJzcDsg SWYgd2UgYXJlIGV4dGVuZGluZyB0byBlbWJlZCBvdGhlciBzY2hlbWFzIHRoYXQ8YnI+Jmd0OyBp bmNsdWRlIHN1Y2ggcmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMsIGRvIHdlIHdhbnQgdG8g YWRkIGFuIGF0dHJpYnV0ZTxicj4mZ3Q7IHRvIHRoZSB2YXJpb3VzIGVsZW1lbnRzIGluIElPREVG IHRoYXQgY291bGQgYmUgaW5kaWNhdG9ycz8mbmJzcDsgSXMgdGhpcyBlbm91Z2g8YnI+Jmd0OyB0 byBtYWtlIHRoZSBjb25uZWN0aW9ucyBvciBpcyBzb21ldGhpbmcgZWxzZSBlbHNlIG5lZWRlZD8m bmJzcDsgV2UgY291bGQgYWRkPGJyPiZndDsgc29tZXRoaW5nIGxpa2UgYW4gSW5kaWNhdG9yX0lE IGluIFJGQzUwNzAtYmlzIHdoaWNoIHdvdWxkIHRoZW4gY29ycmVsYXRlPGJyPiZndDsgdG88YnI+ Jmd0OyB0aGUgcmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMuPGJyPiZndDsgJmd0Ozxicj4m Z3Q7ICZndDsgVGhlbiB0aGUgb3RoZXIgcXVlc3Rpb24gd2FzIG9uIGhvdyB0byBpbmNsdWRlIGlu ZGljYXRvcnMgdGhhdCBhcmUgbm90PGJyPiZndDsgJmd0OyBpbjxicj4mZ3Q7IHRoZSBiYXNlIHNj aGVtYSB0aGF0IG1heSBiZSByZWxhdGVkIG9yIGhhdmUgbGFuZ3VhZ2Ugd2l0aCAmcXVvdDthbmQm cXVvdDsgJnF1b3Q7b3ImcXVvdDsgdG88YnI+Jmd0OyBzcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXBz LiZuYnNwOyBJbiBzb21lIGNhc2VzLCB5b3Ugd2lsbCB3YW50IHRvIGdyb3VwIHRoZXNlPGJyPiZn dDsgaW5kaWN0b3JzIGluIG9uZSBleHRlbnNpb24gcG9pbnQsIHdoZXJlIHRoZXkgbWF5IGZpdCBs b2dpY2FsbHkgaW4gbXVsdGlwbGU8YnI+Jmd0OyBwbGFjZXMgaWYgdGhlIHJlbGF0aW9uc2hpcHMg ZGlkIG5vdCBuZWVkIHRvIGJlIHNob3duIGluIHRoZSBkYXRhPGJyPiZndDsgZm9ybWF0LiZuYnNw OyBJZjxicj4mZ3Q7IHdlIGhhdmUgY2FzZXMgbGlrZSB0aGlzIHdoZXJlIHlvdSBuZWVkIG1vcmUg Y29tcGxleCByZXByZXNlbnRhdGlvbnMsPGJyPiZndDsgc2hvdWxkPGJyPiZndDsgd2UgdXNlIG9u ZSBleHRlbnNpb24gcG9pbnQgdmlhIHRoZSBTQ0kgZHJhZnQgb2ZmIG9mIHRoZSBFdmVudERhdGEg Y2xhc3M8YnI+Jmd0OyBBZGRpdGlvbmFsRGF0YSBleHRlbnNpb24gcG9pbnQ/Jm5ic3A7IE9waW5p b25zIGFyZSBuZWVkZWQgaGVyZS4uLi48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBBIGZldyBw ZW9wbGUgaGF2ZSBtZW50aW9uZWQgd2FudGluZyB0byBpbmNsdWRlIHNvbWUgY29tbW9ubHkgc2hh cmVkPGJyPiZndDsgaW5kaWN0b3JzIGludG8gdGhlIGJhc2UgSU9ERUYgZG9jdW1lbnQuJm5ic3A7 IFdlIGNvdWxkIGhhdmUgYSBjYXRjaC1hbGwgY2xhc3M8YnI+Jmd0OyB0aGF0IGRvZXMgdGhpcyBh bmQgaGFzIGFuIGV4dGVuc2lvbiBwb2ludCBvZmYgb2YgaXQgaW4gRXZlbnREYXRhIG9yIHdlPGJy PiZndDsgY291bGQ8YnI+Jmd0OyBjb250aW51ZSB0byBncm91cCBpdGVtcyBpbiBsb2dpY2FsIHBs YWNlcyBhcyBpcyBkb25lIG5vdyBpbiBJT0RFRiBhbmQ8YnI+Jmd0OyB0aGVuPGJyPiZndDsgaGF2 ZSB0aGUgZXh0ZW5zaW9uIHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZpYSBTQ0kuJm5i c3A7IEkgdGhpbmsgSSBsaWtlPGJyPiZndDsgdGhlIGxhdHRlciBhcHByb2FjaC48YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBUaGFuayB5b3UsPGJyPiZndDsgJmd0OyBLYXRobGVlbjxicj4mZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7ICZn dDsgRnJvbTogPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBv c2U/dG89bWlsZS1ib3VuY2VzQGlldGYub3JnIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8 YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxl LWJvdW5jZXNAaWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBDLjxicj4mZ3Q7ICZndDsgSGVucnk8YnI+Jmd0OyBBZGFtcyAmYW1wOyBCSUUgWzxhIGhyZWY9 Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAw QHlhaG9vLmNvbSI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPl08YnI+Jmd0OyAmZ3Q7IFNlbnQ6 IFNhdHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzIDM6MDUgQU08YnI+Jmd0OyAmZ3Q7IFRvOiA8YSBo cmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGll dGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxicj4mZ3Q7ICZndDsgQ2M6IEMuIEhlbnJ5IEFkYW1z PGJyPiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBHcmVldGluZ3MgRXZlcnlvbmUsPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGFr ZSBtZW50aW9uZWQgdHdvIHR5cGVzIG9mIGluZGljYXRvcnMgYmFzZWQgb24gdGhlIDo8YnI+Jmd0 OyAmZ3Q7PGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAtLS0tLS0tLTxicj4mZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgJmd0OyAxKSBJZiB0aGUgaW5kaWNhdG9ycyBh cmUgc29tZXRoaW5nIGxpa2UgYW4gWE1MLWJhc2VkIGFsZXJ0L3dhcm5pbmcgb2Y8YnI+Jmd0OyAm Z3Q7IGluZm9ybWF0aW9uIGxlYWthZ2UsIGl0IGNvdWxkIGJlIGFuIGV2ZW50IHRoYXQgYXJlIGNv bnZleWVkIGluIHRoZTxicj4mZ3Q7ICZndDsgU0NJJ3MgRXZlbnRSZXBvcnQgY2xhc3MsIElNSE8u PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgMikgSWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0 aGluZyBsaWtlIGFuIG5vbi1YTUwgb25lcywgSSBndWVzcyBpdDxicj4mZ3Q7ICZndDsgY291bGQ8 YnI+Jmd0OyBiZTxicj4mZ3Q7ICZndDsgY29udmV5ZWQgd2l0aG91dCB1c2luZyBTQ0kgZHJhZnQu PGJyPiZndDsgJmd0OyBGb3IgaW5zdGFuY2UsIHdlIGNvdWxkIHVzZSBJbXBhY3QgY2xhc3Mgb2Yg dGhlIGJhc2UgSU9ERUYgdG8gY29udmV5PGJyPiZndDsgJmd0OyB0aGUgaW5kaWNhdG9ycy48YnI+ Jmd0OyAmZ3Q7IFdlIGNvdWxkIGZvciBpbnN0YW5jZSBleHRlbmQgdGhlIGxpc3Qgb2YgaW5kaWNh dG9ycyBvZiB0aGUgSW1wYWN0PGJyPiZndDsgJmd0OyBjbGFzcyw8YnI+Jmd0OyBpZjxicj4mZ3Q7 ICZndDsgbmVlZGVkLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IC0t LS0tLS0tPGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0OyBJbiBkb2luZyBzbyBoZSBwb2ludGVkIG91dCB0aGUgJnF1b3Q7SW1wYWN0IENs YXNzJnF1b3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgV2hlcmVhcywgS2F0aGxlZW4gc3Rh dGVkLDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0 OyAtLS0tLS0tLTxicj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7 IEZvciB0aGUgZGlzY3Vzc2lvbiBiZWxvdywgSSB3YXMgdGhpbmtpbmcgbW9yZSBvZiBjb21iaW5l ZCBzZXQgd2l0aDxicj4mZ3Q7IHJlbGF0aW9uc2hpcHMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4g YSBzaW5nbGUgZXh0ZW5zaW9uIHBvaW50LCBzbyB0aGF0J3M8YnI+Jmd0OyB3aHkgSSB3YXMgdGhp bmtpbmcgYWJvdXQgdGhlIEV2ZW50RGF0YSBjbGFzcywgYnV0IHRoZXJlIG1heSBiZSBiZXR0ZXI8 YnI+Jmd0OyBsb2NhdGlvbnMgb3IgYSBzcGVjaWZpYyBhcmVhIHdpdGhpbiB0aGUgRXZlbnREYXRh Ljxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFBhdWwgU3RvZWNrZXIgaGFkIHN1Z2dlc3RlZCBh ICZxdW90O0RldGVjdGlvbiZxdW90OyBjbGFzcyBhcyBhIGNvbnNpZGVyYXRpb24uPGJyPiZndDsg Jmd0Ozxicj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgLS0tLS0tLS08YnI+Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBLYXRobGVlbiB0aG91 Z2h0cyByZWxhdGVkIHlldCBzdGlsbCB3aXRoIG90aGVyIGluZGljYXRvcnMgYW5kIHRoZTxicj4m Z3Q7IEV2ZW50RGF0YSBDbGFzcy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBJcyB0aGVyZSBh IHBvc3NpYmxlIHdheSB0byBjcmVhdGUgYSBuZXcgWE1MIGNsYXNzIHdoaWNoIGVuY29tcGFzczxi cj4mZ3Q7IGNvbWJpbmluZyB0aGUgRXZlbnREYXRhLCBEZXRlY3Rpb24gYW5kIGJhc2UgSU9ERUYg Y2xhc3NlcyB0byBzaW1wbGlmeTxicj4mZ3Q7IHRoaXM8YnI+Jmd0OyBpc3N1ZT88YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgQy4gSGVucnkgQWRhbXM8YnI+Jmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNo YXRsZ2EyMDAwQHlhaG9vLmNvbSI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPiAoRGlyZWN0IEVt YWlsKTxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20iPmNoZW5yeWFkYW1z QGJpZW1lZGlhZ3JvdXAuY29tPC9hPjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0OyBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlPGJyPiZndDsgJmd0OyBvcmlnaW5hbDxicj4mZ3Q7IHJlY2lwaWVudC4gVGhp cyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW48 YnI+Jmd0OyB0aGU8YnI+Jmd0OyByZWNpcGllbnQncyBwbGFjZSBvZiBidXNpbmVzcyBmb3IgcGxh bm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlcjxicj4mZ3Q7IGRpc3NlbWluYXRpb24sIHdoZXRo ZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC48YnI+Jmd0OyAmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyBtaWxl IG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48 YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWlsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlsZTwvYT48YnI+Jmd0OyA8YnI+Jmd0OyA8bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+ PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_F5063677821E3B4F81ACFB7905573F24CEBDF152MX15Acorpemccom_-- From chatlga2000@yahoo.com Tue Feb 12 21:50:41 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4500521F8A7B for ; Tue, 12 Feb 2013 21:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_50=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr9b0DVncw-5 for ; Tue, 12 Feb 2013 21:50:37 -0800 (PST) Received: from nm30-vm3.bullet.mail.ne1.yahoo.com (nm30-vm3.bullet.mail.ne1.yahoo.com [98.138.91.160]) by ietfa.amsl.com (Postfix) with ESMTP id 08AA121F8A74 for ; Tue, 12 Feb 2013 21:50:28 -0800 (PST) Received: from [98.138.90.53] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 05:50:27 -0000 Received: from [98.138.87.6] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 05:50:27 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 05:50:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 267776.97240.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 87146 invoked by uid 60001); 13 Feb 2013 05:50:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360734627; bh=63lNrwdwV7af0F9LLzGResFP6kCQ6qTt9BsQFrimEQA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=B4obF52Hbqy6WYT4EsGCeqrbYu8LFdvq9AUjUWoPXear1+IU4e3iT1Pb9OCzzbyJDHDvoAE0MfYIPdFzvQfwOreUM+lbU0ulDfPrQmvBxXbM8Lgj4HWhmsHre/5KiR3OjEbop2tMW4ZErh9T5mJ4C4ThYnHB7sfR0FBw8XVLNqA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=G/TU18nCwxn09xm6y8srVMGRM0yDPSoVo16yUXRum4jb8GHkqPf4pCjICNPEwAkYH/Gvn5GwdqTCoQOuI0MAucpX7h3eqbnSf7sPlmj1E25D7recupHnDe4f2UuHqxfCBQOQ3TUOogN0pkevZ00YlXGPmHCCsWuTkscmHkrArj4=; X-YMail-OSG: 7.swSuEVM1n5qWNLIW8c7bMDLWO5FEugvZn3V3Q4er5V1Qx Cqmx1PRLqvIaVxx83FfnFJ.bQky6IwRfQFzI2Es0k6RkN2MstP79DVveaxaq 6wUPVBRTxeR94Z2kfkCBw4TJUuBr6HIvRKRxPofyBYZAM2dNUlKtvD_4Zlta B5jPLJrIMfDuGK3huzjK1ZF3akd1IPinWvQ8.yw1UC1cTYj.fEi6BpnQqqAk WMTwitkRNy2wzdB4Os1dPiRw2ZeGueQ8RipHZKWC5lFMxAQaGSOB_h.Bb5lS DbeaBKkFQIonGhAqt3vGeYMpVFV5B7yp54HDpdqGwnFuW8JYn1lr8eEJrYBB cfFitJJ7ZwpWqB9UDQZnNeYjJyFC8Gc2jF0ivgKD0j2a6fDRXQ3lgOYfi5kl rFnVRHnkOP5XO1Xcs6rVN62xHN3s.kb74ckvimjbr.OSu5Mt1gLTczjHGtqY vgNxopURCfbjynqkhyuc331.hbh2_TdD5yYcakIEqm5JHpeGxnNYhmIO0if6 U Received: from [71.22.243.36] by web121602.mail.ne1.yahoo.com via HTTP; Tue, 12 Feb 2013 21:50:26 PST X-Rocket-MIMEInfo: 001.001, UkZDNTA3MCBDaGFwdGVyIDMgc2VjdGlvbiAxMCBpdGVtIDQgZG9lcyBub3QgYXBwZWFyIHRvIHJlc3RyaWN0IGNvbmZsYXRpb24gb2YgYSBudW1lcmljIHZhbHVlIGFuZCBpdHMgZGVmaW5pdGlvbi4gSSB3b3VsZCBndWVzcyB0aGF0IHdoYXQgSSdtIHJlYWxseSB0cnlpbmcgdG8gc3RhdGUgaGVyZSBpcyB0aGVyZSBzaG91bGQgcGVyaGFwcyBiZSBhIHNpbXBsZSBzdGFuZGFyZGl6YXRpb24gZXN0YWJsaXNoIGluIGEgc29ydCBvZiBhbiBBbHBoYS1udW1lcmljIHZhbHVlIGlmIHBvc3NpYmxlIGFzIG9wcG9zZSABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.133.508 Message-ID: <1360734626.86450.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Tue, 12 Feb 2013 21:50:26 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2038480821-1994560635-1360734626=:86450" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 05:50:41 -0000 ---2038480821-1994560635-1360734626=:86450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable RFC5070 Chapter 3 section 10 item 4 does not appear to restrict conflation = of a numeric value and its definition. I would guess that what I'm really t= rying to state here is there should perhaps be a simple standardization est= ablish in a sort of an Alpha-numeric value if possible as oppose to a numer= ic value. Please see (Revision) below: ( i.e.=C2=A0 1LL =3D Less Likely, =C2=A0 2P =3D Probable,=C2=A0 3AC =3D A C= oncern,=C2=A0 4U =3D=C2=A0 Urgent,=C2=A0 5I =3D Imminent ) I would concur, perhaps Sharing Groups regarding the IODEF should be given = a survey of some kind to address potential issues with the High, Medium, Lo= w assessment combined with a numeric rating=C2=A0 0 - 100 to possibly revis= it creating a simplified approach. Please=0A see section 3.10.4 of RFC5070 as a starting point.=C2=A0 We can c= hange it if=0A it needs to be changed.=C2=A0 The value is for a confidence = rating on the =0Aindicators shared.=C2=A0 The definitions may be helpful fo= r anyone who wants =0Ato work on this discussion.=C2=A0 IODEF has various m= arkers that can be used =0Ain a complimentary way without conflating the ma= rkers meaning. =C2=A0I=0A think some people using IODEF find the numerical = values more helpful, =0Aand it would be good to understand what people have= learned from using =0Athe current structure (what works/does not work).=C2= =A0 The scales I have =0Aseen are 0-100.=C2=A0 There is of course a subject= ive element to assigning a =0Anumerical value to the confidence and it may = vary from entity to =0Aentity.=C2=A0 With this type of rating you may need = to consider who it came =0Afrom and how they scored the confidence rating t= o map to your own =0Arating.=C2=A0 It would be good to hear more thoughts o= n this.=C2=A0 =C2=A0Thanks,Kathleen =C2=A0From: C. Henry Adams & BIE [mail= to:chatlga2000@yahoo.com]=20 Sent: Tuesday, February 12, 2013 2:46 PM To: MILE IETF Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul Subject: Re: [mile] IOCs =C2=A0 Regarding=0A the IOCs or Indicators of Compromise, Chris made a vital point= .=C2=A0 =0ADifferent Confidence levels will cause confusion.=C2=A0 It appea= rs that there=0A maybe a need for some type of simplified standardization t= o be =0Aestablished between all Sharing Groups in this regard. Perhaps numerical scoring set at lower values should express levels of urge= ncy. ( i.e.=C2=A0 1 =3D Less Likely, =C2=A0 2 =3D Probable,=C2=A0 3 =3D A Concer= n,=C2=A0 4 =3D=C2=A0 Urgent,=C2=A0 5 =3D Imminent ) Thanks, C. Henry Adams I see some confusion coming down the pike if we start using Confidence the way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale o= f 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text.=C2=A0 Makes searching / sorting very problematic.=20 At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point.=20 Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen=20 Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Chris & Take, I'll just focus on the confidence scoring.=C2=A0 Right now, the schema allo= ws for you to either use a numerical score OR the ratings of low, medium, and high= . Different sharing groups can decide how they want to share the data.=C2=A0 = If people were to use the numerical values, I agree it would be helpful to hav= e guidance.=C2=A0 This could go in the IODE guidance document. I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher=20 Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level.=20 Low - I am not sure Medium - I am reasonably sure High - I am very sure=20 Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF= ' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? Thank you. Take > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' > Subject: RE: [mile] IOCs >=20 > With respect to tying things back to threat actors, from what I have=20 > seen and use this is a generally accepted grouping: >=20 > Indicator --> Indictor Set --> Campaign --> Threat Actor >=20 > Campaign and Threat Actor are where having a "Confidence" attribute=20 > would be beneficial as making those associations is not a perfect=20 > science by any means. >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Take & others, >=20 > Thanks for chiming in, I've been talking about this with Chris and a=20 > few others on their use cases and would like more opinions.=C2=A0 I'll=20 > provide an option below from what we have discussed from a CIRC view=20 > point.=C2=A0 We are also wondering how to also provide logic in IODEF tha= t=20 > could cross over into SCI attached schemas or IODEF extensions (the=20 > solutions may all tie together with this discussion - or there may be=20 > better/more elegant solutions others would like to propose). >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE=20 > IETF' > Subject: RE: [mile] IOCs >=20 > > I like this discussion. > > I agree, it would be good idea to have indicator identifiers inside=20 > > the IOC-related classes. >=20 > KMM: At the class level, we may have several indicators listed that=20 > should be viewed as a set and may have another instance of that same=20 > class that is a related issue, but a separate set.=C2=A0 We could as you= =20 > say, list the indicator IDs connected through the reference class.=C2=A0= =20 > The set IDs might give us other ways to group the values when we get=20 > into logic and relationships between sets or indicators.=C2=A0 This could= =20 > also be a way to connect indicators or sets across XML documents that=20 > could have been shared previously.=C2=A0 If there are a large number of= =20 > indicators in the set, then this becomes useful, for smaller sets, I=20 > agree it doesn't make as much sense. >=20 > What do others think? >=20 > >> Then for indicators not included in the base schema that may not=20 > >> fit into a category in the SCI draft, do we create a place for=20 > >> these off of SCI or right off of the IODE schema in EventData?=20 > >> (more details > on > >> this in my first message). > > > > If we could see any indicator of compromise as computer event=20 > > record, we could use SCI:EventReport class as the place for the=20 > > XML-based IOCs that couldn't fit anywhere else. >=20 > KMM: That sounds like a good idea to me.=C2=A0 This should go into guidan= ce=20 > in the SCI draft.=C2=A0 Does anyone else want to weigh in? >=20 > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! >=20 > > I agree to have indicator_uid, but I am not sure about the needs of=20 > > the indicator_set_id. > > I understand we could do some grouping of individual indicator_uids=20 > > and its usability, but I am not sure whether we do not have any=20 > > other way to express these groupings. > > For instance,=C2=A0 a Reference class refers to several indicadtor_uids= . > In > > this case, they could be, in a sense, grouped. Isn't it enough? >=20 > KMM: It may be, what do you think about large sets of indicators or=20 > subsequent messages that add indicators to existing sets?=C2=A0 Would thi= s=20 > happen?=C2=A0 Would it be easier to express relationships with sets of=20 > indicators in addition to individual indicators?=C2=A0 By using this, it= =20 > could give us a unique way to also provide the logic and relationships=20 > in a new class of IODEF so we don't have to worry about adding it into=20 > the current structure. > If there are better ways to handle that, and others can provide some=20 > options, that would be appreciated! >=20 > Thank you, > Kathleen >=20 > > I would appreciate if anybody could share expertise on this. Though > I > > think I have read all the emails in the list, I might have=20 > > mis-understood some points. > > > > By the way, I think the indicator_uids should be added to the SCI classes' > > attributes so that they can be correlated with another information=20 > > as > well. > > > > Thanks > > Take >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs >=20 > I think some sort of group ID would do the trick. We also need a=20 > logical and / or somewhere to show relationship between indicators. If=20 > I give you > 2 > registry keys do they both have to be present to be an indication of=20 > compromise or is either one by themselves an indicator? Both would=20 > have the same group ID since they are related. >=20 > Thanks, > --Chris >=20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs >=20 > What if we added indicator group ID along with the indicator_uid?=C2=A0= =20 > This would allow you to group indicators that are related into the=20 > same group ID. >=C2=A0 Would this resolve the issue? >=20 > It is either that or going back to adding a Detection (or Indicators)=20 > class that will should be used to take all of the indicators put them=20 > into one place and have the ability to group the ones that go=20 > together.=C2=A0 I don't mean a place to put indicators that are missing= =20 > from IODEF.I mean a place in the IODEF document where you put the=20 > indicators that are used for detection and prevention of the shared=20 > Incident.=C2=A0 I don't know the answer here, but there has got to be a= =20 > good way for indicators to be identified and being able to group them=20 > as Chris has suggested without basically recreating something=20 > complicated like STIX. >=20 > Paul >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 >=20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE=20 > IETF > Subject: Re: [mile] IOCs >=20 > Hi Chris, >=20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. >=20 > The list has already said they would like to see indicators added to=20 > the definitions in RFC5070-bis, to be more explicit about including=20 > indicators and sets of indicators in IODE documents as opposed to=20 > 'parts of an incident or the useful information on an incident for=20 > sharing purposes.=C2=A0 It was written before we used terms like=20 > indicators.=C2=A0 With that in mind, Rosella proposed a number of changes= =20 > back in July, both for guidance and for format > updates.=C2=A0 It may help to have the first draft try to address at leas= t=20 > some of these issues so people can understand the problems and at=20 > least a proposed solution. >=20 > As you point out, we need to be able to show relationships between=20 > sets of indicators, where we may have a few sets of indicators that=20 > could have a relationship to each other within a document.=C2=A0 In the= =20 > July presentation, one of the questions was to see if we should add=20 > new category attribute values for the System class that would connect=20 > the list of included indicators.=C2=A0 I think we should still keep the= =20 > concept of a Node to a single node, but perhaps within System, list=20 > multiple sets of Nodes that may be one type of attack.=C2=A0 Rosella had= =20 > suggested pulling forward the "FraudType" from RFC5901, this would=20 > help solve the issue as NodeRole values would compliment an AttackType=20 > (FraudType values could be included in AttackType or some broader=20 > term).=C2=A0 It may be better to have the FraudTypes, plus attribute valu= es=20 > like "C2-server", "sinkhole",=C2=A0 "MalwareDistribution" for added conte= xt=20 > so you know what to do with the received set of indicators. >=20 > I am proposing that we change IODEF to include multiple sets of indicators, > add an AttackType attribute (or some other name), a method to connect=20 > indicators and indicator sets within an IODEF using an attribute of=20 > indicator_uid (or some other name) with a string value to make the=20 > connection points, and add a few indicators that are commonly shared=20 > into the base IODEF. >=20 > Back in July, we talked about adding Registry Key/Value pairs and=20 > hashes to the main IODEF document (trying to see if this will help=20 > Chris below).=C2=A0 What if we added the Registry Key/Value pairs as a=20 > class off of RecordData, using a similar structure to what is in=20 > RFC5901, and also added the ability to include hashes in RecordData?=C2= =A0=20 > I think if we then had the indicator_uid at the RecordData level, we=20 > could connect a set within that structure and repeat the structure for=20 > other sets in the same way we would do with Node inside of the System=20 > class, using the indicator_uid to tie the set together.=C2=A0 Then at the= =20 > more specific level for the hash, registry Key/value, IP, etc. use an=20 > indicator_uid if we needed them marked at this level as well?=C2=A0 Maybe= =20 > we want indicator_set at the higher level?=C2=A0 I'd like some opinions o= n=20 > this approach.=C2=A0 +1 if you agree, suggestions if you have other ideas= =20 > that may work better. >=20 > We'll also need to worry about marking the indicators to prevent=20 > forward sharing when not permitted.=C2=A0 We may want to use these values= =20 > or something else. >=20 > Thank you! > Kathleen >=20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs >=20 > I think we have a bigger relationship issue to address. Let use the=20 > Watchlist Use Case. A bunch of indicators are sent in one message. In=20 > that message we could have groupings of indicators that we need to=20 > show are > related: >=20 > Two or more indicators of different type that relate to the same threat: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 The file hash of a malicious file and the URL = of the C2 that=20 > the file uses. Either or both may be present to indicate a compromise. >=20 > Two or more indicators of the same type that relate to the same threat: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 2 different registry values for the same regis= try key. If=20 > either value is present it is a compromise indicator but both will not=20 > be present. >=20 > The problem compounds itself very quickly. Consider the scenario where=20 > both groupings above are part of the same threat. I need to show that=20 > logical groupings of Indicators are related as well. We can't send=20 > multiple IODEF messages for this from what I remember reading. >=20 > The last one I can think of would be when you have 2 different=20 > indicators that represent the same indicator. It's not uncommon to=20 > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the=20 > IOCs are the 2 hash values. How do we show they are related? If we use=20 > a unique Inidcator ID for each hash value there needs to be a higher=20 > level grouping. >=20 > Thoughts? >=20 > Thanks, >=20 > --Chris >=20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > All - >=20 > I'd like your input and will refocus the thread to get opinions from=20 > the list on options to help solve the problems raised in my message=20 > and additionally in Paul's message. >=20 > Interesting point, C. Henry.=C2=A0 Our objective here is to have machine= =20 > automated exchanges, so we rely on encryption rather than obfuscation=20 > to achieve the necessary level of confidentiality. >=20 > Paul mentioned the need to distinguish indicators of compromise from=20 > context information that may also include IP address or other data=20 > that could be indicators.=C2=A0 The question I raised was on how to conne= ct=20 > sets of indicators in the same IODEF document, assuming the ability to=20 > have watchlists that could have several sets of indicators included,=20 > as well as to connect indicators that may be included in embedded=20 > schemas. >=20 > If we add an attribute on all of the relevant indicators, let's say=20 > 'indicator-uid' how do we mark the indicators?=C2=A0 Do we use this to ma= rk=20 > who sent the indicator as well so that we can prevent forward sharing=20 > when it is not permitted or handle that separately? >=20 > Then for indicators not included in the base schema that may not fit=20 > into a category in the SCI draft, do we create a place for these off=20 > of SCI or right off of the IODE schema in EventData? (more details on=20 > this in my first message). >=20 > Comments and questions encouraged to figure out the right technical=20 > solution to have this machine automatable. >=20 > Thank you, > Kathleen >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > Temporal Dependency sounds interesting.=C2=A0 I remember when I first ran= =20 > across this particular craft, an experienced colleague asked me a=20 > peculiar question.=C2=A0 He said, " How do you stop someone from tracking= =20 > the IP Address to your computer?" >=20 > I replied, "I don't know, how?" >=20 > Then he said, "Cut the dog-gone thing off=C2=A0 and the modem that it is > connected- which is constantly on!"=C2=A0=C2=A0=C2=A0LOL >=20 > Here's my point (Hypothetical Situation) :=C2=A0 There is a 1st Responder= =20 > searching a Neighborhood for Survivors which were hit by a Disaster or=20 > let's just say "Live" Terrorist Situation.=C2=A0 He /or She needs to=20 > communication back to other Officials that he /or somehow is in=20 > Danger.=C2=A0 The device used to communicate has been captured by the gre= at=20 > minds of the enemy.=C2=A0 It's only a matter of time before they utilize= =20 > reverse engineering to figure out how it functions.=C2=A0 However, their= =20 > pride comes before a fall when seeking the location of other similar=20 > devices to attack.=C2=A0 Why? Perhaps the less thought of concepts that= =20 > makes the device function properly, saves the day by disguise or=20 > cutting it off (figuratively speaking). >=20 > Just a visionary thought. >=20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the=20 > original recipient. This information is granted for limited=20 > distribution within the recipient's place of business for planning=20 > purposes only. Further dissemination, whether private or public is=20 > prohibited. >=20 > --- On Mon, 1/28/13, Dave Misell wrote: >=20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS=20 > SEC a pemanent and temporal key, with a temporal Id? >=20 > Yours Faithfully, >=20 > Dave Misell MSc CISSP > SilentCircle=C2=A0 dsm > 07710 380044 > david.misell@bcs.org >=20 >=20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: >=20 > > Serialization of a particular Lists of XML Classes in a unique way=20 > > was > closely related to what I attempted to express when I stated,=20 > "consider to a degree what appears to be illogical in brilliant minds=20 > in some instances." > > > > However, I see Dr. Stoecker's point a little clearer.=C2=A0 However, it= =20 > > would > be nice if the UID was in some way disguised from those who study this=20 > Security Art Form in a negative way. > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > Re: [mile] IOCs > > > > Sunday, January 27, 2013 8:52 PM > > From: > > "Stoecker, Paul" > > To: > > "mile@ietf.org" > > I would like to look at this from a slightly different > > perspective=C5=A0let's say I get an XML document that tells me about an > > incident.=C2=A0 This document has source IP and destination IP that is > > being shared.=C2=A0 However, what I don't know is which IP address is m= y > > indicator and which is just a contextual piece of information.=C2=A0 Th= is > > means that my detection product isn't going to know which one to use > > either, because there is nothing to tell me which IP is the one, even > > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > > > > If we had something like indicator_id as an attribute, it would allow > > us to easily identify indicators from contextual data.=C2=A0 I do admit= to > > being biased as I have spent much of my career working on the > > monitoring and detection side of these things, so I am just thinking > > of ways to make it very clear what the indicators are in the XML > > document and the other data that may be important as I investigate > > activity that I have detected off of those indicators. > > > > > > I did suggest the detection class, but I think we may get more > > flexibility with the indicator_uid.=C2=A0 One thing that I haven't > > considered is the UID portion of this=C5=A0how do we use that UID?=C2= =A0 How is > > the UID created?=C2=A0 Are there standards for UIDs? > > > > Regards, > > > > Paul > > > > > > > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote= : > > > > From: C. Henry Adams & BIE > > Subject: RE: [mile] IOCs > > To: "KathleenMoriarty" > > Cc: mile@ietf.org > > Date: Saturday, January 26, 2013, 6:17 PM > > > > Greetings Kathleen, > > > > Your logic stimulates my visionary brain because I'm amazed at the > > many > avenues you review with this approach at once.=C2=A0 However,=C2=A0 could= you share > a > few advantages and disadvantages to the latter? > > > > > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > > "we could continue to group items in logical places as is done now in > IODEF and then have the extension point for combined indicators via SCI." > > > > > -------------------------------------------------------------------- > -------- > --------------------------------------------- > > > > You pointed out what you consider to be logical places, but if I > > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what appears > to > be illogical in brilliant minds in some instances. > > > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > > > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > > > > From: Moriarty, Kathleen > > Subject: RE: [mile] IOCs > > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > Hello C. Henry & others, > > > > Thanks for taking a look at this.=C2=A0 We have a few considerations in > > this > email thread I would like to hear thoughts on (and there may be more once > RFC5070-bis is actively edited). > > > > The AdditionalData class and the RecordItem class both allow for > > non-XML > extensions.=C2=A0 Where you place the extensions should be specific to th= e > logical grouping of the parent elements so you can understand more about > the > included data in most cases. > > > > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating on > the > report as a whole.=C2=A0 Extensions related to impact would be one level = higher > (at the moment) in the Assessment class using the AdditionalData extensio= n > point. > > > > Take asked about including vulnerability information, I would think > > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class.=C2=A0 He did ask about non-XML.=C2=A0 RecordItem or Additio= nalData > do > allow for non-XML extension points, we could either have the SCI draft > handle these as well or have the extensions that are non-XML come directl= y > off the AdditionalData or RecordItem classes according to what makes sens= e > from a logical standpoint. > > > > As for my question, it was two-fold. > > > > Indicator based schemas have a reference number or a GUID for the > > various > indicators they share.=C2=A0 If we are extending to embed other schemas t= hat > include such reference or GUID identifiers, do we want to add an attribut= e > to the various elements in IODEF that could be indicators?=C2=A0 Is this = enough > to make the connections or is something else else needed?=C2=A0 We could = add > something like an Indicator_ID in RFC5070-bis which would then correlate > to > the reference or GUID identifiers. > > > > Then the other question was on how to include indicators that are not > > in > the base schema that may be related or have language with "and" "or" to > specify the relationships.=C2=A0 In some cases, you will want to group th= ese > indictors in one extension point, where they may fit logically in multipl= e > places if the relationships did not need to be shown in the data > format.=C2=A0 If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData class > AdditionalData extension point?=C2=A0 Opinions are needed here.... > > > > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document.=C2=A0 We could have a catch-all c= lass > that does this and has an extension point off of it in EventData or we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI.=C2=A0 I think I= like > the latter approach. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > > Henry > Adams & BIE [chatlga2000@yahoo.com] > > Sent: Saturday, January 26, 2013 3:05 AM > > To: mile@ietf.org > > Cc: C. Henry Adams > > Subject: Re: [mile] IOCs > > > > Greetings Everyone, > > > > Take mentioned two types of indicators based on the : > > > -------------------------------------------------------------------- > -------- > -------------------------- > > 1) If the indicators are something like an XML-based alert/warning of > > information leakage, it could be an event that are conveyed in the > > SCI's EventReport class, IMHO. > > > > 2) If the indicators are something like an non-XML ones, I guess it > > could > be > > conveyed without using SCI draft. > > For instance, we could use Impact class of the base IODEF to convey > > the indicators. > > We could for instance extend the list of indicators of the Impact > > class, > if > > needed. > > > -------------------------------------------------------------------- > -------- > -------------------------- > > > > In doing so he pointed out the "Impact Class" > > > > Whereas, Kathleen stated, > > > > > -------------------------------------------------------------------- > -------- > ------------------------- > > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > > > > Paul Stoecker had suggested a "Detection" class as a consideration. > > > -------------------------------------------------------------------- > -------- > ------------------------ > > > > Kathleen thoughts related yet still with other indicators and the > EventData Class. > > > > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > > > > > > C. Henry Adams > > chatlga2000@yahoo.com (Direct Email) > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > original > recipient. This information is granted for limited distribution within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 ---2038480821-1994560635-1360734626=:86450 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
RFC5070 Chapter 3 section 10 item 4 does not = appear to restrict conflation of a numeric value and its definition. I woul= d guess that what I'm really trying to state here is there should perhaps b= e a simple standardization establish in a sort of an Alpha-numeric value if= possible as oppose to a numeric value.

Please see (Revision) below:=
( i.e.  1LL =3D Less Likely,   2P =3D Probable,  3AC =3D= A Concern,  4U =3D  Urgent,  5I =3D Imminent )

I wou= ld concur, perhaps Sharing Groups regarding the IODEF should be given a sur= vey of some kind to address potential issues with the High, Medium, Low ass= essment combined with a numeric rating  0 - 100 to possibly revisit cr= eating a simplified approach.








Please=0A see section 3.10.4 of RFC= 5070 as a starting point.  We can change it if=0A it needs to be chang= ed.  The value is for a confidence rating on the =0Aindicators shared.=   The definitions may be helpful for anyone who wants =0Ato work on th= is discussion.  IODEF has various markers that can be used =0Ain a com= plimentary way without conflating the markers meaning.

 

<= p class=3D"yiv120555620MsoNormal">I=0A think s= ome people using IODEF find the numerical values more helpful, =0Aand it wo= uld be good to understand what people have learned from using =0Athe curren= t structure (what works/does not work).  The scales I have =0Aseen are= 0-100.  There is of course a subjective element to assigning a =0Anum= erical value to the confidence and it may vary from entity to =0Aentity.&nb= sp; With this type of rating you may need to consider who it came =0Afrom a= nd how they scored the confidence rating to map to your own =0Arating. = ; It would be good to hear more thoughts on this. 

 

<= p class=3D"yiv120555620MsoNormal">Thanks,

Kathl= een

 

From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]
Se= nt: Tuesday, February 12, 2013 2:46 PM
To: MILE IETF
Cc= : Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
Subject= : Re: [mile] IOCs

&= nbsp;


Regarding=0A the IOCs or In= dicators of Compromise, Chris made a vital point.  =0ADifferent Confid= ence levels will cause confusion.  It appears that there=0A maybe a ne= ed for some type of simplified standardization to be =0Aestablished between= all Sharing Groups in this regard.

Perhaps numerical scoring set at= lower values should express levels of urgency.
( i.e.  1 =3D Less = Likely,   2 =3D Probable,  3 =3D A Concern,  4 =3D  Urg= ent,  5 =3D Imminent )

Thanks,
C. Henry Adams


I see some confusion coming down the pike if we start using Confidence the=
way it is supported. If I am using low/med/high and someone sends me an= IoC
with a score of 70, what does that mean to me? What if I am using a= scale of
1 to 4 and someone else is on a scale of 1 to 5? We lose the a= bility to
describe something with a consistent language. It really gets = ugly when we
store IoC from multiple sources. I have confidence values t= hat are numeric
as well as text.  Makes searching / sorting very pr= oblematic.

At this point we have to roll with what we have. I would= strongly recommend
that we revisit this at some point.

Thanks,

--Chris

-----Original Message-----
From: = Moriarty, Kathleen
Sent: Tuesday, February 12, 2013 9:59 AM
To: Harr= ington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE
IETF'Subject: RE: [mile] IOCs

Hi Chris & Take,

I'll just focu= s on the confidence scoring.  Right now, the schema allows for
you = to either use a numerical score OR the ratings of low, medium, and high.Different sharing groups can decide how they want to share the data. = If
people were to use the numerical values, I agree it would be helpful= to have
guidance.  This could go in the IODE guidance document.
I have seen examples of current users that use each of the approaches,= so
we'll need to keep the option for backwards compatibility and it is = nice to
keep in flexible options where we can.

Thank you,
Kath= leen

-----Original Message-----
From: Harrington, Christopher
Sent: Tuesday, February 12, 2013 9:22 AM
To: 'Takeshi T= akahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: = [mile] IOCs

The number of indicators wouldn't necessarily drive the = use of
indicator_set_id. The purpose is to show relationship. If I sent = 3 IP
addresses that were used as C2 for 3 different campaigns I would ha= ve
separate indicator_set_ids, each with one of the 3 C2 IPs

My s= uggestion would be a simple low, medium, high. I think if we break it
do= wn to more levels than that we would need to provide guidance on scoring,rating, etc. I think most people should be able to understand low/med/hig= h
without having to have a mathematical method for arriving at the level= .

Low - I am not sure
Medium - I am reasonably sure
High - I = am very sure


Thanks,

--Chris

-----Original Messag= e-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Tu= esday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, = Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Re= garding the indicator_set_id, I agree, it is useful when we need to dealwith large sets of indicators.
Since indicator_set_id attribute is opti= onal (right?), it could be omitted
if we need to deal with only small nu= mber of indicators.

Regarding the use case, I like the idea of using= the confidence attribute
for the reason Chris kindly described.
I wo= uld like to hear a bit more on this: is it going to be numerical? For
in= stance, 1 means "no confidence" while 5 means "strong confidence", etc?
=
Thank you.
Take


> -----Original Message-----
> F= rom: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]
> Sent: Friday, Febr= uary 08, 2013 4:11 AM
> To: Moriarty, Kathleen; Takeshi Takahashi; St= oecker, Paul; 'MILE IETF'
> Subject: RE: [mile] IOCs
>
>= With respect to tying things back to threat actors, from what I have
&= gt; seen and use this is a generally accepted grouping:
>
> In= dicator --> Indictor Set --> Campaign --> Threat Actor
> > Campaign and Threat Actor are where having a "Confidence" attribute <= br>> would be beneficial as making those associations is not a perfect <= br>> science by any means.
>
> Thanks,
>
> --C= hris
>
>
> -----Original Message-----
> From: Mor= iarty, Kathleen
> Sent: Thursday, February 07, 2013 2:00 PM
> T= o: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE
> IETF'
> Subject: RE: [mile] IOCs
>
> Hi Take &= amp; others,
>
> Thanks for chiming in, I've been talking abou= t this with Chris and a
> few others on their use cases and would li= ke more opinions.  I'll
> provide an option below from what we = have discussed from a CIRC view
> point.  We are also wondering= how to also provide logic in IODEF that
> could cross over into SCI= attached schemas or IODEF extensions (the
> solutions may all tie t= ogether with this discussion - or there may be
> better/more elegant= solutions others would like to propose).
>
> -----Original Me= ssage-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Tue= sday, February 05, 2013 12:04 PM
> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE
> IETF'
> Subject: = RE: [mile] IOCs
>
> > I like this discussion.
> > = I agree, it would be good idea to have indicator identifiers inside
>= ; > the IOC-related classes.
>
> KMM: At the class level, w= e may have several indicators listed that
> should be viewed as a se= t and may have another instance of that same
> class that is a relat= ed issue, but a separate set.  We could as you
> say, list the = indicator IDs connected through the reference class. 
> The set= IDs might give us other ways to group the values when we get
> into= logic and relationships between sets or indicators.  This could
&= gt; also be a way to connect indicators or sets across XML documents that <= br>> could have been shared previously.  If there are a large numbe= r of
> indicators in the set, then this becomes useful, for smaller sets, I
> agree it doesn't make as much sense.
>
= > What do others think?
>
> >> Then for indicators no= t included in the base schema that may not
> >> fit into a cat= egory in the SCI draft, do we create a place for
> >> these of= f of SCI or right off of the IODE schema in EventData?
> >> (m= ore details
> on
> >> this in my first message).
> = >
> > If we could see any indicator of compromise as computer e= vent
> > record, we could use SCI:EventReport class as the place = for the
> > XML-based IOCs that couldn't fit anywhere else.
&g= t;
> KMM: That sounds like a good idea to me.  This should go i= nto guidance
> in the SCI draft.  Does anyone else want to weig= h in?
>
> >
> > For the non-XML IOCs, we could use= RecordData class, as suggested.
> KMM: Sounds good, thanks!
>
> > I agree to have indicator_uid, but I am not = sure about the needs of
> > the indicator_set_id.
> > I = understand we could do some grouping of individual indicator_uids
> = > and its usability, but I am not sure whether we do not have any
&g= t; > other way to express these groupings.
> > For instance,&nb= sp; a Reference class refers to several indicadtor_uids.
> In
>= > this case, they could be, in a sense, grouped. Isn't it enough?
&g= t;
> KMM: It may be, what do you think about large sets of indicator= s or
> subsequent messages that add indicators to existing sets?&nbs= p; Would this
> happen?  Would it be easier to express relation= ships with sets of
> indicators in addition to individual indicators= ?  By using this, it
> could give us a unique way to also provi= de the logic and relationships
> in a new class of IODEF so we don't have to worry about adding it into
> the current
struct= ure.
> If there are better ways to handle that, and others can provid= e some
> options, that would be appreciated!
>
> Thank = you,
> Kathleen
>
> > I would appreciate if anybody c= ould share expertise on this. Though
> I
> > think I have re= ad all the emails in the list, I might have
> > mis-understood so= me points.
> >
> > By the way, I think the indicator_uids= should be added to the SCI
classes'
> > attributes so that the= y can be correlated with another information
> > as
> well.=
> >
> > Thanks
> > Take
>
>
&g= t;
> From: mile-bounces@iet= f.org [mailto:mile-bounces@ietf.org] On Behalf
> Of Harrington, Christophe= r
> Sent: Tuesday, February 05, 2013 4:25 AM
> To: Stoecker, Pa= ul; Moriarty, Kathleen; MILE IETF
> Subject: Re: [mile] IOCs
> =
> I think some sort of group ID would do the trick. We also need a <= br>> logical and / or somewhere to show relationship between indicators.= If
> I give you
> 2
> registry keys do they both have t= o be present to be an indication of
> compromise or is either one by= themselves an indicator? Both would
> have the same group ID since = they are related.
>
> Thanks,
> --Chris
>
>= From: Stoecker, Paul
> Sent: Sunday, February 03, 2013 8:26 PM
&g= t; To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF
> Subje= ct: Re: [mile] IOCs
>
> What if we added indicator group ID along with the indicator_uid? 
> This would allow you to group= indicators that are related into the
> same group ID.
> = Would this resolve the issue?
>
> It is either that or going = back to adding a Detection (or Indicators)
> class that will should = be used to take all of the indicators put them
> into one place and = have the ability to group the ones that go
> together.  I don't= mean a place to put indicators that are missing
> from IODEF.I mean= a place in the IODEF document where you put the
> indicators that a= re used for detection and prevention of the shared
> Incident. = I don't know the answer here, but there has got to be a
> good way = for indicators to be identified and being able to group them
> as Ch= ris has suggested without basically recreating something
> complicat= ed like STIX.
>
> Paul
>
>
> Paul W. Stoecker, Ph.D.
> SMC Lead Content Architect
> RSA, The Sec= urity Division of EMC
> cell: 302.379.3375 | e: paul.stoecker@rsa.com
>
>
> Fro= m: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>
> Date: Sunday, February 3, 201= 3 5:11 PM
> To: "Harrington, Christopher" <Christopher.Harrington@emc.com>, MILE > IETF <mile@ietf.org>
&g= t; Subject: Re: [mile] IOCs
>
> Hi Chris,
>
> I a= gree, we have some work to do in the updated IODEF, RFC5070-bis.
>
> The list has alr= eady said they would like to see indicators added to
> the definitio= ns in RFC5070-bis, to be more explicit about including
> indicators = and sets of indicators in IODE documents as opposed to
> 'parts of a= n incident or the useful information on an incident for
> sharing pu= rposes.  It was written before we used terms like
> indicators.=   With that in mind, Rosella proposed a number of changes
> bac= k in July, both for guidance and for
format
> updates.  It ma= y help to have the first draft try to address at least
> some of the= se issues so people can understand the problems and at
> least a pro= posed solution.
>
> As you point out, we need to be able to sh= ow relationships between
> sets of indicators, where we may have a f= ew sets of indicators that
> could have a relationship to each other within a document.  In the
> July presentation, one= of the questions was to see if we should add
> new category attribu= te values for the System class that would connect
> the list of incl= uded indicators.  I think we should still keep the
> concept of= a Node to a single node, but perhaps within System, list
> multiple= sets of Nodes that may be one type of attack.  Rosella had
> s= uggested pulling forward the "FraudType" from RFC5901, this would
> = help solve the issue as NodeRole values would compliment an AttackType
= > (FraudType values could be included in AttackType or some broader
= > term).  It may be better to have the FraudTypes, plus attribute v= alues
> like "C2-server", "sinkhole",  "MalwareDistribution" fo= r added context
> so you know what to do with the received set of in= dicators.
>
> I am proposing that we change IODEF to include multiple sets of
indicators,
> add an AttackType attribut= e (or some other name), a method to connect
> indicators and indicat= or sets within an IODEF using an attribute of
> indicator_uid (or so= me other name) with a string value to make the
> connection points, = and add a few indicators that are commonly shared
> into the base IO= DEF.
>
> Back in July, we talked about adding Registry Key/Val= ue pairs and
> hashes to the main IODEF document (trying to see if t= his will help
> Chris below).  What if we added the Registry Ke= y/Value pairs as a
> class off of RecordData, using a similar struct= ure to what is in
> RFC5901, and also added the ability to include h= ashes in RecordData? 
> I think if we then had the indicator_ui= d at the RecordData level, we
> could connect a set within that stru= cture and repeat the structure for
> other sets in the same way we would do with Node inside of the System
> class, using the i= ndicator_uid to tie the set together.  Then at the
> more speci= fic level for the hash, registry Key/value, IP, etc. use an
> indica= tor_uid if we needed them marked at this level as well?  Maybe
>= ; we want indicator_set at the higher level?  I'd like some opinions o= n
> this approach.  +1 if you agree, suggestions if you have ot= her ideas
> that may work better.
>
> We'll also need t= o worry about marking the indicators to prevent
> forward sharing wh= en not permitted.  We may want to use these values
> or somethi= ng else.
>
> Thank you!
> Kathleen
>
> From= : Harrington, Christopher
> Sent: Friday, February 01, 2013 12:01 PM<= br>> To: Moriarty, Kathleen; MILE IETF
> Subject: RE: [mile] IOCs<= br>>
> I think we have a bigger relationship issue to address. Let use the
> Watchlist Use Case. A bunch of indicators ar= e sent in one message. In
> that message we could have groupings of = indicators that we need to
> show are
> related:
>
&= gt; Two or more indicators of different type that relate to the same threat= :
>        The file hash of a malicious file and = the URL of the C2 that
> the file uses. Either or both may be presen= t to indicate a compromise.
>
> Two or more indicators of the = same type that relate to the same threat:
>       = ; 2 different registry values for the same registry key. If
> either= value is present it is a compromise indicator but both will not
> b= e
present.
>
> The problem compounds itself very quickly. C= onsider the scenario where
> both groupings above are part of the sa= me threat. I need to show that
> logical groupings of Indicators are related as well. We can't send
> multiple IODEF mess= ages for this from what I remember reading.
>
> The last one I= can think of would be when you have 2 different
> indicators that r= epresent the same indicator. It's not uncommon to
> send both the> MD5
> and SHA1 hash of a malicious file. The indicator is the f= ile but the
> IOCs are the 2 hash values. How do we show they are re= lated? If we use
> a unique Inidcator ID for each hash value there n= eeds to be a higher
> level
grouping.
>
> Thoughts?<= br>>
> Thanks,
>
> --Chris
>
> Christop= her Harrington
> Consulting Security Engineer
> GSO - Critical = Incident Response Center EMC - Where Information Lives
> 174 Middlese= x Turnpike
> Bedford, MA 01730
> 781-515-5862 (work)
> 60= 3-583-1585 (cell)
>
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf
> Of Mori= arty, Kathleen
> Sent: Friday, February 01, 2013 11:28 AM
> To:= MILE IETF
> Subject: Re: [mile] IOCs
>
> All -
> =
> I'd like your input and will refocus the thread to get opinions fr= om
> the list on options to help solve the problems raised in my mes= sage
> and additionally in Paul's message.
>
> Interest= ing point, C. Henry.  Our objective here is to have machine
> a= utomated exchanges, so we rely on encryption rather than obfuscation
&g= t; to achieve the necessary level of confidentiality.
>
> Paul= mentioned the need to distinguish indicators of compromise from
> c= ontext information that may also include IP address or other data
> that c= ould be indicators.  The question I raised was on how to connect
&= gt; sets of indicators in the same IODEF document, assuming the ability to =
> have watchlists that could have several sets of indicators include= d,
> as well as to connect indicators that may be included in embedd= ed
> schemas.
>
> If we add an attribute on all of the = relevant indicators, let's say
> 'indicator-uid' how do we mark the = indicators?  Do we use this to mark
> who sent the indicator as= well so that we can prevent forward sharing
> when it is not permit= ted or handle that separately?
>
> Then for indicators not inc= luded in the base schema that may not fit
> into a category in the S= CI draft, do we create a place for these off
> of SCI or right off o= f the IODE schema in EventData? (more details on
> this in my first message).
>
> Comments and questions encouraged to figu= re out the right technical
> solution to have this machine automatab= le.
>
> Thank you,
> Kathleen
>
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf =
> Of C.
> Henry Adams & BIE
> Sent: Monday, January = 28, 2013 11:25 PM
> To: MILE IETF
> Subject: Re: [mile] IOCs>
> Temporal Dependency sounds interesting.  I remember whe= n I first ran
> across this particular craft, an experienced colleag= ue asked me a
> peculiar question.  He said, " How do you stop = someone from tracking
> the IP Address to your computer?"
> > I replied, "I don't know, how?"
>
> Then he said, "Cut the dog-= gone thing off  and the modem that it is
> connected- which is c= onstantly on!"   LOL
>
> Here's my point (Hypot= hetical Situation) :  There is a 1st Responder
> searching a Ne= ighborhood for Survivors which were hit by a Disaster or
> let's jus= t say "Live" Terrorist Situation.  He /or She needs to
> commun= ication back to other Officials that he /or somehow is in
> Danger.&= nbsp; The device used to communicate has been captured by the great
>= ; minds of the enemy.  It's only a matter of time before they utilize =
> reverse engineering to figure out how it functions.  However,= their
> pride comes before a fall when seeking the location of othe= r similar
> devices to attack.  Why? Perhaps the less thought o= f concepts that
> makes the device function properly, saves the day by disguise or
> cutting it off (figuratively speaking).>
> Just a visionary thought.
>
> C. Henry Adams> chenryadams@biemedia= group.com
> http://biemediagroup.com
>
>
> T= he information contained herein is for the exclusive use of the
> or= iginal recipient. This information is granted for limited
> distribu= tion within the recipient's place of business for planning
> purpose= s only. Further dissemination, whether private or public is
> prohib= ited.
>
> --- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> wrote:
>
&g= t; From: Dave Misell <david.misell@bcs.org>
> Subject: Re: [mile] IOCs
> To: "C. Henry Adams & BI= E" <chatlga2000@yahoo.com&g= t;
> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored wi= th DNS
> SEC a pemanent and temporal key, with a temporal Id?
>= ;
> Yours Faithfully,
>
> Dave Misell MSc CISSP
>= SilentCircle  dsm
> 07710 380044
> david.misell@bcs.org
>
>
> On 29 = Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com>
> wrote:
>
> > Seri= alization of a particular Lists of XML Classes in a unique way
> >= ; was
> closely related to what I attempted to express when I stated,=
> "consider to a degree what appears to be illogical in brilliant m= inds
> in some instances."
> >
> > However, I see = Dr. Stoecker's point a little clearer.  However, it
> > woul= d
> be nice if the UID was in some way disguised from those who study= this
> Security Art Form in a negative way.
> >
> &g= t; C. Henry Adams
> > c= hatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com
> >
> >
= > > The information contained herein is for the exclusive use of the<= br>> > original
> recipient. This information is granted for li= mited distribution within
> the
> recipient's place of business= for planning purposes only. Further
> dissemination, whether private= or public is prohibited.
> >
> > Re: [mile] IOCs
>= >
> > Sunday, January 27, 2013 8:52 PM
> > From:
&= gt; > "Stoecker, Paul" <Paul= .Stoecker@rsa.com>
> > To:
> > "mile@ietf.org" <mile= @ietf.org>
> > I would like to look at this from a slightly= different
> > perspective=C5=A0let's say I get an XML document th= at tells me about an
> > incident.  This document has source = IP and destination IP that is
> > being shared.  However, wha= t I don't know is which IP address is my
> > indicator and which i= s just a contextual piece of information.  This
> > means tha= t my detection product isn't going to know which one to use
> > ei= ther, because there is nothing to tell me which IP is the one, even
>= > if the roles are set it still might not be enough to tell my system> which
> one I should use as the indicator.
> >
>= ; > If we had something like indicator_id as an attribute, it would allo= w
> > us to easily identify indicators from contextual data.  I do admit to
> > being biased as I have spent much of my career = working on the
> > monitoring and detection side of these things, = so I am just thinking
> > of ways to make it very clear what the i= ndicators are in the XML
> > document and the other data that may = be important as I investigate
> > activity that I have detected of= f of those indicators.
> >
> >
> > I did suggest= the detection class, but I think we may get more
> > flexibility = with the indicator_uid.  One thing that I haven't
> > conside= red is the UID portion of this=C5=A0how do we use that UID?  How is> > the UID created?  Are there standards for UIDs?
> >= ;
> > Regards,
> >
> > Paul
> >
>= >
> >
> > Paul W. Stoecker, Ph.D.
> > SMC Le= ad Content Architect
> > RSA, The Security Division of EMC
> > cell: 302.379.3375 | e: paul.stoecker@rsa.com
> >
> > --- On Sat, 1/2= 6/13, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote:
> >
> > From: C. He= nry Adams & BIE <chatlga200= 0@yahoo.com>
> > Subject: RE: [mile] IOCs
> > To: = "KathleenMoriarty" <kathlee= n.moriarty@emc.com>
> > Cc: mile@ietf.org
> > Date: Saturday, January 26, 2013, 6:17 PM
> >
> > Greeti= ngs Kathleen,
> >
> > Your logic stimulates my visionary = brain because I'm amazed at the
> > many
> avenues you revie= w with this approach at once.  However,  could you share
> = a
> few advantages and disadvantages to the latter?
> >
&= gt; >
> ----------------------------------------------------------= ----------
> --------
> ---------------------------------------= -------
> > "we could continue to group items in logical places as= is done now in
> IODEF and then have the extension point for combine= d indicators via SCI."
> >
> >
> ------------------= --------------------------------------------------
> --------
>= ---------------------------------------------
> >
> > Yo= u pointed out what you consider to be logical places, but if I
> > wanted to
> protect information from parties capable = of ascertaining it from your
> logical places, perhaps we should also= consider to a degree what appears
> to
> be illogical in brill= iant minds in some instances.
> >
> >
> >
>= ; > C. Henry Adams
> > chatlga2000@yahoo.com (Direct Email)
> > chenryadams@biemediagroup.com
> >=
> > The information contained herein is for the exclusive use of = the
> > original
> recipient. This information is granted fo= r limited distribution within
> the
> recipient's place of busi= ness for planning purposes only. Further
> dissemination, whether pri= vate or public is prohibited.
> >
> > --- On Sat, 1/26/13, Moria= rty, Kathleen <kathleen.mor= iarty@emc.com>
> wrote:
> >
> > From: Moriar= ty, Kathleen <kathleen.mori= arty@emc.com>
> > Subject: RE: [mile] IOCs
> > To:= "C. Henry Adams & BIE" <c= hatlga2000@yahoo.com>, "mile@ietf= .org"
> <mile@ietf.org>= ;
> > Date: Saturday, January 26, 2013, 10:13 AM
> >
> > Hello C. Henry & = others,
> >
> > Thanks for taking a look at this.  W= e have a few considerations in
> > this
> email thread I wou= ld like to hear thoughts on (and there may be more once
> RFC5070-bis= is actively edited).
> >
> > The AdditionalData class an= d the RecordItem class both allow for
> > non-XML
> extensio= ns.  Where you place the extensions should be specific to the
> = logical grouping of the parent elements so you can understand more about> the
> included data in most cases.
> >
> > Th= e Impact class can be used to provide context information on the
> in= cluded data of the report and also can include a confidence rating on
&g= t; the
> report as a whole.  Extensions related to impact would = be one level higher
> (at the moment) in the Assessment class using the AdditionalData extension
> point.
> >
> >= ; Take asked about including vulnerability information, I would think
&g= t; > that
> would fit under the Vulnerability extension point of t= he SCI draft in
> the
> Method class.  He did ask about no= n-XML.  RecordItem or AdditionalData
> do
> allow for non-= XML extension points, we could either have the SCI draft
> handle the= se as well or have the extensions that are non-XML come directly
> of= f the AdditionalData or RecordItem classes according to what makes sense> from a logical standpoint.
> >
> > As for my questi= on, it was two-fold.
> >
> > Indicator based schemas have= a reference number or a GUID for the
> > various
> indicato= rs they share.  If we are extending to embed other schemas that
>= ; include such reference or GUID identifiers, do we want to add an attribute
> to the various elements in IODEF that could be indicator= s?  Is this enough
> to make the connections or is something els= e else needed?  We could add
> something like an Indicator_ID in= RFC5070-bis which would then correlate
> to
> the reference or= GUID identifiers.
> >
> > Then the other question was on= how to include indicators that are not
> > in
> the base sc= hema that may be related or have language with "and" "or" to
> specif= y the relationships.  In some cases, you will want to group these
&= gt; indictors in one extension point, where they may fit logically in multi= ple
> places if the relationships did not need to be shown in the dat= a
> format.  If
> we have cases like this where you need m= ore complex representations,
> should
> we use one extension po= int via the SCI draft off of the EventData class
> AdditionalData extension point?  Opinions are needed here....
>= >
> > A few people have mentioned wanting to include some comm= only shared
> indictors into the base IODEF document.  We could = have a catch-all class
> that does this and has an extension point of= f of it in EventData or we
> could
> continue to group items in= logical places as is done now in IODEF and
> then
> have the e= xtension point for combined indicators via SCI.  I think I like
>= ; the latter approach.
> >
> > Thank you,
> > Ka= thleen
> > ________________________________________
> > F= rom: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf= Of C.
> > Henry
> Adams & BIE [chatlga2000@yahoo.com]
> > Sent: Saturday, Janu= ary 26, 2013 3:05 AM
> > To: mile= @ietf.org
> > Cc: C. Henry Adams
> > Subject: Re: [mi= le] IOCs
> >
> > Greetings Everyone,
> >
>= > Take mentioned two types of indicators based on the :
> >> --------------------------------------------------------------------<= br>> --------
> --------------------------
> > 1) If the = indicators are something like an XML-based alert/warning of
> > in= formation leakage, it could be an event that are conveyed in the
> &g= t; SCI's EventReport class, IMHO.
> >
> > 2) If the indic= ators are something like an non-XML ones, I guess it
> > could
> be> > conveyed without using SCI draft.
> > For instance, we= could use Impact class of the base IODEF to convey
> > the indica= tors.
> > We could for instance extend the list of indicators of t= he Impact
> > class,
> if
> > needed.
> ><= br>> -------------------------------------------------------------------= -
> --------
> --------------------------
> >
> = > In doing so he pointed out the "Impact Class"
> >
> >= ; Whereas, Kathleen stated,
> >
> >
> -------------= -------------------------------------------------------
> --------> -------------------------
> > For the discussion below, I wa= s thinking more of combined set with
> relationships that may be incl= uded in a single extension point, so that's
> why I was thinking about the EventData class, but there may be better
> locati= ons or a specific area within the EventData.
> >
> > Paul= Stoecker had suggested a "Detection" class as a consideration.
> >= ;
> -----------------------------------------------------------------= ---
> --------
> ------------------------
> >
> = > Kathleen thoughts related yet still with other indicators and the
&= gt; EventData Class.
> >
> > Is there a possible way to c= reate a new XML class which encompass
> combining the EventData, Dete= ction and base IODEF classes to simplify
> this
> issue?
>= ; >
> >
> > C. Henry Adams
> > chatlga2000@yahoo.com (Direct Email)
>= > chenryadams@biemediagroup.com
> >
> >
= > > The information contained herein is for the exclusive use of the<= br>> > original
> recipient. This information is granted for li= mited distribution within
> the
> recipient's place of business= for planning purposes only. Further
> dissemination, whether private= or public is prohibited.
> > ____________________________________= ___________
> > mile mailing list
> > mile@ietf.org
> > https://www.iet= f.org/mailman/listinfo/mile
>
>


---2038480821-1994560635-1360734626=:86450-- From trammell@tik.ee.ethz.ch Tue Feb 12 23:14:22 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C499421F8918 for ; Tue, 12 Feb 2013 23:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=-3.194, BAYES_50=0.001, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NvBnTe0PZ3s for ; Tue, 12 Feb 2013 23:14:20 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1221F86F0 for ; Tue, 12 Feb 2013 23:14:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0DA43D930B; Wed, 13 Feb 2013 08:14:18 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hk3WF0WLEn-J; Wed, 13 Feb 2013 08:14:17 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 585BFD9308; Wed, 13 Feb 2013 08:14:17 +0100 (MET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Wed, 13 Feb 2013 08:14:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40C79581-1FCD-4471-AC7B-51066C20982C@tik.ee.ethz.ch> References: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.1499) Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:14:22 -0000 Hi, Kathleen, all, I think 3.10.4 in 5070 takes the right approach here: trying to build = interoperable numeric scales for assessment is a very hard problem. = (Were I charged with defining such a scale, the value "70" would mean = "we compared this incident report to N past similar incident reports = according to similarity algorithm S, and 70% of the past reports had = assessed impacts within E% of the actual, measured final impact -- I = think for most applications this is vastly more difficult and rigorous = than it needs to be.) Unless a numeric Confidence value is based on some actual, repeatably = measurable aspect of the Assessment report -- which I suspect in = many/most/all cases it's not -- then it just represents a guess, however = educated. Each team will probably naturally tune its own scales such = that each value generally means the same thing in each report. Across = teams, I don't know. On the other hand, Assessments are by their very nature educated = guesses, anyway, so I don't know that I'd find much use in automating a = response based on the assessment confidence. Chris has a good point, = though -- it makes searching difficult and sorting kind of pointless. If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I = agree, we should put that in the guidance document (along with a note = that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, = unless we want to do it non-linearly). If the _vast_majority_ of the = users of this field use a 100-point scale with 100 meaning "yes" and 0 = meaning "any resemblance these values may have to actual fact is purely = coincidental", then let's consider renaming it "percent" in 5070-bis. Best regards, Brian (as contributor) On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" = wrote: > Please see section 3.10.4 of RFC5070 as a starting point. We can = change it if it needs to be changed. The value is for a confidence = rating on the indicators shared. The definitions may be helpful for = anyone who wants to work on this discussion. IODEF has various markers = that can be used in a complimentary way without conflating the markers = meaning. > =20 > I think some people using IODEF find the numerical values more = helpful, and it would be good to understand what people have learned = from using the current structure (what works/does not work). The scales = I have seen are 0-100. There is of course a subjective element to = assigning a numerical value to the confidence and it may vary from = entity to entity. With this type of rating you may need to consider who = it came from and how they scored the confidence rating to map to your = own rating. It would be good to hear more thoughts on this.=20 > =20 > Thanks, > Kathleen > =20 > From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]=20 > Sent: Tuesday, February 12, 2013 2:46 PM > To: MILE IETF > Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul > Subject: Re: [mile] IOCs > =20 >=20 > Regarding the IOCs or Indicators of Compromise, Chris made a vital = point. Different Confidence levels will cause confusion. It appears = that there maybe a need for some type of simplified standardization to = be established between all Sharing Groups in this regard. >=20 > Perhaps numerical scoring set at lower values should express levels of = urgency. > ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) >=20 > Thanks, > C. Henry Adams >=20 >=20 >=20 > I see some confusion coming down the pike if we start using Confidence = the > way it is supported. If I am using low/med/high and someone sends me = an IoC > with a score of 70, what does that mean to me? What if I am using a = scale of > 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability = to > describe something with a consistent language. It really gets ugly = when we > store IoC from multiple sources. I have confidence values that are = numeric > as well as text. Makes searching / sorting very problematic.=20 >=20 > At this point we have to roll with what we have. I would strongly = recommend > that we revisit this at some point.=20 >=20 > Thanks, >=20 > --Chris >=20 > -----Original Message----- > From: Moriarty, Kathleen=20 > Sent: Tuesday, February 12, 2013 9:59 AM > To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; = 'MILE > IETF' > Subject: RE: [mile] IOCs >=20 > Hi Chris & Take, >=20 > I'll just focus on the confidence scoring. Right now, the schema = allows for > you to either use a numerical score OR the ratings of low, medium, and = high. > Different sharing groups can decide how they want to share the data. = If > people were to use the numerical values, I agree it would be helpful = to have > guidance. This could go in the IODE guidance document. >=20 > I have seen examples of current users that use each of the approaches, = so > we'll need to keep the option for backwards compatibility and it is = nice to > keep in flexible options where we can. >=20 > Thank you, > Kathleen >=20 > -----Original Message----- > From: Harrington, Christopher=20 > Sent: Tuesday, February 12, 2013 9:22 AM > To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE = IETF' > Subject: RE: [mile] IOCs >=20 > The number of indicators wouldn't necessarily drive the use of > indicator_set_id. The purpose is to show relationship. If I sent 3 IP > addresses that were used as C2 for 3 different campaigns I would have > separate indicator_set_ids, each with one of the 3 C2 IPs >=20 > My suggestion would be a simple low, medium, high. I think if we break = it > down to more levels than that we would need to provide guidance on = scoring, > rating, etc. I think most people should be able to understand = low/med/high > without having to have a mathematical method for arriving at the = level.=20 >=20 > Low - I am not sure > Medium - I am reasonably sure > High - I am very sure=20 >=20 >=20 > Thanks, >=20 > --Chris >=20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 > Sent: Tuesday, February 12, 2013 4:21 AM > To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE = IETF' > Subject: RE: [mile] IOCs >=20 > Regarding the indicator_set_id, I agree, it is useful when we need to = deal > with large sets of indicators. > Since indicator_set_id attribute is optional (right?), it could be = omitted > if we need to deal with only small number of indicators. >=20 > Regarding the use case, I like the idea of using the confidence = attribute > for the reason Chris kindly described. > I would like to hear a bit more on this: is it going to be numerical? = For > instance, 1 means "no confidence" while 5 means "strong confidence", = etc? >=20 > Thank you. > Take >=20 >=20 > > -----Original Message----- > > From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] > > Sent: Friday, February 08, 2013 4:11 AM > > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE = IETF' > > Subject: RE: [mile] IOCs > >=20 > > With respect to tying things back to threat actors, from what I have=20= > > seen and use this is a generally accepted grouping: > >=20 > > Indicator --> Indictor Set --> Campaign --> Threat Actor > >=20 > > Campaign and Threat Actor are where having a "Confidence" attribute=20= > > would be beneficial as making those associations is not a perfect=20 > > science by any means. > >=20 > > Thanks, > >=20 > > --Chris > >=20 > >=20 > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Thursday, February 07, 2013 2:00 PM > > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; = 'MILE=20 > > IETF' > > Subject: RE: [mile] IOCs > >=20 > > Hi Take & others, > >=20 > > Thanks for chiming in, I've been talking about this with Chris and a=20= > > few others on their use cases and would like more opinions. I'll=20 > > provide an option below from what we have discussed from a CIRC view=20= > > point. We are also wondering how to also provide logic in IODEF = that=20 > > could cross over into SCI attached schemas or IODEF extensions (the=20= > > solutions may all tie together with this discussion - or there may = be=20 > > better/more elegant solutions others would like to propose). > >=20 > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Tuesday, February 05, 2013 12:04 PM > > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; = 'MILE=20 > > IETF' > > Subject: RE: [mile] IOCs > >=20 > > > I like this discussion. > > > I agree, it would be good idea to have indicator identifiers = inside=20 > > > the IOC-related classes. > >=20 > > KMM: At the class level, we may have several indicators listed that=20= > > should be viewed as a set and may have another instance of that same=20= > > class that is a related issue, but a separate set. We could as you=20= > > say, list the indicator IDs connected through the reference class. =20= > > The set IDs might give us other ways to group the values when we get=20= > > into logic and relationships between sets or indicators. This could=20= > > also be a way to connect indicators or sets across XML documents = that=20 > > could have been shared previously. If there are a large number of=20= > > indicators in the set, then this becomes useful, for smaller sets, I=20= > > agree it doesn't make as much sense. > >=20 > > What do others think? > >=20 > > >> Then for indicators not included in the base schema that may not=20= > > >> fit into a category in the SCI draft, do we create a place for=20 > > >> these off of SCI or right off of the IODE schema in EventData?=20 > > >> (more details > > on > > >> this in my first message). > > > > > > If we could see any indicator of compromise as computer event=20 > > > record, we could use SCI:EventReport class as the place for the=20 > > > XML-based IOCs that couldn't fit anywhere else. > >=20 > > KMM: That sounds like a good idea to me. This should go into = guidance=20 > > in the SCI draft. Does anyone else want to weigh in? > >=20 > > > > > > For the non-XML IOCs, we could use RecordData class, as suggested. > > KMM: Sounds good, thanks! > >=20 > > > I agree to have indicator_uid, but I am not sure about the needs = of=20 > > > the indicator_set_id. > > > I understand we could do some grouping of individual = indicator_uids=20 > > > and its usability, but I am not sure whether we do not have any=20 > > > other way to express these groupings. > > > For instance, a Reference class refers to several = indicadtor_uids. > > In > > > this case, they could be, in a sense, grouped. Isn't it enough? > >=20 > > KMM: It may be, what do you think about large sets of indicators or=20= > > subsequent messages that add indicators to existing sets? Would = this=20 > > happen? Would it be easier to express relationships with sets of=20 > > indicators in addition to individual indicators? By using this, it=20= > > could give us a unique way to also provide the logic and = relationships=20 > > in a new class of IODEF so we don't have to worry about adding it = into=20 > > the current > structure. > > If there are better ways to handle that, and others can provide some=20= > > options, that would be appreciated! > >=20 > > Thank you, > > Kathleen > >=20 > > > I would appreciate if anybody could share expertise on this. = Though > > I > > > think I have read all the emails in the list, I might have=20 > > > mis-understood some points. > > > > > > By the way, I think the indicator_uids should be added to the SCI > classes' > > > attributes so that they can be correlated with another information=20= > > > as > > well. > > > > > > Thanks > > > Take > >=20 > >=20 > >=20 > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= > > Of Harrington, Christopher > > Sent: Tuesday, February 05, 2013 4:25 AM > > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > > Subject: Re: [mile] IOCs > >=20 > > I think some sort of group ID would do the trick. We also need a=20 > > logical and / or somewhere to show relationship between indicators. = If=20 > > I give you > > 2 > > registry keys do they both have to be present to be an indication of=20= > > compromise or is either one by themselves an indicator? Both would=20= > > have the same group ID since they are related. > >=20 > > Thanks, > > --Chris > >=20 > > From: Stoecker, Paul > > Sent: Sunday, February 03, 2013 8:26 PM > > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > > Subject: Re: [mile] IOCs > >=20 > > What if we added indicator group ID along with the indicator_uid? =20= > > This would allow you to group indicators that are related into the=20= > > same group ID. > > Would this resolve the issue? > >=20 > > It is either that or going back to adding a Detection (or = Indicators)=20 > > class that will should be used to take all of the indicators put = them=20 > > into one place and have the ability to group the ones that go=20 > > together. I don't mean a place to put indicators that are missing=20= > > from IODEF.I mean a place in the IODEF document where you put the=20 > > indicators that are used for detection and prevention of the shared=20= > > Incident. I don't know the answer here, but there has got to be a=20= > > good way for indicators to be identified and being able to group = them=20 > > as Chris has suggested without basically recreating something=20 > > complicated like STIX. > >=20 > > Paul > >=20 > >=20 > > Paul W. Stoecker, Ph.D. > > SMC Lead Content Architect > > RSA, The Security Division of EMC > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > >=20 > >=20 > > From: , Kathleen > > Date: Sunday, February 3, 2013 5:11 PM > > To: "Harrington, Christopher" , MILE=20= > > IETF > > Subject: Re: [mile] IOCs > >=20 > > Hi Chris, > >=20 > > I agree, we have some work to do in the updated IODEF, RFC5070-bis. > >=20 > > The list has already said they would like to see indicators added to=20= > > the definitions in RFC5070-bis, to be more explicit about including=20= > > indicators and sets of indicators in IODE documents as opposed to=20 > > 'parts of an incident or the useful information on an incident for=20= > > sharing purposes. It was written before we used terms like=20 > > indicators. With that in mind, Rosella proposed a number of changes=20= > > back in July, both for guidance and for > format > > updates. It may help to have the first draft try to address at = least=20 > > some of these issues so people can understand the problems and at=20 > > least a proposed solution. > >=20 > > As you point out, we need to be able to show relationships between=20= > > sets of indicators, where we may have a few sets of indicators that=20= > > could have a relationship to each other within a document. In the=20= > > July presentation, one of the questions was to see if we should add=20= > > new category attribute values for the System class that would = connect=20 > > the list of included indicators. I think we should still keep the=20= > > concept of a Node to a single node, but perhaps within System, list=20= > > multiple sets of Nodes that may be one type of attack. Rosella had=20= > > suggested pulling forward the "FraudType" from RFC5901, this would=20= > > help solve the issue as NodeRole values would compliment an = AttackType=20 > > (FraudType values could be included in AttackType or some broader=20 > > term). It may be better to have the FraudTypes, plus attribute = values=20 > > like "C2-server", "sinkhole", "MalwareDistribution" for added = context=20 > > so you know what to do with the received set of indicators. > >=20 > > I am proposing that we change IODEF to include multiple sets of > indicators, > > add an AttackType attribute (or some other name), a method to = connect=20 > > indicators and indicator sets within an IODEF using an attribute of=20= > > indicator_uid (or some other name) with a string value to make the=20= > > connection points, and add a few indicators that are commonly shared=20= > > into the base IODEF. > >=20 > > Back in July, we talked about adding Registry Key/Value pairs and=20 > > hashes to the main IODEF document (trying to see if this will help=20= > > Chris below). What if we added the Registry Key/Value pairs as a=20 > > class off of RecordData, using a similar structure to what is in=20 > > RFC5901, and also added the ability to include hashes in RecordData? = =20 > > I think if we then had the indicator_uid at the RecordData level, we=20= > > could connect a set within that structure and repeat the structure = for=20 > > other sets in the same way we would do with Node inside of the = System=20 > > class, using the indicator_uid to tie the set together. Then at the=20= > > more specific level for the hash, registry Key/value, IP, etc. use = an=20 > > indicator_uid if we needed them marked at this level as well? Maybe=20= > > we want indicator_set at the higher level? I'd like some opinions = on=20 > > this approach. +1 if you agree, suggestions if you have other ideas=20= > > that may work better. > >=20 > > We'll also need to worry about marking the indicators to prevent=20 > > forward sharing when not permitted. We may want to use these values=20= > > or something else. > >=20 > > Thank you! > > Kathleen > >=20 > > From: Harrington, Christopher > > Sent: Friday, February 01, 2013 12:01 PM > > To: Moriarty, Kathleen; MILE IETF > > Subject: RE: [mile] IOCs > >=20 > > I think we have a bigger relationship issue to address. Let use the=20= > > Watchlist Use Case. A bunch of indicators are sent in one message. = In=20 > > that message we could have groupings of indicators that we need to=20= > > show are > > related: > >=20 > > Two or more indicators of different type that relate to the same = threat: > > The file hash of a malicious file and the URL of the C2 that=20= > > the file uses. Either or both may be present to indicate a = compromise. > >=20 > > Two or more indicators of the same type that relate to the same = threat: > > 2 different registry values for the same registry key. If=20 > > either value is present it is a compromise indicator but both will = not=20 > > be > present. > >=20 > > The problem compounds itself very quickly. Consider the scenario = where=20 > > both groupings above are part of the same threat. I need to show = that=20 > > logical groupings of Indicators are related as well. We can't send=20= > > multiple IODEF messages for this from what I remember reading. > >=20 > > The last one I can think of would be when you have 2 different=20 > > indicators that represent the same indicator. It's not uncommon to=20= > > send both the > > MD5 > > and SHA1 hash of a malicious file. The indicator is the file but the=20= > > IOCs are the 2 hash values. How do we show they are related? If we = use=20 > > a unique Inidcator ID for each hash value there needs to be a higher=20= > > level > grouping. > >=20 > > Thoughts? > >=20 > > Thanks, > >=20 > > --Chris > >=20 > > Christopher Harrington > > Consulting Security Engineer > > GSO - Critical Incident Response Center EMC - Where Information = Lives > > 174 Middlesex Turnpike > > Bedford, MA 01730 > > 781-515-5862 (work) > > 603-583-1585 (cell) > >=20 > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= > > Of Moriarty, Kathleen > > Sent: Friday, February 01, 2013 11:28 AM > > To: MILE IETF > > Subject: Re: [mile] IOCs > >=20 > > All - > >=20 > > I'd like your input and will refocus the thread to get opinions from=20= > > the list on options to help solve the problems raised in my message=20= > > and additionally in Paul's message. > >=20 > > Interesting point, C. Henry. Our objective here is to have machine=20= > > automated exchanges, so we rely on encryption rather than = obfuscation=20 > > to achieve the necessary level of confidentiality. > >=20 > > Paul mentioned the need to distinguish indicators of compromise from=20= > > context information that may also include IP address or other data=20= > > that could be indicators. The question I raised was on how to = connect=20 > > sets of indicators in the same IODEF document, assuming the ability = to=20 > > have watchlists that could have several sets of indicators included,=20= > > as well as to connect indicators that may be included in embedded=20 > > schemas. > >=20 > > If we add an attribute on all of the relevant indicators, let's say=20= > > 'indicator-uid' how do we mark the indicators? Do we use this to = mark=20 > > who sent the indicator as well so that we can prevent forward = sharing=20 > > when it is not permitted or handle that separately? > >=20 > > Then for indicators not included in the base schema that may not fit=20= > > into a category in the SCI draft, do we create a place for these off=20= > > of SCI or right off of the IODE schema in EventData? (more details = on=20 > > this in my first message). > >=20 > > Comments and questions encouraged to figure out the right technical=20= > > solution to have this machine automatable. > >=20 > > Thank you, > > Kathleen > >=20 > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= > > Of C. > > Henry Adams & BIE > > Sent: Monday, January 28, 2013 11:25 PM > > To: MILE IETF > > Subject: Re: [mile] IOCs > >=20 > > Temporal Dependency sounds interesting. I remember when I first ran=20= > > across this particular craft, an experienced colleague asked me a=20 > > peculiar question. He said, " How do you stop someone from tracking=20= > > the IP Address to your computer?" > >=20 > > I replied, "I don't know, how?" > >=20 > > Then he said, "Cut the dog-gone thing off and the modem that it is > > connected- which is constantly on!" LOL > >=20 > > Here's my point (Hypothetical Situation) : There is a 1st Responder=20= > > searching a Neighborhood for Survivors which were hit by a Disaster = or=20 > > let's just say "Live" Terrorist Situation. He /or She needs to=20 > > communication back to other Officials that he /or somehow is in=20 > > Danger. The device used to communicate has been captured by the = great=20 > > minds of the enemy. It's only a matter of time before they utilize=20= > > reverse engineering to figure out how it functions. However, their=20= > > pride comes before a fall when seeking the location of other similar=20= > > devices to attack. Why? Perhaps the less thought of concepts that=20= > > makes the device function properly, saves the day by disguise or=20 > > cutting it off (figuratively speaking). > >=20 > > Just a visionary thought. > >=20 > > C. Henry Adams > > chenryadams@biemediagroup.com > > http://biemediagroup.com > >=20 > >=20 > > The information contained herein is for the exclusive use of the=20 > > original recipient. This information is granted for limited=20 > > distribution within the recipient's place of business for planning=20= > > purposes only. Further dissemination, whether private or public is=20= > > prohibited. > >=20 > > --- On Mon, 1/28/13, Dave Misell wrote: > >=20 > > From: Dave Misell > > Subject: Re: [mile] IOCs > > To: "C. Henry Adams & BIE" > > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with = DNS=20 > > SEC a pemanent and temporal key, with a temporal Id? > >=20 > > Yours Faithfully, > >=20 > > Dave Misell MSc CISSP > > SilentCircle dsm > > 07710 380044 > > david.misell@bcs.org > >=20 > >=20 > > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE = > > wrote: > >=20 > > > Serialization of a particular Lists of XML Classes in a unique way=20= > > > was > > closely related to what I attempted to express when I stated,=20 > > "consider to a degree what appears to be illogical in brilliant = minds=20 > > in some instances." > > > > > > However, I see Dr. Stoecker's point a little clearer. However, it=20= > > > would > > be nice if the UID was in some way disguised from those who study = this=20 > > Security Art Form in a negative way. > > > > > > C. Henry Adams > > > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > > > > > > > > > The information contained herein is for the exclusive use of the > > > original > > recipient. This information is granted for limited distribution = within > > the > > recipient's place of business for planning purposes only. Further > > dissemination, whether private or public is prohibited. > > > > > > Re: [mile] IOCs > > > > > > Sunday, January 27, 2013 8:52 PM > > > From: > > > "Stoecker, Paul" > > > To: > > > "mile@ietf.org" > > > I would like to look at this from a slightly different > > > perspective=8Alet's say I get an XML document that tells me about = an > > > incident. This document has source IP and destination IP that is > > > being shared. However, what I don't know is which IP address is = my > > > indicator and which is just a contextual piece of information. = This > > > means that my detection product isn't going to know which one to = use > > > either, because there is nothing to tell me which IP is the one, = even > > > if the roles are set it still might not be enough to tell my = system > > which > > one I should use as the indicator. > > > > > > If we had something like indicator_id as an attribute, it would = allow > > > us to easily identify indicators from contextual data. I do admit = to > > > being biased as I have spent much of my career working on the > > > monitoring and detection side of these things, so I am just = thinking > > > of ways to make it very clear what the indicators are in the XML > > > document and the other data that may be important as I investigate > > > activity that I have detected off of those indicators. > > > > > > > > > I did suggest the detection class, but I think we may get more > > > flexibility with the indicator_uid. One thing that I haven't > > > considered is the UID portion of this=8Ahow do we use that UID? = How is > > > the UID created? Are there standards for UIDs? > > > > > > Regards, > > > > > > Paul > > > > > > > > > > > > Paul W. Stoecker, Ph.D. > > > SMC Lead Content Architect > > > RSA, The Security Division of EMC > > > cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > > > --- On Sat, 1/26/13, C. Henry Adams & BIE = wrote: > > > > > > From: C. Henry Adams & BIE > > > Subject: RE: [mile] IOCs > > > To: "KathleenMoriarty" > > > Cc: mile@ietf.org > > > Date: Saturday, January 26, 2013, 6:17 PM > > > > > > Greetings Kathleen, > > > > > > Your logic stimulates my visionary brain because I'm amazed at the > > > many > > avenues you review with this approach at once. However, could you = share > > a > > few advantages and disadvantages to the latter? > > > > > > > > -------------------------------------------------------------------- > > -------- > > ---------------------------------------------- > > > "we could continue to group items in logical places as is done now = in > > IODEF and then have the extension point for combined indicators via = SCI." > > > > > > > > -------------------------------------------------------------------- > > -------- > > --------------------------------------------- > > > > > > You pointed out what you consider to be logical places, but if I > > > wanted to > > protect information from parties capable of ascertaining it from = your > > logical places, perhaps we should also consider to a degree what = appears > > to > > be illogical in brilliant minds in some instances. > > > > > > > > > > > > C. Henry Adams > > > chatlga2000@yahoo.com (Direct Email) > > > chenryadams@biemediagroup.com > > > > > > The information contained herein is for the exclusive use of the > > > original > > recipient. This information is granted for limited distribution = within > > the > > recipient's place of business for planning purposes only. Further > > dissemination, whether private or public is prohibited. > > > > > > --- On Sat, 1/26/13, Moriarty, Kathleen = > > wrote: > > > > > > From: Moriarty, Kathleen > > > Subject: RE: [mile] IOCs > > > To: "C. Henry Adams & BIE" , = "mile@ietf.org" > > > > > Date: Saturday, January 26, 2013, 10:13 AM > > > > > > Hello C. Henry & others, > > > > > > Thanks for taking a look at this. We have a few considerations in > > > this > > email thread I would like to hear thoughts on (and there may be more = once > > RFC5070-bis is actively edited). > > > > > > The AdditionalData class and the RecordItem class both allow for > > > non-XML > > extensions. Where you place the extensions should be specific to = the > > logical grouping of the parent elements so you can understand more = about > > the > > included data in most cases. > > > > > > The Impact class can be used to provide context information on the > > included data of the report and also can include a confidence rating = on > > the > > report as a whole. Extensions related to impact would be one level = higher > > (at the moment) in the Assessment class using the AdditionalData = extension > > point. > > > > > > Take asked about including vulnerability information, I would = think > > > that > > would fit under the Vulnerability extension point of the SCI draft = in > > the > > Method class. He did ask about non-XML. RecordItem or = AdditionalData > > do > > allow for non-XML extension points, we could either have the SCI = draft > > handle these as well or have the extensions that are non-XML come = directly > > off the AdditionalData or RecordItem classes according to what makes = sense > > from a logical standpoint. > > > > > > As for my question, it was two-fold. > > > > > > Indicator based schemas have a reference number or a GUID for the > > > various > > indicators they share. If we are extending to embed other schemas = that > > include such reference or GUID identifiers, do we want to add an = attribute > > to the various elements in IODEF that could be indicators? Is this = enough > > to make the connections or is something else else needed? We could = add > > something like an Indicator_ID in RFC5070-bis which would then = correlate > > to > > the reference or GUID identifiers. > > > > > > Then the other question was on how to include indicators that are = not > > > in > > the base schema that may be related or have language with "and" "or" = to > > specify the relationships. In some cases, you will want to group = these > > indictors in one extension point, where they may fit logically in = multiple > > places if the relationships did not need to be shown in the data > > format. If > > we have cases like this where you need more complex representations, > > should > > we use one extension point via the SCI draft off of the EventData = class > > AdditionalData extension point? Opinions are needed here.... > > > > > > A few people have mentioned wanting to include some commonly = shared > > indictors into the base IODEF document. We could have a catch-all = class > > that does this and has an extension point off of it in EventData or = we > > could > > continue to group items in logical places as is done now in IODEF = and > > then > > have the extension point for combined indicators via SCI. I think I = like > > the latter approach. > > > > > > Thank you, > > > Kathleen > > > ________________________________________ > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = C. > > > Henry > > Adams & BIE [chatlga2000@yahoo.com] > > > Sent: Saturday, January 26, 2013 3:05 AM > > > To: mile@ietf.org > > > Cc: C. Henry Adams > > > Subject: Re: [mile] IOCs > > > > > > Greetings Everyone, > > > > > > Take mentioned two types of indicators based on the : > > > > > -------------------------------------------------------------------- > > -------- > > -------------------------- > > > 1) If the indicators are something like an XML-based alert/warning = of > > > information leakage, it could be an event that are conveyed in the > > > SCI's EventReport class, IMHO. > > > > > > 2) If the indicators are something like an non-XML ones, I guess = it > > > could > > be > > > conveyed without using SCI draft. > > > For instance, we could use Impact class of the base IODEF to = convey > > > the indicators. > > > We could for instance extend the list of indicators of the Impact > > > class, > > if > > > needed. > > > > > -------------------------------------------------------------------- > > -------- > > -------------------------- > > > > > > In doing so he pointed out the "Impact Class" > > > > > > Whereas, Kathleen stated, > > > > > > > > -------------------------------------------------------------------- > > -------- > > ------------------------- > > > For the discussion below, I was thinking more of combined set with > > relationships that may be included in a single extension point, so = that's > > why I was thinking about the EventData class, but there may be = better > > locations or a specific area within the EventData. > > > > > > Paul Stoecker had suggested a "Detection" class as a = consideration. > > > > > -------------------------------------------------------------------- > > -------- > > ------------------------ > > > > > > Kathleen thoughts related yet still with other indicators and the > > EventData Class. > > > > > > Is there a possible way to create a new XML class which encompass > > combining the EventData, Detection and base IODEF classes to = simplify > > this > > issue? > > > > > > > > > C. Henry Adams > > > chatlga2000@yahoo.com (Direct Email) > > > chenryadams@biemediagroup.com > > > > > > > > > The information contained herein is for the exclusive use of the > > > original > > recipient. This information is granted for limited distribution = within > > the > > recipient's place of business for planning purposes only. Further > > dissemination, whether private or public is prohibited. > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > >=20 > > > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Paul.Stoecker@rsa.com Wed Feb 13 04:14:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F1721F8881 for ; Wed, 13 Feb 2013 04:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8NTDWQVYRHZ for ; Wed, 13 Feb 2013 04:14:06 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0929E21F8880 for ; Wed, 13 Feb 2013 04:14:05 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DCE1N8005490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 07:14:04 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 13 Feb 2013 07:13:47 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DCDdl3017018; Wed, 13 Feb 2013 07:13:46 -0500 Received: from mx33a.corp.emc.com ([169.254.1.154]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Wed, 13 Feb 2013 07:13:39 -0500 From: "Stoecker, Paul" To: Brian Trammell Date: Wed, 13 Feb 2013 07:13:34 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J4448R+G80PyERrebAk419Xx+7g== Message-ID: References: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> <40C79581-1FCD-4471-AC7B-51066C20982C@tik.ee.ethz.ch> In-Reply-To: <40C79581-1FCD-4471-AC7B-51066C20982C@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 12:14:08 -0000 Q2FudCB3ZSBtYWtlIENvbmZpZGVuY2UgYSBMaXN0IHRoYXQgaGFzIG9ubHkgMyB2YWx1ZXM6ICBI aWdoLCBNZWRpdW0sIGFuZCBMb3c/ICBBbnkgb3RoZXIgdmFsdWUgbWVhbnMgdGhhdCB0aGUgRG9j dW1lbnQgd2lsbCBtb3QgdmFsaWRhdGUgYWdhaW5zdCB0aGUgc2NoZW1hLg0KDQpTZW50IGZyb20g bXkgaVBob25lDQoNCk9uIEZlYiAxMywgMjAxMywgYXQgMjoxNCBBTSwgIkJyaWFuIFRyYW1tZWxs IiA8dHJhbW1lbGxAdGlrLmVlLmV0aHouY2g+IHdyb3RlOg0KDQo+IEhpLCBLYXRobGVlbiwgYWxs LA0KPg0KPiBJIHRoaW5rIDMuMTAuNCBpbiA1MDcwIHRha2VzIHRoZSByaWdodCBhcHByb2FjaCBo ZXJlOiB0cnlpbmcgdG8gYnVpbGQgaW50ZXJvcGVyYWJsZSBudW1lcmljIHNjYWxlcyBmb3IgYXNz ZXNzbWVudCBpcyBhIHZlcnkgaGFyZCBwcm9ibGVtLiAoV2VyZSBJIGNoYXJnZWQgd2l0aCBkZWZp bmluZyBzdWNoIGEgc2NhbGUsIHRoZSB2YWx1ZSAiNzAiIHdvdWxkIG1lYW4gIndlIGNvbXBhcmVk IHRoaXMgaW5jaWRlbnQgcmVwb3J0IHRvIE4gcGFzdCBzaW1pbGFyIGluY2lkZW50IHJlcG9ydHMg YWNjb3JkaW5nIHRvIHNpbWlsYXJpdHkgYWxnb3JpdGhtIFMsIGFuZCA3MCUgb2YgdGhlIHBhc3Qg cmVwb3J0cyBoYWQgYXNzZXNzZWQgaW1wYWN0cyB3aXRoaW4gRSUgb2YgdGhlIGFjdHVhbCwgbWVh c3VyZWQgZmluYWwgaW1wYWN0IC0tIEkgdGhpbmsgZm9yIG1vc3QgYXBwbGljYXRpb25zIHRoaXMg aXMgdmFzdGx5IG1vcmUgZGlmZmljdWx0IGFuZCByaWdvcm91cyB0aGFuIGl0IG5lZWRzIHRvIGJl LikNCj4NCj4gVW5sZXNzIGEgbnVtZXJpYyBDb25maWRlbmNlIHZhbHVlIGlzIGJhc2VkIG9uIHNv bWUgYWN0dWFsLCByZXBlYXRhYmx5IG1lYXN1cmFibGUgYXNwZWN0IG9mIHRoZSBBc3Nlc3NtZW50 IHJlcG9ydCAtLSB3aGljaCBJIHN1c3BlY3QgaW4gbWFueS9tb3N0L2FsbCBjYXNlcyBpdCdzIG5v dCAtLSB0aGVuIGl0IGp1c3QgcmVwcmVzZW50cyBhIGd1ZXNzLCBob3dldmVyIGVkdWNhdGVkLiAg RWFjaCB0ZWFtIHdpbGwgcHJvYmFibHkgbmF0dXJhbGx5IHR1bmUgaXRzIG93biBzY2FsZXMgc3Vj aCB0aGF0IGVhY2ggdmFsdWUgZ2VuZXJhbGx5IG1lYW5zIHRoZSBzYW1lIHRoaW5nIGluIGVhY2gg cmVwb3J0LiBBY3Jvc3MgdGVhbXMsIEkgZG9uJ3Qga25vdy4NCj4NCj4gT24gdGhlIG90aGVyIGhh bmQsIEFzc2Vzc21lbnRzIGFyZSBieSB0aGVpciB2ZXJ5IG5hdHVyZSBlZHVjYXRlZCBndWVzc2Vz LCBhbnl3YXksIHNvIEkgZG9uJ3Qga25vdyB0aGF0IEknZCBmaW5kIG11Y2ggdXNlIGluIGF1dG9t YXRpbmcgYSByZXNwb25zZSBiYXNlZCBvbiB0aGUgYXNzZXNzbWVudCBjb25maWRlbmNlLiBDaHJp cyBoYXMgYSBnb29kIHBvaW50LCB0aG91Z2ggLS0gaXQgbWFrZXMgc2VhcmNoaW5nIGRpZmZpY3Vs dCBhbmQgc29ydGluZyBraW5kIG9mIHBvaW50bGVzcy4NCj4NCj4gSWYgd2UndmUgc2VlbiBhIGdl bmVyYWwgdHJlbmQgdG93YXJkICIwID0gMCUsIDEwMCA9IDEwMCUiLCB0aGVuIEkgYWdyZWUsIHdl IHNob3VsZCBwdXQgdGhhdCBpbiB0aGUgZ3VpZGFuY2UgZG9jdW1lbnQgKGFsb25nIHdpdGggYSBu b3RlIHRoYXQgMC0zMyBtYXAgdG8gbG93LCAzNCAtIDY2IG1hcCB0byBtZWRpdW0sIGFuZCA2NyAt IDEwMCBtYXAgdG8gaGlnaCwgdW5sZXNzIHdlIHdhbnQgdG8gZG8gaXQgbm9uLWxpbmVhcmx5KS4g SWYgdGhlIF92YXN0X21ham9yaXR5XyBvZiB0aGUgdXNlcnMgb2YgdGhpcyBmaWVsZCB1c2UgYSAx MDAtcG9pbnQgc2NhbGUgd2l0aCAxMDAgbWVhbmluZyAieWVzIiBhbmQgMCBtZWFuaW5nICJhbnkg cmVzZW1ibGFuY2UgdGhlc2UgdmFsdWVzIG1heSBoYXZlIHRvIGFjdHVhbCBmYWN0IGlzIHB1cmVs eSBjb2luY2lkZW50YWwiLCB0aGVuIGxldCdzIGNvbnNpZGVyIHJlbmFtaW5nIGl0ICJwZXJjZW50 IiBpbiA1MDcwLWJpcy4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBCcmlhbiAoYXMgY29udHJp YnV0b3IpDQo+DQo+DQo+IE9uIEZlYiAxMiwgMjAxMywgYXQgOTo1NiBQTSwgIk1vcmlhcnR5LCBL YXRobGVlbiIgPGthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+IHdyb3RlOg0KPg0KPj4gUGxlYXNl IHNlZSBzZWN0aW9uIDMuMTAuNCBvZiBSRkM1MDcwIGFzIGEgc3RhcnRpbmcgcG9pbnQuICBXZSBj YW4gY2hhbmdlIGl0IGlmIGl0IG5lZWRzIHRvIGJlIGNoYW5nZWQuICBUaGUgdmFsdWUgaXMgZm9y IGEgY29uZmlkZW5jZSByYXRpbmcgb24gdGhlIGluZGljYXRvcnMgc2hhcmVkLiAgVGhlIGRlZmlu aXRpb25zIG1heSBiZSBoZWxwZnVsIGZvciBhbnlvbmUgd2hvIHdhbnRzIHRvIHdvcmsgb24gdGhp cyBkaXNjdXNzaW9uLiAgSU9ERUYgaGFzIHZhcmlvdXMgbWFya2VycyB0aGF0IGNhbiBiZSB1c2Vk IGluIGEgY29tcGxpbWVudGFyeSB3YXkgd2l0aG91dCBjb25mbGF0aW5nIHRoZSBtYXJrZXJzIG1l YW5pbmcuDQo+Pg0KPj4gSSB0aGluayBzb21lIHBlb3BsZSB1c2luZyBJT0RFRiBmaW5kIHRoZSBu dW1lcmljYWwgdmFsdWVzIG1vcmUgaGVscGZ1bCwgYW5kIGl0IHdvdWxkIGJlIGdvb2QgdG8gdW5k ZXJzdGFuZCB3aGF0IHBlb3BsZSBoYXZlIGxlYXJuZWQgZnJvbSB1c2luZyB0aGUgY3VycmVudCBz dHJ1Y3R1cmUgKHdoYXQgd29ya3MvZG9lcyBub3Qgd29yaykuICBUaGUgc2NhbGVzIEkgaGF2ZSBz ZWVuIGFyZSAwLTEwMC4gIFRoZXJlIGlzIG9mIGNvdXJzZSBhIHN1YmplY3RpdmUgZWxlbWVudCB0 byBhc3NpZ25pbmcgYSBudW1lcmljYWwgdmFsdWUgdG8gdGhlIGNvbmZpZGVuY2UgYW5kIGl0IG1h eSB2YXJ5IGZyb20gZW50aXR5IHRvIGVudGl0eS4gIFdpdGggdGhpcyB0eXBlIG9mIHJhdGluZyB5 b3UgbWF5IG5lZWQgdG8gY29uc2lkZXIgd2hvIGl0IGNhbWUgZnJvbSBhbmQgaG93IHRoZXkgc2Nv cmVkIHRoZSBjb25maWRlbmNlIHJhdGluZyB0byBtYXAgdG8geW91ciBvd24gcmF0aW5nLiAgSXQg d291bGQgYmUgZ29vZCB0byBoZWFyIG1vcmUgdGhvdWdodHMgb24gdGhpcy4NCj4+DQo+PiBUaGFu a3MsDQo+PiBLYXRobGVlbg0KPj4NCj4+IEZyb206IEMuIEhlbnJ5IEFkYW1zICYgQklFIFttYWls dG86Y2hhdGxnYTIwMDBAeWFob28uY29tXQ0KPj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIs IDIwMTMgMjo0NiBQTQ0KPj4gVG86IE1JTEUgSUVURg0KPj4gQ2M6IE1vcmlhcnR5LCBLYXRobGVl bjsgJ1Rha2VzaGkgVGFrYWhhc2hpJzsgU3RvZWNrZXIsIFBhdWwNCj4+IFN1YmplY3Q6IFJlOiBb bWlsZV0gSU9Dcw0KPj4NCj4+DQo+PiBSZWdhcmRpbmcgdGhlIElPQ3Mgb3IgSW5kaWNhdG9ycyBv ZiBDb21wcm9taXNlLCBDaHJpcyBtYWRlIGEgdml0YWwgcG9pbnQuICBEaWZmZXJlbnQgQ29uZmlk ZW5jZSBsZXZlbHMgd2lsbCBjYXVzZSBjb25mdXNpb24uICBJdCBhcHBlYXJzIHRoYXQgdGhlcmUg bWF5YmUgYSBuZWVkIGZvciBzb21lIHR5cGUgb2Ygc2ltcGxpZmllZCBzdGFuZGFyZGl6YXRpb24g dG8gYmUgZXN0YWJsaXNoZWQgYmV0d2VlbiBhbGwgU2hhcmluZyBHcm91cHMgaW4gdGhpcyByZWdh cmQuDQo+Pg0KPj4gUGVyaGFwcyBudW1lcmljYWwgc2NvcmluZyBzZXQgYXQgbG93ZXIgdmFsdWVz IHNob3VsZCBleHByZXNzIGxldmVscyBvZiB1cmdlbmN5Lg0KPj4gKCBpLmUuICAxID0gTGVzcyBM aWtlbHksICAgMiA9IFByb2JhYmxlLCAgMyA9IEEgQ29uY2VybiwgIDQgPSAgVXJnZW50LCAgNSA9 IEltbWluZW50ICkNCj4+DQo+PiBUaGFua3MsDQo+PiBDLiBIZW5yeSBBZGFtcw0KPj4NCj4+DQo+ Pg0KPj4gSSBzZWUgc29tZSBjb25mdXNpb24gY29taW5nIGRvd24gdGhlIHBpa2UgaWYgd2Ugc3Rh cnQgdXNpbmcgQ29uZmlkZW5jZSB0aGUNCj4+IHdheSBpdCBpcyBzdXBwb3J0ZWQuIElmIEkgYW0g dXNpbmcgbG93L21lZC9oaWdoIGFuZCBzb21lb25lIHNlbmRzIG1lIGFuIElvQw0KPj4gd2l0aCBh IHNjb3JlIG9mIDcwLCB3aGF0IGRvZXMgdGhhdCBtZWFuIHRvIG1lPyBXaGF0IGlmIEkgYW0gdXNp bmcgYSBzY2FsZSBvZg0KPj4gMSB0byA0IGFuZCBzb21lb25lIGVsc2UgaXMgb24gYSBzY2FsZSBv ZiAxIHRvIDU/IFdlIGxvc2UgdGhlIGFiaWxpdHkgdG8NCj4+IGRlc2NyaWJlIHNvbWV0aGluZyB3 aXRoIGEgY29uc2lzdGVudCBsYW5ndWFnZS4gSXQgcmVhbGx5IGdldHMgdWdseSB3aGVuIHdlDQo+ PiBzdG9yZSBJb0MgZnJvbSBtdWx0aXBsZSBzb3VyY2VzLiBJIGhhdmUgY29uZmlkZW5jZSB2YWx1 ZXMgdGhhdCBhcmUgbnVtZXJpYw0KPj4gYXMgd2VsbCBhcyB0ZXh0LiAgTWFrZXMgc2VhcmNoaW5n IC8gc29ydGluZyB2ZXJ5IHByb2JsZW1hdGljLg0KPj4NCj4+IEF0IHRoaXMgcG9pbnQgd2UgaGF2 ZSB0byByb2xsIHdpdGggd2hhdCB3ZSBoYXZlLiBJIHdvdWxkIHN0cm9uZ2x5IHJlY29tbWVuZA0K Pj4gdGhhdCB3ZSByZXZpc2l0IHRoaXMgYXQgc29tZSBwb2ludC4NCj4+DQo+PiBUaGFua3MsDQo+ Pg0KPj4gLS1DaHJpcw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBNb3JpYXJ0eSwgS2F0aGxlZW4NCj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEz IDk6NTkgQU0NCj4+IFRvOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgJ1Rha2VzaGkgVGFrYWhh c2hpJzsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFDQo+PiBJRVRGJw0KPj4gU3ViamVjdDogUkU6IFtt aWxlXSBJT0NzDQo+Pg0KPj4gSGkgQ2hyaXMgJiBUYWtlLA0KPj4NCj4+IEknbGwganVzdCBmb2N1 cyBvbiB0aGUgY29uZmlkZW5jZSBzY29yaW5nLiAgUmlnaHQgbm93LCB0aGUgc2NoZW1hIGFsbG93 cyBmb3INCj4+IHlvdSB0byBlaXRoZXIgdXNlIGEgbnVtZXJpY2FsIHNjb3JlIE9SIHRoZSByYXRp bmdzIG9mIGxvdywgbWVkaXVtLCBhbmQgaGlnaC4NCj4+IERpZmZlcmVudCBzaGFyaW5nIGdyb3Vw cyBjYW4gZGVjaWRlIGhvdyB0aGV5IHdhbnQgdG8gc2hhcmUgdGhlIGRhdGEuICBJZg0KPj4gcGVv cGxlIHdlcmUgdG8gdXNlIHRoZSBudW1lcmljYWwgdmFsdWVzLCBJIGFncmVlIGl0IHdvdWxkIGJl IGhlbHBmdWwgdG8gaGF2ZQ0KPj4gZ3VpZGFuY2UuICBUaGlzIGNvdWxkIGdvIGluIHRoZSBJT0RF IGd1aWRhbmNlIGRvY3VtZW50Lg0KPj4NCj4+IEkgaGF2ZSBzZWVuIGV4YW1wbGVzIG9mIGN1cnJl bnQgdXNlcnMgdGhhdCB1c2UgZWFjaCBvZiB0aGUgYXBwcm9hY2hlcywgc28NCj4+IHdlJ2xsIG5l ZWQgdG8ga2VlcCB0aGUgb3B0aW9uIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhbmQgaXQg aXMgbmljZSB0bw0KPj4ga2VlcCBpbiBmbGV4aWJsZSBvcHRpb25zIHdoZXJlIHdlIGNhbi4NCj4+ DQo+PiBUaGFuayB5b3UsDQo+PiBLYXRobGVlbg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcg0KPj4gU2VudDogVHVlc2Rh eSwgRmVicnVhcnkgMTIsIDIwMTMgOToyMiBBTQ0KPj4gVG86ICdUYWtlc2hpIFRha2FoYXNoaSc7 IE1vcmlhcnR5LCBLYXRobGVlbjsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFIElFVEYnDQo+PiBTdWJq ZWN0OiBSRTogW21pbGVdIElPQ3MNCj4+DQo+PiBUaGUgbnVtYmVyIG9mIGluZGljYXRvcnMgd291 bGRuJ3QgbmVjZXNzYXJpbHkgZHJpdmUgdGhlIHVzZSBvZg0KPj4gaW5kaWNhdG9yX3NldF9pZC4g VGhlIHB1cnBvc2UgaXMgdG8gc2hvdyByZWxhdGlvbnNoaXAuIElmIEkgc2VudCAzIElQDQo+PiBh ZGRyZXNzZXMgdGhhdCB3ZXJlIHVzZWQgYXMgQzIgZm9yIDMgZGlmZmVyZW50IGNhbXBhaWducyBJ IHdvdWxkIGhhdmUNCj4+IHNlcGFyYXRlIGluZGljYXRvcl9zZXRfaWRzLCBlYWNoIHdpdGggb25l IG9mIHRoZSAzIEMyIElQcw0KPj4NCj4+IE15IHN1Z2dlc3Rpb24gd291bGQgYmUgYSBzaW1wbGUg bG93LCBtZWRpdW0sIGhpZ2guIEkgdGhpbmsgaWYgd2UgYnJlYWsgaXQNCj4+IGRvd24gdG8gbW9y ZSBsZXZlbHMgdGhhbiB0aGF0IHdlIHdvdWxkIG5lZWQgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiBz Y29yaW5nLA0KPj4gcmF0aW5nLCBldGMuIEkgdGhpbmsgbW9zdCBwZW9wbGUgc2hvdWxkIGJlIGFi bGUgdG8gdW5kZXJzdGFuZCBsb3cvbWVkL2hpZ2gNCj4+IHdpdGhvdXQgaGF2aW5nIHRvIGhhdmUg YSBtYXRoZW1hdGljYWwgbWV0aG9kIGZvciBhcnJpdmluZyBhdCB0aGUgbGV2ZWwuDQo+Pg0KPj4g TG93IC0gSSBhbSBub3Qgc3VyZQ0KPj4gTWVkaXVtIC0gSSBhbSByZWFzb25hYmx5IHN1cmUNCj4+ IEhpZ2ggLSBJIGFtIHZlcnkgc3VyZQ0KPj4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gLS1DaHJp cw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBUYWtlc2hpIFRh a2FoYXNoaSBbbWFpbHRvOnRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanBdDQo+PiBTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyA0OjIxIEFNDQo+PiBUbzogSGFycmluZ3RvbiwgQ2hy aXN0b3BoZXI7IE1vcmlhcnR5LCBLYXRobGVlbjsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFIElFVEYn DQo+PiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4+DQo+PiBSZWdhcmRpbmcgdGhlIGluZGlj YXRvcl9zZXRfaWQsIEkgYWdyZWUsIGl0IGlzIHVzZWZ1bCB3aGVuIHdlIG5lZWQgdG8gZGVhbA0K Pj4gd2l0aCBsYXJnZSBzZXRzIG9mIGluZGljYXRvcnMuDQo+PiBTaW5jZSBpbmRpY2F0b3Jfc2V0 X2lkIGF0dHJpYnV0ZSBpcyBvcHRpb25hbCAocmlnaHQ/KSwgaXQgY291bGQgYmUgb21pdHRlZA0K Pj4gaWYgd2UgbmVlZCB0byBkZWFsIHdpdGggb25seSBzbWFsbCBudW1iZXIgb2YgaW5kaWNhdG9y cy4NCj4+DQo+PiBSZWdhcmRpbmcgdGhlIHVzZSBjYXNlLCBJIGxpa2UgdGhlIGlkZWEgb2YgdXNp bmcgdGhlIGNvbmZpZGVuY2UgYXR0cmlidXRlDQo+PiBmb3IgdGhlIHJlYXNvbiBDaHJpcyBraW5k bHkgZGVzY3JpYmVkLg0KPj4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgYSBiaXQgbW9yZSBvbiB0aGlz OiBpcyBpdCBnb2luZyB0byBiZSBudW1lcmljYWw/IEZvcg0KPj4gaW5zdGFuY2UsIDEgbWVhbnMg Im5vIGNvbmZpZGVuY2UiIHdoaWxlIDUgbWVhbnMgInN0cm9uZyBjb25maWRlbmNlIiwgZXRjPw0K Pj4NCj4+IFRoYW5rIHlvdS4NCj4+IFRha2UNCj4+DQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gRnJvbTogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXIgW21haWx0bzpDaHJp c3RvcGhlci5IYXJyaW5ndG9uQGVtYy5jb21dDQo+Pj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAw OCwgMjAxMyA0OjExIEFNDQo+Pj4gVG86IE1vcmlhcnR5LCBLYXRobGVlbjsgVGFrZXNoaSBUYWth aGFzaGk7IFN0b2Vja2VyLCBQYXVsOyAnTUlMRSBJRVRGJw0KPj4+IFN1YmplY3Q6IFJFOiBbbWls ZV0gSU9Dcw0KPj4+DQo+Pj4gV2l0aCByZXNwZWN0IHRvIHR5aW5nIHRoaW5ncyBiYWNrIHRvIHRo cmVhdCBhY3RvcnMsIGZyb20gd2hhdCBJIGhhdmUNCj4+PiBzZWVuIGFuZCB1c2UgdGhpcyBpcyBh IGdlbmVyYWxseSBhY2NlcHRlZCBncm91cGluZzoNCj4+Pg0KPj4+IEluZGljYXRvciAtLT4gSW5k aWN0b3IgU2V0IC0tPiBDYW1wYWlnbiAtLT4gVGhyZWF0IEFjdG9yDQo+Pj4NCj4+PiBDYW1wYWln biBhbmQgVGhyZWF0IEFjdG9yIGFyZSB3aGVyZSBoYXZpbmcgYSAiQ29uZmlkZW5jZSIgYXR0cmli dXRlDQo+Pj4gd291bGQgYmUgYmVuZWZpY2lhbCBhcyBtYWtpbmcgdGhvc2UgYXNzb2NpYXRpb25z IGlzIG5vdCBhIHBlcmZlY3QNCj4+PiBzY2llbmNlIGJ5IGFueSBtZWFucy4NCj4+Pg0KPj4+IFRo YW5rcywNCj4+Pg0KPj4+IC0tQ2hyaXMNCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+PiBGcm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4NCj4+PiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMDcsIDIwMTMgMjowMCBQTQ0KPj4+IFRvOiBUYWtlc2hpIFRha2FoYXNoaTsg SGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7IFN0b2Vja2VyLCBQYXVsOyAnTUlMRQ0KPj4+IElFVEYn DQo+Pj4gU3ViamVjdDogUkU6IFttaWxlXSBJT0NzDQo+Pj4NCj4+PiBIaSBUYWtlICYgb3RoZXJz LA0KPj4+DQo+Pj4gVGhhbmtzIGZvciBjaGltaW5nIGluLCBJJ3ZlIGJlZW4gdGFsa2luZyBhYm91 dCB0aGlzIHdpdGggQ2hyaXMgYW5kIGENCj4+PiBmZXcgb3RoZXJzIG9uIHRoZWlyIHVzZSBjYXNl cyBhbmQgd291bGQgbGlrZSBtb3JlIG9waW5pb25zLiAgSSdsbA0KPj4+IHByb3ZpZGUgYW4gb3B0 aW9uIGJlbG93IGZyb20gd2hhdCB3ZSBoYXZlIGRpc2N1c3NlZCBmcm9tIGEgQ0lSQyB2aWV3DQo+ Pj4gcG9pbnQuICBXZSBhcmUgYWxzbyB3b25kZXJpbmcgaG93IHRvIGFsc28gcHJvdmlkZSBsb2dp YyBpbiBJT0RFRiB0aGF0DQo+Pj4gY291bGQgY3Jvc3Mgb3ZlciBpbnRvIFNDSSBhdHRhY2hlZCBz Y2hlbWFzIG9yIElPREVGIGV4dGVuc2lvbnMgKHRoZQ0KPj4+IHNvbHV0aW9ucyBtYXkgYWxsIHRp ZSB0b2dldGhlciB3aXRoIHRoaXMgZGlzY3Vzc2lvbiAtIG9yIHRoZXJlIG1heSBiZQ0KPj4+IGJl dHRlci9tb3JlIGVsZWdhbnQgc29sdXRpb25zIG90aGVycyB3b3VsZCBsaWtlIHRvIHByb3Bvc2Up Lg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBUYWtlc2hp IFRha2FoYXNoaSBbbWFpbHRvOnRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanBdDQo+Pj4gU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMDUsIDIwMTMgMTI6MDQgUE0NCj4+PiBUbzogSGFycmluZ3Rv biwgQ2hyaXN0b3BoZXI7IFN0b2Vja2VyLCBQYXVsOyBNb3JpYXJ0eSwgS2F0aGxlZW47ICdNSUxF DQo+Pj4gSUVURicNCj4+PiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4+Pg0KPj4+PiBJIGxp a2UgdGhpcyBkaXNjdXNzaW9uLg0KPj4+PiBJIGFncmVlLCBpdCB3b3VsZCBiZSBnb29kIGlkZWEg dG8gaGF2ZSBpbmRpY2F0b3IgaWRlbnRpZmllcnMgaW5zaWRlDQo+Pj4+IHRoZSBJT0MtcmVsYXRl ZCBjbGFzc2VzLg0KPj4+DQo+Pj4gS01NOiBBdCB0aGUgY2xhc3MgbGV2ZWwsIHdlIG1heSBoYXZl IHNldmVyYWwgaW5kaWNhdG9ycyBsaXN0ZWQgdGhhdA0KPj4+IHNob3VsZCBiZSB2aWV3ZWQgYXMg YSBzZXQgYW5kIG1heSBoYXZlIGFub3RoZXIgaW5zdGFuY2Ugb2YgdGhhdCBzYW1lDQo+Pj4gY2xh c3MgdGhhdCBpcyBhIHJlbGF0ZWQgaXNzdWUsIGJ1dCBhIHNlcGFyYXRlIHNldC4gIFdlIGNvdWxk IGFzIHlvdQ0KPj4+IHNheSwgbGlzdCB0aGUgaW5kaWNhdG9yIElEcyBjb25uZWN0ZWQgdGhyb3Vn aCB0aGUgcmVmZXJlbmNlIGNsYXNzLg0KPj4+IFRoZSBzZXQgSURzIG1pZ2h0IGdpdmUgdXMgb3Ro ZXIgd2F5cyB0byBncm91cCB0aGUgdmFsdWVzIHdoZW4gd2UgZ2V0DQo+Pj4gaW50byBsb2dpYyBh bmQgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHNldHMgb3IgaW5kaWNhdG9ycy4gIFRoaXMgY291bGQN Cj4+PiBhbHNvIGJlIGEgd2F5IHRvIGNvbm5lY3QgaW5kaWNhdG9ycyBvciBzZXRzIGFjcm9zcyBY TUwgZG9jdW1lbnRzIHRoYXQNCj4+PiBjb3VsZCBoYXZlIGJlZW4gc2hhcmVkIHByZXZpb3VzbHku ICBJZiB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2YNCj4+PiBpbmRpY2F0b3JzIGluIHRoZSBz ZXQsIHRoZW4gdGhpcyBiZWNvbWVzIHVzZWZ1bCwgZm9yIHNtYWxsZXIgc2V0cywgSQ0KPj4+IGFn cmVlIGl0IGRvZXNuJ3QgbWFrZSBhcyBtdWNoIHNlbnNlLg0KPj4+DQo+Pj4gV2hhdCBkbyBvdGhl cnMgdGhpbms/DQo+Pj4NCj4+Pj4+IFRoZW4gZm9yIGluZGljYXRvcnMgbm90IGluY2x1ZGVkIGlu IHRoZSBiYXNlIHNjaGVtYSB0aGF0IG1heSBub3QNCj4+Pj4+IGZpdCBpbnRvIGEgY2F0ZWdvcnkg aW4gdGhlIFNDSSBkcmFmdCwgZG8gd2UgY3JlYXRlIGEgcGxhY2UgZm9yDQo+Pj4+PiB0aGVzZSBv ZmYgb2YgU0NJIG9yIHJpZ2h0IG9mZiBvZiB0aGUgSU9ERSBzY2hlbWEgaW4gRXZlbnREYXRhPw0K Pj4+Pj4gKG1vcmUgZGV0YWlscw0KPj4+IG9uDQo+Pj4+PiB0aGlzIGluIG15IGZpcnN0IG1lc3Nh Z2UpLg0KPj4+Pg0KPj4+PiBJZiB3ZSBjb3VsZCBzZWUgYW55IGluZGljYXRvciBvZiBjb21wcm9t aXNlIGFzIGNvbXB1dGVyIGV2ZW50DQo+Pj4+IHJlY29yZCwgd2UgY291bGQgdXNlIFNDSTpFdmVu dFJlcG9ydCBjbGFzcyBhcyB0aGUgcGxhY2UgZm9yIHRoZQ0KPj4+PiBYTUwtYmFzZWQgSU9DcyB0 aGF0IGNvdWxkbid0IGZpdCBhbnl3aGVyZSBlbHNlLg0KPj4+DQo+Pj4gS01NOiBUaGF0IHNvdW5k cyBsaWtlIGEgZ29vZCBpZGVhIHRvIG1lLiAgVGhpcyBzaG91bGQgZ28gaW50byBndWlkYW5jZQ0K Pj4+IGluIHRoZSBTQ0kgZHJhZnQuICBEb2VzIGFueW9uZSBlbHNlIHdhbnQgdG8gd2VpZ2ggaW4/ DQo+Pj4NCj4+Pj4NCj4+Pj4gRm9yIHRoZSBub24tWE1MIElPQ3MsIHdlIGNvdWxkIHVzZSBSZWNv cmREYXRhIGNsYXNzLCBhcyBzdWdnZXN0ZWQuDQo+Pj4gS01NOiBTb3VuZHMgZ29vZCwgdGhhbmtz IQ0KPj4+DQo+Pj4+IEkgYWdyZWUgdG8gaGF2ZSBpbmRpY2F0b3JfdWlkLCBidXQgSSBhbSBub3Qg c3VyZSBhYm91dCB0aGUgbmVlZHMgb2YNCj4+Pj4gdGhlIGluZGljYXRvcl9zZXRfaWQuDQo+Pj4+ IEkgdW5kZXJzdGFuZCB3ZSBjb3VsZCBkbyBzb21lIGdyb3VwaW5nIG9mIGluZGl2aWR1YWwgaW5k aWNhdG9yX3VpZHMNCj4+Pj4gYW5kIGl0cyB1c2FiaWxpdHksIGJ1dCBJIGFtIG5vdCBzdXJlIHdo ZXRoZXIgd2UgZG8gbm90IGhhdmUgYW55DQo+Pj4+IG90aGVyIHdheSB0byBleHByZXNzIHRoZXNl IGdyb3VwaW5ncy4NCj4+Pj4gRm9yIGluc3RhbmNlLCAgYSBSZWZlcmVuY2UgY2xhc3MgcmVmZXJz IHRvIHNldmVyYWwgaW5kaWNhZHRvcl91aWRzLg0KPj4+IEluDQo+Pj4+IHRoaXMgY2FzZSwgdGhl eSBjb3VsZCBiZSwgaW4gYSBzZW5zZSwgZ3JvdXBlZC4gSXNuJ3QgaXQgZW5vdWdoPw0KPj4+DQo+ Pj4gS01NOiBJdCBtYXkgYmUsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0IGxhcmdlIHNldHMgb2Yg aW5kaWNhdG9ycyBvcg0KPj4+IHN1YnNlcXVlbnQgbWVzc2FnZXMgdGhhdCBhZGQgaW5kaWNhdG9y cyB0byBleGlzdGluZyBzZXRzPyAgV291bGQgdGhpcw0KPj4+IGhhcHBlbj8gIFdvdWxkIGl0IGJl IGVhc2llciB0byBleHByZXNzIHJlbGF0aW9uc2hpcHMgd2l0aCBzZXRzIG9mDQo+Pj4gaW5kaWNh dG9ycyBpbiBhZGRpdGlvbiB0byBpbmRpdmlkdWFsIGluZGljYXRvcnM/ICBCeSB1c2luZyB0aGlz LCBpdA0KPj4+IGNvdWxkIGdpdmUgdXMgYSB1bmlxdWUgd2F5IHRvIGFsc28gcHJvdmlkZSB0aGUg bG9naWMgYW5kIHJlbGF0aW9uc2hpcHMNCj4+PiBpbiBhIG5ldyBjbGFzcyBvZiBJT0RFRiBzbyB3 ZSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IGFkZGluZyBpdCBpbnRvDQo+Pj4gdGhlIGN1cnJl bnQNCj4+IHN0cnVjdHVyZS4NCj4+PiBJZiB0aGVyZSBhcmUgYmV0dGVyIHdheXMgdG8gaGFuZGxl IHRoYXQsIGFuZCBvdGhlcnMgY2FuIHByb3ZpZGUgc29tZQ0KPj4+IG9wdGlvbnMsIHRoYXQgd291 bGQgYmUgYXBwcmVjaWF0ZWQhDQo+Pj4NCj4+PiBUaGFuayB5b3UsDQo+Pj4gS2F0aGxlZW4NCj4+ Pg0KPj4+PiBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgYW55Ym9keSBjb3VsZCBzaGFyZSBleHBlcnRp c2Ugb24gdGhpcy4gVGhvdWdoDQo+Pj4gSQ0KPj4+PiB0aGluayBJIGhhdmUgcmVhZCBhbGwgdGhl IGVtYWlscyBpbiB0aGUgbGlzdCwgSSBtaWdodCBoYXZlDQo+Pj4+IG1pcy11bmRlcnN0b29kIHNv bWUgcG9pbnRzLg0KPj4+Pg0KPj4+PiBCeSB0aGUgd2F5LCBJIHRoaW5rIHRoZSBpbmRpY2F0b3Jf dWlkcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIFNDSQ0KPj4gY2xhc3NlcycNCj4+Pj4gYXR0cmli dXRlcyBzbyB0aGF0IHRoZXkgY2FuIGJlIGNvcnJlbGF0ZWQgd2l0aCBhbm90aGVyIGluZm9ybWF0 aW9uDQo+Pj4+IGFzDQo+Pj4gd2VsbC4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+IFRha2UNCj4+ Pg0KPj4+DQo+Pj4NCj4+PiBGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWxl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+IE9mIEhhcnJpbmd0b24sIENocmlzdG9w aGVyDQo+Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDUsIDIwMTMgNDoyNSBBTQ0KPj4+IFRv OiBTdG9lY2tlciwgUGF1bDsgTW9yaWFydHksIEthdGhsZWVuOyBNSUxFIElFVEYNCj4+PiBTdWJq ZWN0OiBSZTogW21pbGVdIElPQ3MNCj4+Pg0KPj4+IEkgdGhpbmsgc29tZSBzb3J0IG9mIGdyb3Vw IElEIHdvdWxkIGRvIHRoZSB0cmljay4gV2UgYWxzbyBuZWVkIGENCj4+PiBsb2dpY2FsIGFuZCAv IG9yIHNvbWV3aGVyZSB0byBzaG93IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGluZGljYXRvcnMuIElm DQo+Pj4gSSBnaXZlIHlvdQ0KPj4+IDINCj4+PiByZWdpc3RyeSBrZXlzIGRvIHRoZXkgYm90aCBo YXZlIHRvIGJlIHByZXNlbnQgdG8gYmUgYW4gaW5kaWNhdGlvbiBvZg0KPj4+IGNvbXByb21pc2Ug b3IgaXMgZWl0aGVyIG9uZSBieSB0aGVtc2VsdmVzIGFuIGluZGljYXRvcj8gQm90aCB3b3VsZA0K Pj4+IGhhdmUgdGhlIHNhbWUgZ3JvdXAgSUQgc2luY2UgdGhleSBhcmUgcmVsYXRlZC4NCj4+Pg0K Pj4+IFRoYW5rcywNCj4+PiAtLUNocmlzDQo+Pj4NCj4+PiBGcm9tOiBTdG9lY2tlciwgUGF1bA0K Pj4+IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMDMsIDIwMTMgODoyNiBQTQ0KPj4+IFRvOiBNb3Jp YXJ0eSwgS2F0aGxlZW47IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyBNSUxFIElFVEYNCj4+PiBT dWJqZWN0OiBSZTogW21pbGVdIElPQ3MNCj4+Pg0KPj4+IFdoYXQgaWYgd2UgYWRkZWQgaW5kaWNh dG9yIGdyb3VwIElEIGFsb25nIHdpdGggdGhlIGluZGljYXRvcl91aWQ/DQo+Pj4gVGhpcyB3b3Vs ZCBhbGxvdyB5b3UgdG8gZ3JvdXAgaW5kaWNhdG9ycyB0aGF0IGFyZSByZWxhdGVkIGludG8gdGhl DQo+Pj4gc2FtZSBncm91cCBJRC4NCj4+PiBXb3VsZCB0aGlzIHJlc29sdmUgdGhlIGlzc3VlPw0K Pj4+DQo+Pj4gSXQgaXMgZWl0aGVyIHRoYXQgb3IgZ29pbmcgYmFjayB0byBhZGRpbmcgYSBEZXRl Y3Rpb24gKG9yIEluZGljYXRvcnMpDQo+Pj4gY2xhc3MgdGhhdCB3aWxsIHNob3VsZCBiZSB1c2Vk IHRvIHRha2UgYWxsIG9mIHRoZSBpbmRpY2F0b3JzIHB1dCB0aGVtDQo+Pj4gaW50byBvbmUgcGxh Y2UgYW5kIGhhdmUgdGhlIGFiaWxpdHkgdG8gZ3JvdXAgdGhlIG9uZXMgdGhhdCBnbw0KPj4+IHRv Z2V0aGVyLiAgSSBkb24ndCBtZWFuIGEgcGxhY2UgdG8gcHV0IGluZGljYXRvcnMgdGhhdCBhcmUg bWlzc2luZw0KPj4+IGZyb20gSU9ERUYuSSBtZWFuIGEgcGxhY2UgaW4gdGhlIElPREVGIGRvY3Vt ZW50IHdoZXJlIHlvdSBwdXQgdGhlDQo+Pj4gaW5kaWNhdG9ycyB0aGF0IGFyZSB1c2VkIGZvciBk ZXRlY3Rpb24gYW5kIHByZXZlbnRpb24gb2YgdGhlIHNoYXJlZA0KPj4+IEluY2lkZW50LiAgSSBk b24ndCBrbm93IHRoZSBhbnN3ZXIgaGVyZSwgYnV0IHRoZXJlIGhhcyBnb3QgdG8gYmUgYQ0KPj4+ IGdvb2Qgd2F5IGZvciBpbmRpY2F0b3JzIHRvIGJlIGlkZW50aWZpZWQgYW5kIGJlaW5nIGFibGUg dG8gZ3JvdXAgdGhlbQ0KPj4+IGFzIENocmlzIGhhcyBzdWdnZXN0ZWQgd2l0aG91dCBiYXNpY2Fs bHkgcmVjcmVhdGluZyBzb21ldGhpbmcNCj4+PiBjb21wbGljYXRlZCBsaWtlIFNUSVguDQo+Pj4N Cj4+PiBQYXVsDQo+Pj4NCj4+Pg0KPj4+IFBhdWwgVy4gU3RvZWNrZXIsIFBoLkQuDQo+Pj4gU01D IExlYWQgQ29udGVudCBBcmNoaXRlY3QNCj4+PiBSU0EsIFRoZSBTZWN1cml0eSBEaXZpc2lvbiBv ZiBFTUMNCj4+PiBjZWxsOiAzMDIuMzc5LjMzNzUgfCBlOiBwYXVsLnN0b2Vja2VyQHJzYS5jb20N Cj4+Pg0KPj4+DQo+Pj4gRnJvbTogPE1vcmlhcnR5PiwgS2F0aGxlZW4gPGthdGhsZWVuLm1vcmlh cnR5QGVtYy5jb20+DQo+Pj4gRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAzLCAyMDEzIDU6MTEgUE0N Cj4+PiBUbzogIkhhcnJpbmd0b24sIENocmlzdG9waGVyIiA8Q2hyaXN0b3BoZXIuSGFycmluZ3Rv bkBlbWMuY29tPiwgTUlMRQ0KPj4+IElFVEYgPG1pbGVAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDog UmU6IFttaWxlXSBJT0NzDQo+Pj4NCj4+PiBIaSBDaHJpcywNCj4+Pg0KPj4+IEkgYWdyZWUsIHdl IGhhdmUgc29tZSB3b3JrIHRvIGRvIGluIHRoZSB1cGRhdGVkIElPREVGLCBSRkM1MDcwLWJpcy4N Cj4+Pg0KPj4+IFRoZSBsaXN0IGhhcyBhbHJlYWR5IHNhaWQgdGhleSB3b3VsZCBsaWtlIHRvIHNl ZSBpbmRpY2F0b3JzIGFkZGVkIHRvDQo+Pj4gdGhlIGRlZmluaXRpb25zIGluIFJGQzUwNzAtYmlz LCB0byBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IGluY2x1ZGluZw0KPj4+IGluZGljYXRvcnMgYW5k IHNldHMgb2YgaW5kaWNhdG9ycyBpbiBJT0RFIGRvY3VtZW50cyBhcyBvcHBvc2VkIHRvDQo+Pj4g J3BhcnRzIG9mIGFuIGluY2lkZW50IG9yIHRoZSB1c2VmdWwgaW5mb3JtYXRpb24gb24gYW4gaW5j aWRlbnQgZm9yDQo+Pj4gc2hhcmluZyBwdXJwb3Nlcy4gIEl0IHdhcyB3cml0dGVuIGJlZm9yZSB3 ZSB1c2VkIHRlcm1zIGxpa2UNCj4+PiBpbmRpY2F0b3JzLiAgV2l0aCB0aGF0IGluIG1pbmQsIFJv c2VsbGEgcHJvcG9zZWQgYSBudW1iZXIgb2YgY2hhbmdlcw0KPj4+IGJhY2sgaW4gSnVseSwgYm90 aCBmb3IgZ3VpZGFuY2UgYW5kIGZvcg0KPj4gZm9ybWF0DQo+Pj4gdXBkYXRlcy4gIEl0IG1heSBo ZWxwIHRvIGhhdmUgdGhlIGZpcnN0IGRyYWZ0IHRyeSB0byBhZGRyZXNzIGF0IGxlYXN0DQo+Pj4g c29tZSBvZiB0aGVzZSBpc3N1ZXMgc28gcGVvcGxlIGNhbiB1bmRlcnN0YW5kIHRoZSBwcm9ibGVt cyBhbmQgYXQNCj4+PiBsZWFzdCBhIHByb3Bvc2VkIHNvbHV0aW9uLg0KPj4+DQo+Pj4gQXMgeW91 IHBvaW50IG91dCwgd2UgbmVlZCB0byBiZSBhYmxlIHRvIHNob3cgcmVsYXRpb25zaGlwcyBiZXR3 ZWVuDQo+Pj4gc2V0cyBvZiBpbmRpY2F0b3JzLCB3aGVyZSB3ZSBtYXkgaGF2ZSBhIGZldyBzZXRz IG9mIGluZGljYXRvcnMgdGhhdA0KPj4+IGNvdWxkIGhhdmUgYSByZWxhdGlvbnNoaXAgdG8gZWFj aCBvdGhlciB3aXRoaW4gYSBkb2N1bWVudC4gIEluIHRoZQ0KPj4+IEp1bHkgcHJlc2VudGF0aW9u LCBvbmUgb2YgdGhlIHF1ZXN0aW9ucyB3YXMgdG8gc2VlIGlmIHdlIHNob3VsZCBhZGQNCj4+PiBu ZXcgY2F0ZWdvcnkgYXR0cmlidXRlIHZhbHVlcyBmb3IgdGhlIFN5c3RlbSBjbGFzcyB0aGF0IHdv dWxkIGNvbm5lY3QNCj4+PiB0aGUgbGlzdCBvZiBpbmNsdWRlZCBpbmRpY2F0b3JzLiAgSSB0aGlu ayB3ZSBzaG91bGQgc3RpbGwga2VlcCB0aGUNCj4+PiBjb25jZXB0IG9mIGEgTm9kZSB0byBhIHNp bmdsZSBub2RlLCBidXQgcGVyaGFwcyB3aXRoaW4gU3lzdGVtLCBsaXN0DQo+Pj4gbXVsdGlwbGUg c2V0cyBvZiBOb2RlcyB0aGF0IG1heSBiZSBvbmUgdHlwZSBvZiBhdHRhY2suICBSb3NlbGxhIGhh ZA0KPj4+IHN1Z2dlc3RlZCBwdWxsaW5nIGZvcndhcmQgdGhlICJGcmF1ZFR5cGUiIGZyb20gUkZD NTkwMSwgdGhpcyB3b3VsZA0KPj4+IGhlbHAgc29sdmUgdGhlIGlzc3VlIGFzIE5vZGVSb2xlIHZh bHVlcyB3b3VsZCBjb21wbGltZW50IGFuIEF0dGFja1R5cGUNCj4+PiAoRnJhdWRUeXBlIHZhbHVl cyBjb3VsZCBiZSBpbmNsdWRlZCBpbiBBdHRhY2tUeXBlIG9yIHNvbWUgYnJvYWRlcg0KPj4+IHRl cm0pLiAgSXQgbWF5IGJlIGJldHRlciB0byBoYXZlIHRoZSBGcmF1ZFR5cGVzLCBwbHVzIGF0dHJp YnV0ZSB2YWx1ZXMNCj4+PiBsaWtlICJDMi1zZXJ2ZXIiLCAic2lua2hvbGUiLCAgIk1hbHdhcmVE aXN0cmlidXRpb24iIGZvciBhZGRlZCBjb250ZXh0DQo+Pj4gc28geW91IGtub3cgd2hhdCB0byBk byB3aXRoIHRoZSByZWNlaXZlZCBzZXQgb2YgaW5kaWNhdG9ycy4NCj4+Pg0KPj4+IEkgYW0gcHJv cG9zaW5nIHRoYXQgd2UgY2hhbmdlIElPREVGIHRvIGluY2x1ZGUgbXVsdGlwbGUgc2V0cyBvZg0K Pj4gaW5kaWNhdG9ycywNCj4+PiBhZGQgYW4gQXR0YWNrVHlwZSBhdHRyaWJ1dGUgKG9yIHNvbWUg b3RoZXIgbmFtZSksIGEgbWV0aG9kIHRvIGNvbm5lY3QNCj4+PiBpbmRpY2F0b3JzIGFuZCBpbmRp Y2F0b3Igc2V0cyB3aXRoaW4gYW4gSU9ERUYgdXNpbmcgYW4gYXR0cmlidXRlIG9mDQo+Pj4gaW5k aWNhdG9yX3VpZCAob3Igc29tZSBvdGhlciBuYW1lKSB3aXRoIGEgc3RyaW5nIHZhbHVlIHRvIG1h a2UgdGhlDQo+Pj4gY29ubmVjdGlvbiBwb2ludHMsIGFuZCBhZGQgYSBmZXcgaW5kaWNhdG9ycyB0 aGF0IGFyZSBjb21tb25seSBzaGFyZWQNCj4+PiBpbnRvIHRoZSBiYXNlIElPREVGLg0KPj4+DQo+ Pj4gQmFjayBpbiBKdWx5LCB3ZSB0YWxrZWQgYWJvdXQgYWRkaW5nIFJlZ2lzdHJ5IEtleS9WYWx1 ZSBwYWlycyBhbmQNCj4+PiBoYXNoZXMgdG8gdGhlIG1haW4gSU9ERUYgZG9jdW1lbnQgKHRyeWlu ZyB0byBzZWUgaWYgdGhpcyB3aWxsIGhlbHANCj4+PiBDaHJpcyBiZWxvdykuICBXaGF0IGlmIHdl IGFkZGVkIHRoZSBSZWdpc3RyeSBLZXkvVmFsdWUgcGFpcnMgYXMgYQ0KPj4+IGNsYXNzIG9mZiBv ZiBSZWNvcmREYXRhLCB1c2luZyBhIHNpbWlsYXIgc3RydWN0dXJlIHRvIHdoYXQgaXMgaW4NCj4+ PiBSRkM1OTAxLCBhbmQgYWxzbyBhZGRlZCB0aGUgYWJpbGl0eSB0byBpbmNsdWRlIGhhc2hlcyBp biBSZWNvcmREYXRhPw0KPj4+IEkgdGhpbmsgaWYgd2UgdGhlbiBoYWQgdGhlIGluZGljYXRvcl91 aWQgYXQgdGhlIFJlY29yZERhdGEgbGV2ZWwsIHdlDQo+Pj4gY291bGQgY29ubmVjdCBhIHNldCB3 aXRoaW4gdGhhdCBzdHJ1Y3R1cmUgYW5kIHJlcGVhdCB0aGUgc3RydWN0dXJlIGZvcg0KPj4+IG90 aGVyIHNldHMgaW4gdGhlIHNhbWUgd2F5IHdlIHdvdWxkIGRvIHdpdGggTm9kZSBpbnNpZGUgb2Yg dGhlIFN5c3RlbQ0KPj4+IGNsYXNzLCB1c2luZyB0aGUgaW5kaWNhdG9yX3VpZCB0byB0aWUgdGhl IHNldCB0b2dldGhlci4gIFRoZW4gYXQgdGhlDQo+Pj4gbW9yZSBzcGVjaWZpYyBsZXZlbCBmb3Ig dGhlIGhhc2gsIHJlZ2lzdHJ5IEtleS92YWx1ZSwgSVAsIGV0Yy4gdXNlIGFuDQo+Pj4gaW5kaWNh dG9yX3VpZCBpZiB3ZSBuZWVkZWQgdGhlbSBtYXJrZWQgYXQgdGhpcyBsZXZlbCBhcyB3ZWxsPyAg TWF5YmUNCj4+PiB3ZSB3YW50IGluZGljYXRvcl9zZXQgYXQgdGhlIGhpZ2hlciBsZXZlbD8gIEkn ZCBsaWtlIHNvbWUgb3BpbmlvbnMgb24NCj4+PiB0aGlzIGFwcHJvYWNoLiAgKzEgaWYgeW91IGFn cmVlLCBzdWdnZXN0aW9ucyBpZiB5b3UgaGF2ZSBvdGhlciBpZGVhcw0KPj4+IHRoYXQgbWF5IHdv cmsgYmV0dGVyLg0KPj4+DQo+Pj4gV2UnbGwgYWxzbyBuZWVkIHRvIHdvcnJ5IGFib3V0IG1hcmtp bmcgdGhlIGluZGljYXRvcnMgdG8gcHJldmVudA0KPj4+IGZvcndhcmQgc2hhcmluZyB3aGVuIG5v dCBwZXJtaXR0ZWQuICBXZSBtYXkgd2FudCB0byB1c2UgdGhlc2UgdmFsdWVzDQo+Pj4gb3Igc29t ZXRoaW5nIGVsc2UuDQo+Pj4NCj4+PiBUaGFuayB5b3UhDQo+Pj4gS2F0aGxlZW4NCj4+Pg0KPj4+ IEZyb206IEhhcnJpbmd0b24sIENocmlzdG9waGVyDQo+Pj4gU2VudDogRnJpZGF5LCBGZWJydWFy eSAwMSwgMjAxMyAxMjowMSBQTQ0KPj4+IFRvOiBNb3JpYXJ0eSwgS2F0aGxlZW47IE1JTEUgSUVU Rg0KPj4+IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KPj4+DQo+Pj4gSSB0aGluayB3ZSBoYXZl IGEgYmlnZ2VyIHJlbGF0aW9uc2hpcCBpc3N1ZSB0byBhZGRyZXNzLiBMZXQgdXNlIHRoZQ0KPj4+ IFdhdGNobGlzdCBVc2UgQ2FzZS4gQSBidW5jaCBvZiBpbmRpY2F0b3JzIGFyZSBzZW50IGluIG9u ZSBtZXNzYWdlLiBJbg0KPj4+IHRoYXQgbWVzc2FnZSB3ZSBjb3VsZCBoYXZlIGdyb3VwaW5ncyBv ZiBpbmRpY2F0b3JzIHRoYXQgd2UgbmVlZCB0bw0KPj4+IHNob3cgYXJlDQo+Pj4gcmVsYXRlZDoN Cj4+Pg0KPj4+IFR3byBvciBtb3JlIGluZGljYXRvcnMgb2YgZGlmZmVyZW50IHR5cGUgdGhhdCBy ZWxhdGUgdG8gdGhlIHNhbWUgdGhyZWF0Og0KPj4+ICAgICAgIFRoZSBmaWxlIGhhc2ggb2YgYSBt YWxpY2lvdXMgZmlsZSBhbmQgdGhlIFVSTCBvZiB0aGUgQzIgdGhhdA0KPj4+IHRoZSBmaWxlIHVz ZXMuIEVpdGhlciBvciBib3RoIG1heSBiZSBwcmVzZW50IHRvIGluZGljYXRlIGEgY29tcHJvbWlz ZS4NCj4+Pg0KPj4+IFR3byBvciBtb3JlIGluZGljYXRvcnMgb2YgdGhlIHNhbWUgdHlwZSB0aGF0 IHJlbGF0ZSB0byB0aGUgc2FtZSB0aHJlYXQ6DQo+Pj4gICAgICAgMiBkaWZmZXJlbnQgcmVnaXN0 cnkgdmFsdWVzIGZvciB0aGUgc2FtZSByZWdpc3RyeSBrZXkuIElmDQo+Pj4gZWl0aGVyIHZhbHVl IGlzIHByZXNlbnQgaXQgaXMgYSBjb21wcm9taXNlIGluZGljYXRvciBidXQgYm90aCB3aWxsIG5v dA0KPj4+IGJlDQo+PiBwcmVzZW50Lg0KPj4+DQo+Pj4gVGhlIHByb2JsZW0gY29tcG91bmRzIGl0 c2VsZiB2ZXJ5IHF1aWNrbHkuIENvbnNpZGVyIHRoZSBzY2VuYXJpbyB3aGVyZQ0KPj4+IGJvdGgg Z3JvdXBpbmdzIGFib3ZlIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIHRocmVhdC4gSSBuZWVkIHRvIHNo b3cgdGhhdA0KPj4+IGxvZ2ljYWwgZ3JvdXBpbmdzIG9mIEluZGljYXRvcnMgYXJlIHJlbGF0ZWQg YXMgd2VsbC4gV2UgY2FuJ3Qgc2VuZA0KPj4+IG11bHRpcGxlIElPREVGIG1lc3NhZ2VzIGZvciB0 aGlzIGZyb20gd2hhdCBJIHJlbWVtYmVyIHJlYWRpbmcuDQo+Pj4NCj4+PiBUaGUgbGFzdCBvbmUg SSBjYW4gdGhpbmsgb2Ygd291bGQgYmUgd2hlbiB5b3UgaGF2ZSAyIGRpZmZlcmVudA0KPj4+IGlu ZGljYXRvcnMgdGhhdCByZXByZXNlbnQgdGhlIHNhbWUgaW5kaWNhdG9yLiBJdCdzIG5vdCB1bmNv bW1vbiB0bw0KPj4+IHNlbmQgYm90aCB0aGUNCj4+PiBNRDUNCj4+PiBhbmQgU0hBMSBoYXNoIG9m IGEgbWFsaWNpb3VzIGZpbGUuIFRoZSBpbmRpY2F0b3IgaXMgdGhlIGZpbGUgYnV0IHRoZQ0KPj4+ IElPQ3MgYXJlIHRoZSAyIGhhc2ggdmFsdWVzLiBIb3cgZG8gd2Ugc2hvdyB0aGV5IGFyZSByZWxh dGVkPyBJZiB3ZSB1c2UNCj4+PiBhIHVuaXF1ZSBJbmlkY2F0b3IgSUQgZm9yIGVhY2ggaGFzaCB2 YWx1ZSB0aGVyZSBuZWVkcyB0byBiZSBhIGhpZ2hlcg0KPj4+IGxldmVsDQo+PiBncm91cGluZy4N Cj4+Pg0KPj4+IFRob3VnaHRzPw0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gLS1DaHJpcw0K Pj4+DQo+Pj4gQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbg0KPj4+IENvbnN1bHRpbmcgU2VjdXJpdHkg RW5naW5lZXINCj4+PiBHU08gLSBDcml0aWNhbCBJbmNpZGVudCBSZXNwb25zZSBDZW50ZXIgRU1D IC0gV2hlcmUgSW5mb3JtYXRpb24gTGl2ZXMNCj4+PiAxNzQgTWlkZGxlc2V4IFR1cm5waWtlDQo+ Pj4gQmVkZm9yZCwgTUEgMDE3MzANCj4+PiA3ODEtNTE1LTU4NjIgKHdvcmspDQo+Pj4gNjAzLTU4 My0xNTg1IChjZWxsKQ0KPj4+DQo+Pj4gRnJvbTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+PiBPZiBNb3JpYXJ0eSwgS2F0 aGxlZW4NCj4+PiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAxLCAyMDEzIDExOjI4IEFNDQo+Pj4g VG86IE1JTEUgSUVURg0KPj4+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPj4+DQo+Pj4gQWxs IC0NCj4+Pg0KPj4+IEknZCBsaWtlIHlvdXIgaW5wdXQgYW5kIHdpbGwgcmVmb2N1cyB0aGUgdGhy ZWFkIHRvIGdldCBvcGluaW9ucyBmcm9tDQo+Pj4gdGhlIGxpc3Qgb24gb3B0aW9ucyB0byBoZWxw IHNvbHZlIHRoZSBwcm9ibGVtcyByYWlzZWQgaW4gbXkgbWVzc2FnZQ0KPj4+IGFuZCBhZGRpdGlv bmFsbHkgaW4gUGF1bCdzIG1lc3NhZ2UuDQo+Pj4NCj4+PiBJbnRlcmVzdGluZyBwb2ludCwgQy4g SGVucnkuICBPdXIgb2JqZWN0aXZlIGhlcmUgaXMgdG8gaGF2ZSBtYWNoaW5lDQo+Pj4gYXV0b21h dGVkIGV4Y2hhbmdlcywgc28gd2UgcmVseSBvbiBlbmNyeXB0aW9uIHJhdGhlciB0aGFuIG9iZnVz Y2F0aW9uDQo+Pj4gdG8gYWNoaWV2ZSB0aGUgbmVjZXNzYXJ5IGxldmVsIG9mIGNvbmZpZGVudGlh bGl0eS4NCj4+Pg0KPj4+IFBhdWwgbWVudGlvbmVkIHRoZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGlu ZGljYXRvcnMgb2YgY29tcHJvbWlzZSBmcm9tDQo+Pj4gY29udGV4dCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBhbHNvIGluY2x1ZGUgSVAgYWRkcmVzcyBvciBvdGhlciBkYXRhDQo+Pj4gdGhhdCBjb3Vs ZCBiZSBpbmRpY2F0b3JzLiAgVGhlIHF1ZXN0aW9uIEkgcmFpc2VkIHdhcyBvbiBob3cgdG8gY29u bmVjdA0KPj4+IHNldHMgb2YgaW5kaWNhdG9ycyBpbiB0aGUgc2FtZSBJT0RFRiBkb2N1bWVudCwg YXNzdW1pbmcgdGhlIGFiaWxpdHkgdG8NCj4+PiBoYXZlIHdhdGNobGlzdHMgdGhhdCBjb3VsZCBo YXZlIHNldmVyYWwgc2V0cyBvZiBpbmRpY2F0b3JzIGluY2x1ZGVkLA0KPj4+IGFzIHdlbGwgYXMg dG8gY29ubmVjdCBpbmRpY2F0b3JzIHRoYXQgbWF5IGJlIGluY2x1ZGVkIGluIGVtYmVkZGVkDQo+ Pj4gc2NoZW1hcy4NCj4+Pg0KPj4+IElmIHdlIGFkZCBhbiBhdHRyaWJ1dGUgb24gYWxsIG9mIHRo ZSByZWxldmFudCBpbmRpY2F0b3JzLCBsZXQncyBzYXkNCj4+PiAnaW5kaWNhdG9yLXVpZCcgaG93 IGRvIHdlIG1hcmsgdGhlIGluZGljYXRvcnM/ICBEbyB3ZSB1c2UgdGhpcyB0byBtYXJrDQo+Pj4g d2hvIHNlbnQgdGhlIGluZGljYXRvciBhcyB3ZWxsIHNvIHRoYXQgd2UgY2FuIHByZXZlbnQgZm9y d2FyZCBzaGFyaW5nDQo+Pj4gd2hlbiBpdCBpcyBub3QgcGVybWl0dGVkIG9yIGhhbmRsZSB0aGF0 IHNlcGFyYXRlbHk/DQo+Pj4NCj4+PiBUaGVuIGZvciBpbmRpY2F0b3JzIG5vdCBpbmNsdWRlZCBp biB0aGUgYmFzZSBzY2hlbWEgdGhhdCBtYXkgbm90IGZpdA0KPj4+IGludG8gYSBjYXRlZ29yeSBp biB0aGUgU0NJIGRyYWZ0LCBkbyB3ZSBjcmVhdGUgYSBwbGFjZSBmb3IgdGhlc2Ugb2ZmDQo+Pj4g b2YgU0NJIG9yIHJpZ2h0IG9mZiBvZiB0aGUgSU9ERSBzY2hlbWEgaW4gRXZlbnREYXRhPyAobW9y ZSBkZXRhaWxzIG9uDQo+Pj4gdGhpcyBpbiBteSBmaXJzdCBtZXNzYWdlKS4NCj4+Pg0KPj4+IENv bW1lbnRzIGFuZCBxdWVzdGlvbnMgZW5jb3VyYWdlZCB0byBmaWd1cmUgb3V0IHRoZSByaWdodCB0 ZWNobmljYWwNCj4+PiBzb2x1dGlvbiB0byBoYXZlIHRoaXMgbWFjaGluZSBhdXRvbWF0YWJsZS4N Cj4+Pg0KPj4+IFRoYW5rIHlvdSwNCj4+PiBLYXRobGVlbg0KPj4+DQo+Pj4gRnJvbTogbWlsZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4+PiBPZiBDLg0KPj4+IEhlbnJ5IEFkYW1zICYgQklFDQo+Pj4gU2VudDogTW9uZGF5LCBKYW51 YXJ5IDI4LCAyMDEzIDExOjI1IFBNDQo+Pj4gVG86IE1JTEUgSUVURg0KPj4+IFN1YmplY3Q6IFJl OiBbbWlsZV0gSU9Dcw0KPj4+DQo+Pj4gVGVtcG9yYWwgRGVwZW5kZW5jeSBzb3VuZHMgaW50ZXJl c3RpbmcuICBJIHJlbWVtYmVyIHdoZW4gSSBmaXJzdCByYW4NCj4+PiBhY3Jvc3MgdGhpcyBwYXJ0 aWN1bGFyIGNyYWZ0LCBhbiBleHBlcmllbmNlZCBjb2xsZWFndWUgYXNrZWQgbWUgYQ0KPj4+IHBl Y3VsaWFyIHF1ZXN0aW9uLiAgSGUgc2FpZCwgIiBIb3cgZG8geW91IHN0b3Agc29tZW9uZSBmcm9t IHRyYWNraW5nDQo+Pj4gdGhlIElQIEFkZHJlc3MgdG8geW91ciBjb21wdXRlcj8iDQo+Pj4NCj4+ PiBJIHJlcGxpZWQsICJJIGRvbid0IGtub3csIGhvdz8iDQo+Pj4NCj4+PiBUaGVuIGhlIHNhaWQs ICJDdXQgdGhlIGRvZy1nb25lIHRoaW5nIG9mZiAgYW5kIHRoZSBtb2RlbSB0aGF0IGl0IGlzDQo+ Pj4gY29ubmVjdGVkLSB3aGljaCBpcyBjb25zdGFudGx5IG9uISIgICBMT0wNCj4+Pg0KPj4+IEhl cmUncyBteSBwb2ludCAoSHlwb3RoZXRpY2FsIFNpdHVhdGlvbikgOiAgVGhlcmUgaXMgYSAxc3Qg UmVzcG9uZGVyDQo+Pj4gc2VhcmNoaW5nIGEgTmVpZ2hib3Job29kIGZvciBTdXJ2aXZvcnMgd2hp Y2ggd2VyZSBoaXQgYnkgYSBEaXNhc3RlciBvcg0KPj4+IGxldCdzIGp1c3Qgc2F5ICJMaXZlIiBU ZXJyb3Jpc3QgU2l0dWF0aW9uLiAgSGUgL29yIFNoZSBuZWVkcyB0bw0KPj4+IGNvbW11bmljYXRp b24gYmFjayB0byBvdGhlciBPZmZpY2lhbHMgdGhhdCBoZSAvb3Igc29tZWhvdyBpcyBpbg0KPj4+ IERhbmdlci4gIFRoZSBkZXZpY2UgdXNlZCB0byBjb21tdW5pY2F0ZSBoYXMgYmVlbiBjYXB0dXJl ZCBieSB0aGUgZ3JlYXQNCj4+PiBtaW5kcyBvZiB0aGUgZW5lbXkuICBJdCdzIG9ubHkgYSBtYXR0 ZXIgb2YgdGltZSBiZWZvcmUgdGhleSB1dGlsaXplDQo+Pj4gcmV2ZXJzZSBlbmdpbmVlcmluZyB0 byBmaWd1cmUgb3V0IGhvdyBpdCBmdW5jdGlvbnMuICBIb3dldmVyLCB0aGVpcg0KPj4+IHByaWRl IGNvbWVzIGJlZm9yZSBhIGZhbGwgd2hlbiBzZWVraW5nIHRoZSBsb2NhdGlvbiBvZiBvdGhlciBz aW1pbGFyDQo+Pj4gZGV2aWNlcyB0byBhdHRhY2suICBXaHk/IFBlcmhhcHMgdGhlIGxlc3MgdGhv dWdodCBvZiBjb25jZXB0cyB0aGF0DQo+Pj4gbWFrZXMgdGhlIGRldmljZSBmdW5jdGlvbiBwcm9w ZXJseSwgc2F2ZXMgdGhlIGRheSBieSBkaXNndWlzZSBvcg0KPj4+IGN1dHRpbmcgaXQgb2ZmIChm aWd1cmF0aXZlbHkgc3BlYWtpbmcpLg0KPj4+DQo+Pj4gSnVzdCBhIHZpc2lvbmFyeSB0aG91Z2h0 Lg0KPj4+DQo+Pj4gQy4gSGVucnkgQWRhbXMNCj4+PiBjaGVucnlhZGFtc0BiaWVtZWRpYWdyb3Vw LmNvbQ0KPj4+IGh0dHA6Ly9iaWVtZWRpYWdyb3VwLmNvbQ0KPj4+DQo+Pj4NCj4+PiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl DQo+Pj4gb3JpZ2luYWwgcmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9y IGxpbWl0ZWQNCj4+PiBkaXN0cmlidXRpb24gd2l0aGluIHRoZSByZWNpcGllbnQncyBwbGFjZSBv ZiBidXNpbmVzcyBmb3IgcGxhbm5pbmcNCj4+PiBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyIGRpc3Nl bWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMNCj4+PiBwcm9oaWJpdGVkLg0K Pj4+DQo+Pj4gLS0tIE9uIE1vbiwgMS8yOC8xMywgRGF2ZSBNaXNlbGwgPGRhdmlkLm1pc2VsbEBi Y3Mub3JnPiB3cm90ZToNCj4+Pg0KPj4+IEZyb206IERhdmUgTWlzZWxsIDxkYXZpZC5taXNlbGxA YmNzLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW21pbGVdIElPQ3MNCj4+PiBUbzogIkMuIEhlbnJ5 IEFkYW1zICYgQklFIiA8Y2hhdGxnYTIwMDBAeWFob28uY29tPg0KPj4+IERhdGU6IE1vbmRheSwg SmFudWFyeSAyOCwgMjAxMywgOToyNSBQTSBVSUQgY291bGQgYmUgbWlycm9yZWQgd2l0aCBETlMN Cj4+PiBTRUMgYSBwZW1hbmVudCBhbmQgdGVtcG9yYWwga2V5LCB3aXRoIGEgdGVtcG9yYWwgSWQ/ DQo+Pj4NCj4+PiBZb3VycyBGYWl0aGZ1bGx5LA0KPj4+DQo+Pj4gRGF2ZSBNaXNlbGwgTVNjIENJ U1NQDQo+Pj4gU2lsZW50Q2lyY2xlICBkc20NCj4+PiAwNzcxMCAzODAwNDQNCj4+PiBkYXZpZC5t aXNlbGxAYmNzLm9yZw0KPj4+DQo+Pj4NCj4+PiBPbiAyOSBKYW4gMjAxMywgYXQgMDA6MzksIEMu IEhlbnJ5IEFkYW1zICYgQklFIDxjaGF0bGdhMjAwMEB5YWhvby5jb20+DQo+Pj4gd3JvdGU6DQo+ Pj4NCj4+Pj4gU2VyaWFsaXphdGlvbiBvZiBhIHBhcnRpY3VsYXIgTGlzdHMgb2YgWE1MIENsYXNz ZXMgaW4gYSB1bmlxdWUgd2F5DQo+Pj4+IHdhcw0KPj4+IGNsb3NlbHkgcmVsYXRlZCB0byB3aGF0 IEkgYXR0ZW1wdGVkIHRvIGV4cHJlc3Mgd2hlbiBJIHN0YXRlZCwNCj4+PiAiY29uc2lkZXIgdG8g YSBkZWdyZWUgd2hhdCBhcHBlYXJzIHRvIGJlIGlsbG9naWNhbCBpbiBicmlsbGlhbnQgbWluZHMN Cj4+PiBpbiBzb21lIGluc3RhbmNlcy4iDQo+Pj4+DQo+Pj4+IEhvd2V2ZXIsIEkgc2VlIERyLiBT dG9lY2tlcidzIHBvaW50IGEgbGl0dGxlIGNsZWFyZXIuICBIb3dldmVyLCBpdA0KPj4+PiB3b3Vs ZA0KPj4+IGJlIG5pY2UgaWYgdGhlIFVJRCB3YXMgaW4gc29tZSB3YXkgZGlzZ3Vpc2VkIGZyb20g dGhvc2Ugd2hvIHN0dWR5IHRoaXMNCj4+PiBTZWN1cml0eSBBcnQgRm9ybSBpbiBhIG5lZ2F0aXZl IHdheS4NCj4+Pj4NCj4+Pj4gQy4gSGVucnkgQWRhbXMNCj4+Pj4gY2hhdGxnYTIwMDBAeWFob28u Y29tIChEaXJlY3QgRW1haWwpIGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tDQo+Pj4+DQo+ Pj4+DQo+Pj4+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUNCj4+Pj4gb3JpZ2luYWwNCj4+PiByZWNpcGllbnQuIFRoaXMgaW5m b3JtYXRpb24gaXMgZ3JhbnRlZCBmb3IgbGltaXRlZCBkaXN0cmlidXRpb24gd2l0aGluDQo+Pj4g dGhlDQo+Pj4gcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1cnBv c2VzIG9ubHkuIEZ1cnRoZXINCj4+PiBkaXNzZW1pbmF0aW9uLCB3aGV0aGVyIHByaXZhdGUgb3Ig cHVibGljIGlzIHByb2hpYml0ZWQuDQo+Pj4+DQo+Pj4+IFJlOiBbbWlsZV0gSU9Dcw0KPj4+Pg0K Pj4+PiBTdW5kYXksIEphbnVhcnkgMjcsIDIwMTMgODo1MiBQTQ0KPj4+PiBGcm9tOg0KPj4+PiAi U3RvZWNrZXIsIFBhdWwiIDxQYXVsLlN0b2Vja2VyQHJzYS5jb20+DQo+Pj4+IFRvOg0KPj4+PiAi bWlsZUBpZXRmLm9yZyIgPG1pbGVAaWV0Zi5vcmc+DQo+Pj4+IEkgd291bGQgbGlrZSB0byBsb29r IGF0IHRoaXMgZnJvbSBhIHNsaWdodGx5IGRpZmZlcmVudA0KPj4+PiBwZXJzcGVjdGl2ZcWgbGV0 J3Mgc2F5IEkgZ2V0IGFuIFhNTCBkb2N1bWVudCB0aGF0IHRlbGxzIG1lIGFib3V0IGFuDQo+Pj4+ IGluY2lkZW50LiAgVGhpcyBkb2N1bWVudCBoYXMgc291cmNlIElQIGFuZCBkZXN0aW5hdGlvbiBJ UCB0aGF0IGlzDQo+Pj4+IGJlaW5nIHNoYXJlZC4gIEhvd2V2ZXIsIHdoYXQgSSBkb24ndCBrbm93 IGlzIHdoaWNoIElQIGFkZHJlc3MgaXMgbXkNCj4+Pj4gaW5kaWNhdG9yIGFuZCB3aGljaCBpcyBq dXN0IGEgY29udGV4dHVhbCBwaWVjZSBvZiBpbmZvcm1hdGlvbi4gIFRoaXMNCj4+Pj4gbWVhbnMg dGhhdCBteSBkZXRlY3Rpb24gcHJvZHVjdCBpc24ndCBnb2luZyB0byBrbm93IHdoaWNoIG9uZSB0 byB1c2UNCj4+Pj4gZWl0aGVyLCBiZWNhdXNlIHRoZXJlIGlzIG5vdGhpbmcgdG8gdGVsbCBtZSB3 aGljaCBJUCBpcyB0aGUgb25lLCBldmVuDQo+Pj4+IGlmIHRoZSByb2xlcyBhcmUgc2V0IGl0IHN0 aWxsIG1pZ2h0IG5vdCBiZSBlbm91Z2ggdG8gdGVsbCBteSBzeXN0ZW0NCj4+PiB3aGljaA0KPj4+ IG9uZSBJIHNob3VsZCB1c2UgYXMgdGhlIGluZGljYXRvci4NCj4+Pj4NCj4+Pj4gSWYgd2UgaGFk IHNvbWV0aGluZyBsaWtlIGluZGljYXRvcl9pZCBhcyBhbiBhdHRyaWJ1dGUsIGl0IHdvdWxkIGFs bG93DQo+Pj4+IHVzIHRvIGVhc2lseSBpZGVudGlmeSBpbmRpY2F0b3JzIGZyb20gY29udGV4dHVh bCBkYXRhLiAgSSBkbyBhZG1pdCB0bw0KPj4+PiBiZWluZyBiaWFzZWQgYXMgSSBoYXZlIHNwZW50 IG11Y2ggb2YgbXkgY2FyZWVyIHdvcmtpbmcgb24gdGhlDQo+Pj4+IG1vbml0b3JpbmcgYW5kIGRl dGVjdGlvbiBzaWRlIG9mIHRoZXNlIHRoaW5ncywgc28gSSBhbSBqdXN0IHRoaW5raW5nDQo+Pj4+ IG9mIHdheXMgdG8gbWFrZSBpdCB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGluZGljYXRvcnMgYXJlIGlu IHRoZSBYTUwNCj4+Pj4gZG9jdW1lbnQgYW5kIHRoZSBvdGhlciBkYXRhIHRoYXQgbWF5IGJlIGlt cG9ydGFudCBhcyBJIGludmVzdGlnYXRlDQo+Pj4+IGFjdGl2aXR5IHRoYXQgSSBoYXZlIGRldGVj dGVkIG9mZiBvZiB0aG9zZSBpbmRpY2F0b3JzLg0KPj4+Pg0KPj4+Pg0KPj4+PiBJIGRpZCBzdWdn ZXN0IHRoZSBkZXRlY3Rpb24gY2xhc3MsIGJ1dCBJIHRoaW5rIHdlIG1heSBnZXQgbW9yZQ0KPj4+ PiBmbGV4aWJpbGl0eSB3aXRoIHRoZSBpbmRpY2F0b3JfdWlkLiAgT25lIHRoaW5nIHRoYXQgSSBo YXZlbid0DQo+Pj4+IGNvbnNpZGVyZWQgaXMgdGhlIFVJRCBwb3J0aW9uIG9mIHRoaXPFoGhvdyBk byB3ZSB1c2UgdGhhdCBVSUQ/ICBIb3cgaXMNCj4+Pj4gdGhlIFVJRCBjcmVhdGVkPyAgQXJlIHRo ZXJlIHN0YW5kYXJkcyBmb3IgVUlEcz8NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4NCj4+Pj4g UGF1bA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBQYXVsIFcuIFN0b2Vja2VyLCBQaC5ELg0KPj4+ PiBTTUMgTGVhZCBDb250ZW50IEFyY2hpdGVjdA0KPj4+PiBSU0EsIFRoZSBTZWN1cml0eSBEaXZp c2lvbiBvZiBFTUMNCj4+Pj4gY2VsbDogMzAyLjM3OS4zMzc1IHwgZTogcGF1bC5zdG9lY2tlckBy c2EuY29tDQo+Pj4+DQo+Pj4+IC0tLSBPbiBTYXQsIDEvMjYvMTMsIEMuIEhlbnJ5IEFkYW1zICYg QklFIDxjaGF0bGdhMjAwMEB5YWhvby5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBGcm9tOiBDLiBI ZW5yeSBBZGFtcyAmIEJJRSA8Y2hhdGxnYTIwMDBAeWFob28uY29tPg0KPj4+PiBTdWJqZWN0OiBS RTogW21pbGVdIElPQ3MNCj4+Pj4gVG86ICJLYXRobGVlbk1vcmlhcnR5IiA8a2F0aGxlZW4ubW9y aWFydHlAZW1jLmNvbT4NCj4+Pj4gQ2M6IG1pbGVAaWV0Zi5vcmcNCj4+Pj4gRGF0ZTogU2F0dXJk YXksIEphbnVhcnkgMjYsIDIwMTMsIDY6MTcgUE0NCj4+Pj4NCj4+Pj4gR3JlZXRpbmdzIEthdGhs ZWVuLA0KPj4+Pg0KPj4+PiBZb3VyIGxvZ2ljIHN0aW11bGF0ZXMgbXkgdmlzaW9uYXJ5IGJyYWlu IGJlY2F1c2UgSSdtIGFtYXplZCBhdCB0aGUNCj4+Pj4gbWFueQ0KPj4+IGF2ZW51ZXMgeW91IHJl dmlldyB3aXRoIHRoaXMgYXBwcm9hY2ggYXQgb25jZS4gIEhvd2V2ZXIsICBjb3VsZCB5b3Ugc2hh cmUNCj4+PiBhDQo+Pj4gZmV3IGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMgdG8gdGhlIGxh dHRlcj8NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IC0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAid2UgY291bGQgY29udGludWUg dG8gZ3JvdXAgaXRlbXMgaW4gbG9naWNhbCBwbGFjZXMgYXMgaXMgZG9uZSBub3cgaW4NCj4+PiBJ T0RFRiBhbmQgdGhlbiBoYXZlIHRoZSBleHRlbnNpb24gcG9pbnQgZm9yIGNvbWJpbmVkIGluZGlj YXRvcnMgdmlhIFNDSS4iDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLS0tLS0tLQ0KPj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pg0KPj4+PiBZb3Ug cG9pbnRlZCBvdXQgd2hhdCB5b3UgY29uc2lkZXIgdG8gYmUgbG9naWNhbCBwbGFjZXMsIGJ1dCBp ZiBJDQo+Pj4+IHdhbnRlZCB0bw0KPj4+IHByb3RlY3QgaW5mb3JtYXRpb24gZnJvbSBwYXJ0aWVz IGNhcGFibGUgb2YgYXNjZXJ0YWluaW5nIGl0IGZyb20geW91cg0KPj4+IGxvZ2ljYWwgcGxhY2Vz LCBwZXJoYXBzIHdlIHNob3VsZCBhbHNvIGNvbnNpZGVyIHRvIGEgZGVncmVlIHdoYXQgYXBwZWFy cw0KPj4+IHRvDQo+Pj4gYmUgaWxsb2dpY2FsIGluIGJyaWxsaWFudCBtaW5kcyBpbiBzb21lIGlu c3RhbmNlcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gQy4gSGVucnkgQWRhbXMNCj4+Pj4gY2hh dGxnYTIwMDBAeWFob28uY29tIChEaXJlY3QgRW1haWwpDQo+Pj4+IGNoZW5yeWFkYW1zQGJpZW1l ZGlhZ3JvdXAuY29tDQo+Pj4+DQo+Pj4+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUNCj4+Pj4gb3JpZ2luYWwNCj4+PiByZWNp cGllbnQuIFRoaXMgaW5mb3JtYXRpb24gaXMgZ3JhbnRlZCBmb3IgbGltaXRlZCBkaXN0cmlidXRp b24gd2l0aGluDQo+Pj4gdGhlDQo+Pj4gcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9y IHBsYW5uaW5nIHB1cnBvc2VzIG9ubHkuIEZ1cnRoZXINCj4+PiBkaXNzZW1pbmF0aW9uLCB3aGV0 aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuDQo+Pj4+DQo+Pj4+IC0tLSBPbiBT YXQsIDEvMjYvMTMsIE1vcmlhcnR5LCBLYXRobGVlbiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNv bT4NCj4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4gRnJvbTogTW9yaWFydHksIEthdGhsZWVuIDxrYXRo bGVlbi5tb3JpYXJ0eUBlbWMuY29tPg0KPj4+PiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4+ Pj4gVG86ICJDLiBIZW5yeSBBZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbT4sICJt aWxlQGlldGYub3JnIg0KPj4+IDxtaWxlQGlldGYub3JnPg0KPj4+PiBEYXRlOiBTYXR1cmRheSwg SmFudWFyeSAyNiwgMjAxMywgMTA6MTMgQU0NCj4+Pj4NCj4+Pj4gSGVsbG8gQy4gSGVucnkgJiBv dGhlcnMsDQo+Pj4+DQo+Pj4+IFRoYW5rcyBmb3IgdGFraW5nIGEgbG9vayBhdCB0aGlzLiAgV2Ug aGF2ZSBhIGZldyBjb25zaWRlcmF0aW9ucyBpbg0KPj4+PiB0aGlzDQo+Pj4gZW1haWwgdGhyZWFk IEkgd291bGQgbGlrZSB0byBoZWFyIHRob3VnaHRzIG9uIChhbmQgdGhlcmUgbWF5IGJlIG1vcmUg b25jZQ0KPj4+IFJGQzUwNzAtYmlzIGlzIGFjdGl2ZWx5IGVkaXRlZCkuDQo+Pj4+DQo+Pj4+IFRo ZSBBZGRpdGlvbmFsRGF0YSBjbGFzcyBhbmQgdGhlIFJlY29yZEl0ZW0gY2xhc3MgYm90aCBhbGxv dyBmb3INCj4+Pj4gbm9uLVhNTA0KPj4+IGV4dGVuc2lvbnMuICBXaGVyZSB5b3UgcGxhY2UgdGhl IGV4dGVuc2lvbnMgc2hvdWxkIGJlIHNwZWNpZmljIHRvIHRoZQ0KPj4+IGxvZ2ljYWwgZ3JvdXBp bmcgb2YgdGhlIHBhcmVudCBlbGVtZW50cyBzbyB5b3UgY2FuIHVuZGVyc3RhbmQgbW9yZSBhYm91 dA0KPj4+IHRoZQ0KPj4+IGluY2x1ZGVkIGRhdGEgaW4gbW9zdCBjYXNlcy4NCj4+Pj4NCj4+Pj4g VGhlIEltcGFjdCBjbGFzcyBjYW4gYmUgdXNlZCB0byBwcm92aWRlIGNvbnRleHQgaW5mb3JtYXRp b24gb24gdGhlDQo+Pj4gaW5jbHVkZWQgZGF0YSBvZiB0aGUgcmVwb3J0IGFuZCBhbHNvIGNhbiBp bmNsdWRlIGEgY29uZmlkZW5jZSByYXRpbmcgb24NCj4+PiB0aGUNCj4+PiByZXBvcnQgYXMgYSB3 aG9sZS4gIEV4dGVuc2lvbnMgcmVsYXRlZCB0byBpbXBhY3Qgd291bGQgYmUgb25lIGxldmVsIGhp Z2hlcg0KPj4+IChhdCB0aGUgbW9tZW50KSBpbiB0aGUgQXNzZXNzbWVudCBjbGFzcyB1c2luZyB0 aGUgQWRkaXRpb25hbERhdGEgZXh0ZW5zaW9uDQo+Pj4gcG9pbnQuDQo+Pj4+DQo+Pj4+IFRha2Ug YXNrZWQgYWJvdXQgaW5jbHVkaW5nIHZ1bG5lcmFiaWxpdHkgaW5mb3JtYXRpb24sIEkgd291bGQg dGhpbmsNCj4+Pj4gdGhhdA0KPj4+IHdvdWxkIGZpdCB1bmRlciB0aGUgVnVsbmVyYWJpbGl0eSBl eHRlbnNpb24gcG9pbnQgb2YgdGhlIFNDSSBkcmFmdCBpbg0KPj4+IHRoZQ0KPj4+IE1ldGhvZCBj bGFzcy4gIEhlIGRpZCBhc2sgYWJvdXQgbm9uLVhNTC4gIFJlY29yZEl0ZW0gb3IgQWRkaXRpb25h bERhdGENCj4+PiBkbw0KPj4+IGFsbG93IGZvciBub24tWE1MIGV4dGVuc2lvbiBwb2ludHMsIHdl IGNvdWxkIGVpdGhlciBoYXZlIHRoZSBTQ0kgZHJhZnQNCj4+PiBoYW5kbGUgdGhlc2UgYXMgd2Vs bCBvciBoYXZlIHRoZSBleHRlbnNpb25zIHRoYXQgYXJlIG5vbi1YTUwgY29tZSBkaXJlY3RseQ0K Pj4+IG9mZiB0aGUgQWRkaXRpb25hbERhdGEgb3IgUmVjb3JkSXRlbSBjbGFzc2VzIGFjY29yZGlu ZyB0byB3aGF0IG1ha2VzIHNlbnNlDQo+Pj4gZnJvbSBhIGxvZ2ljYWwgc3RhbmRwb2ludC4NCj4+ Pj4NCj4+Pj4gQXMgZm9yIG15IHF1ZXN0aW9uLCBpdCB3YXMgdHdvLWZvbGQuDQo+Pj4+DQo+Pj4+ IEluZGljYXRvciBiYXNlZCBzY2hlbWFzIGhhdmUgYSByZWZlcmVuY2UgbnVtYmVyIG9yIGEgR1VJ RCBmb3IgdGhlDQo+Pj4+IHZhcmlvdXMNCj4+PiBpbmRpY2F0b3JzIHRoZXkgc2hhcmUuICBJZiB3 ZSBhcmUgZXh0ZW5kaW5nIHRvIGVtYmVkIG90aGVyIHNjaGVtYXMgdGhhdA0KPj4+IGluY2x1ZGUg c3VjaCByZWZlcmVuY2Ugb3IgR1VJRCBpZGVudGlmaWVycywgZG8gd2Ugd2FudCB0byBhZGQgYW4g YXR0cmlidXRlDQo+Pj4gdG8gdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gSU9ERUYgdGhhdCBjb3Vs ZCBiZSBpbmRpY2F0b3JzPyAgSXMgdGhpcyBlbm91Z2gNCj4+PiB0byBtYWtlIHRoZSBjb25uZWN0 aW9ucyBvciBpcyBzb21ldGhpbmcgZWxzZSBlbHNlIG5lZWRlZD8gIFdlIGNvdWxkIGFkZA0KPj4+ IHNvbWV0aGluZyBsaWtlIGFuIEluZGljYXRvcl9JRCBpbiBSRkM1MDcwLWJpcyB3aGljaCB3b3Vs ZCB0aGVuIGNvcnJlbGF0ZQ0KPj4+IHRvDQo+Pj4gdGhlIHJlZmVyZW5jZSBvciBHVUlEIGlkZW50 aWZpZXJzLg0KPj4+Pg0KPj4+PiBUaGVuIHRoZSBvdGhlciBxdWVzdGlvbiB3YXMgb24gaG93IHRv IGluY2x1ZGUgaW5kaWNhdG9ycyB0aGF0IGFyZSBub3QNCj4+Pj4gaW4NCj4+PiB0aGUgYmFzZSBz Y2hlbWEgdGhhdCBtYXkgYmUgcmVsYXRlZCBvciBoYXZlIGxhbmd1YWdlIHdpdGggImFuZCIgIm9y IiB0bw0KPj4+IHNwZWNpZnkgdGhlIHJlbGF0aW9uc2hpcHMuICBJbiBzb21lIGNhc2VzLCB5b3Ug d2lsbCB3YW50IHRvIGdyb3VwIHRoZXNlDQo+Pj4gaW5kaWN0b3JzIGluIG9uZSBleHRlbnNpb24g cG9pbnQsIHdoZXJlIHRoZXkgbWF5IGZpdCBsb2dpY2FsbHkgaW4gbXVsdGlwbGUNCj4+PiBwbGFj ZXMgaWYgdGhlIHJlbGF0aW9uc2hpcHMgZGlkIG5vdCBuZWVkIHRvIGJlIHNob3duIGluIHRoZSBk YXRhDQo+Pj4gZm9ybWF0LiAgSWYNCj4+PiB3ZSBoYXZlIGNhc2VzIGxpa2UgdGhpcyB3aGVyZSB5 b3UgbmVlZCBtb3JlIGNvbXBsZXggcmVwcmVzZW50YXRpb25zLA0KPj4+IHNob3VsZA0KPj4+IHdl IHVzZSBvbmUgZXh0ZW5zaW9uIHBvaW50IHZpYSB0aGUgU0NJIGRyYWZ0IG9mZiBvZiB0aGUgRXZl bnREYXRhIGNsYXNzDQo+Pj4gQWRkaXRpb25hbERhdGEgZXh0ZW5zaW9uIHBvaW50PyAgT3Bpbmlv bnMgYXJlIG5lZWRlZCBoZXJlLi4uLg0KPj4+Pg0KPj4+PiBBIGZldyBwZW9wbGUgaGF2ZSBtZW50 aW9uZWQgd2FudGluZyB0byBpbmNsdWRlIHNvbWUgY29tbW9ubHkgc2hhcmVkDQo+Pj4gaW5kaWN0 b3JzIGludG8gdGhlIGJhc2UgSU9ERUYgZG9jdW1lbnQuICBXZSBjb3VsZCBoYXZlIGEgY2F0Y2gt YWxsIGNsYXNzDQo+Pj4gdGhhdCBkb2VzIHRoaXMgYW5kIGhhcyBhbiBleHRlbnNpb24gcG9pbnQg b2ZmIG9mIGl0IGluIEV2ZW50RGF0YSBvciB3ZQ0KPj4+IGNvdWxkDQo+Pj4gY29udGludWUgdG8g Z3JvdXAgaXRlbXMgaW4gbG9naWNhbCBwbGFjZXMgYXMgaXMgZG9uZSBub3cgaW4gSU9ERUYgYW5k DQo+Pj4gdGhlbg0KPj4+IGhhdmUgdGhlIGV4dGVuc2lvbiBwb2ludCBmb3IgY29tYmluZWQgaW5k aWNhdG9ycyB2aWEgU0NJLiAgSSB0aGluayBJIGxpa2UNCj4+PiB0aGUgbGF0dGVyIGFwcHJvYWNo Lg0KPj4+Pg0KPj4+PiBUaGFuayB5b3UsDQo+Pj4+IEthdGhsZWVuDQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogbWlsZS1ib3VuY2VzQGll dGYub3JnIFttaWxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDLg0KPj4+PiBIZW5y eQ0KPj4+IEFkYW1zICYgQklFIFtjaGF0bGdhMjAwMEB5YWhvby5jb21dDQo+Pj4+IFNlbnQ6IFNh dHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzIDM6MDUgQU0NCj4+Pj4gVG86IG1pbGVAaWV0Zi5vcmcN Cj4+Pj4gQ2M6IEMuIEhlbnJ5IEFkYW1zDQo+Pj4+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0K Pj4+Pg0KPj4+PiBHcmVldGluZ3MgRXZlcnlvbmUsDQo+Pj4+DQo+Pj4+IFRha2UgbWVudGlvbmVk IHR3byB0eXBlcyBvZiBpbmRpY2F0b3JzIGJhc2VkIG9uIHRoZSA6DQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+PiAtLS0tLS0tLQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IDEpIElm IHRoZSBpbmRpY2F0b3JzIGFyZSBzb21ldGhpbmcgbGlrZSBhbiBYTUwtYmFzZWQgYWxlcnQvd2Fy bmluZyBvZg0KPj4+PiBpbmZvcm1hdGlvbiBsZWFrYWdlLCBpdCBjb3VsZCBiZSBhbiBldmVudCB0 aGF0IGFyZSBjb252ZXllZCBpbiB0aGUNCj4+Pj4gU0NJJ3MgRXZlbnRSZXBvcnQgY2xhc3MsIElN SE8uDQo+Pj4+DQo+Pj4+IDIpIElmIHRoZSBpbmRpY2F0b3JzIGFyZSBzb21ldGhpbmcgbGlrZSBh biBub24tWE1MIG9uZXMsIEkgZ3Vlc3MgaXQNCj4+Pj4gY291bGQNCj4+PiBiZQ0KPj4+PiBjb252 ZXllZCB3aXRob3V0IHVzaW5nIFNDSSBkcmFmdC4NCj4+Pj4gRm9yIGluc3RhbmNlLCB3ZSBjb3Vs ZCB1c2UgSW1wYWN0IGNsYXNzIG9mIHRoZSBiYXNlIElPREVGIHRvIGNvbnZleQ0KPj4+PiB0aGUg aW5kaWNhdG9ycy4NCj4+Pj4gV2UgY291bGQgZm9yIGluc3RhbmNlIGV4dGVuZCB0aGUgbGlzdCBv ZiBpbmRpY2F0b3JzIG9mIHRoZSBJbXBhY3QNCj4+Pj4gY2xhc3MsDQo+Pj4gaWYNCj4+Pj4gbmVl ZGVkLg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0NCj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+Pg0KPj4+PiBJbiBkb2luZyBzbyBoZSBwb2ludGVkIG91dCB0aGUgIklt cGFjdCBDbGFzcyINCj4+Pj4NCj4+Pj4gV2hlcmVhcywgS2F0aGxlZW4gc3RhdGVkLA0KPj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+IEZvciB0aGUgZGlzY3Vzc2lvbiBiZWxvdywgSSB3YXMgdGhpbmtpbmcgbW9yZSBvZiBjb21i aW5lZCBzZXQgd2l0aA0KPj4+IHJlbGF0aW9uc2hpcHMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4g YSBzaW5nbGUgZXh0ZW5zaW9uIHBvaW50LCBzbyB0aGF0J3MNCj4+PiB3aHkgSSB3YXMgdGhpbmtp bmcgYWJvdXQgdGhlIEV2ZW50RGF0YSBjbGFzcywgYnV0IHRoZXJlIG1heSBiZSBiZXR0ZXINCj4+ PiBsb2NhdGlvbnMgb3IgYSBzcGVjaWZpYyBhcmVhIHdpdGhpbiB0aGUgRXZlbnREYXRhLg0KPj4+ Pg0KPj4+PiBQYXVsIFN0b2Vja2VyIGhhZCBzdWdnZXN0ZWQgYSAiRGV0ZWN0aW9uIiBjbGFzcyBh cyBhIGNvbnNpZGVyYXRpb24uDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLS0tLS0tLQ0KPj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pg0KPj4+PiBLYXRobGVlbiB0aG91Z2h0cyByZWxh dGVkIHlldCBzdGlsbCB3aXRoIG90aGVyIGluZGljYXRvcnMgYW5kIHRoZQ0KPj4+IEV2ZW50RGF0 YSBDbGFzcy4NCj4+Pj4NCj4+Pj4gSXMgdGhlcmUgYSBwb3NzaWJsZSB3YXkgdG8gY3JlYXRlIGEg bmV3IFhNTCBjbGFzcyB3aGljaCBlbmNvbXBhc3MNCj4+PiBjb21iaW5pbmcgdGhlIEV2ZW50RGF0 YSwgRGV0ZWN0aW9uIGFuZCBiYXNlIElPREVGIGNsYXNzZXMgdG8gc2ltcGxpZnkNCj4+PiB0aGlz DQo+Pj4gaXNzdWU/DQo+Pj4+DQo+Pj4+DQo+Pj4+IEMuIEhlbnJ5IEFkYW1zDQo+Pj4+IGNoYXRs Z2EyMDAwQHlhaG9vLmNvbSAoRGlyZWN0IEVtYWlsKQ0KPj4+PiBjaGVucnlhZGFtc0BiaWVtZWRp YWdyb3VwLmNvbQ0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+Pj4+IG9yaWdpbmFsDQo+Pj4g cmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgZGlzdHJp YnV0aW9uIHdpdGhpbg0KPj4+IHRoZQ0KPj4+IHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNz IGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyDQo+Pj4gZGlzc2VtaW5hdGlvbiwg d2hldGhlciBwcml2YXRlIG9yIHB1YmxpYyBpcyBwcm9oaWJpdGVkLg0KPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBtaWxlIG1haWxpbmcg bGlzdA0KPj4+PiBtaWxlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWlsZQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBtaWxlIG1haWxpbmcgbGlzdA0KPj4gbWlsZUBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1pbGUgbWFpbGlu ZyBsaXN0DQo+IG1pbGVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taWxlDQo+DQo= From Paul.Stoecker@rsa.com Wed Feb 13 05:04:23 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE921F85B4 for ; Wed, 13 Feb 2013 05:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+nGphAk2SP1 for ; Wed, 13 Feb 2013 05:04:21 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1E46421F85B3 for ; Wed, 13 Feb 2013 05:04:20 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DD4DGg017642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 08:04:19 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 13 Feb 2013 08:04:07 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DD46RQ026575; Wed, 13 Feb 2013 08:04:06 -0500 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub14.corp.emc.com (128.222.70.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Feb 2013 08:04:06 -0500 Received: from mx33a.corp.emc.com ([169.254.1.154]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Wed, 13 Feb 2013 08:04:06 -0500 From: "Stoecker, Paul" To: "Moriarty, Kathleen" , Brian Trammell Date: Wed, 13 Feb 2013 08:04:04 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J6pqeWmOqyJVRTmqxBS29weWY2w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:04:23 -0000 I may have been too succinct in my response ;-) Confidence is a subjective thing, so I think we should use subjective terms: Low, Medium, High. Having a numeric scale with a map that essentially would say something like: 1-33 =3D Low 34-67=3D Medium 68-100=3DHigh Is just a more complicated way of saying that something is Low, Medium, High...do we really thing that how High something is makes that much of a difference? This is like when you get your Performance review where it is Does Not Meet, Meets and Exceeds...your boss tells you that you are a High Meets...y= our bonus tells you that you got the same bonus that all the other Meets got ;-) Anyway, I digress but trying to prove a point that I would argue that confidence in this case is going to be basically a gut feeling, so why use numeric values when Low, Medium, High would do just fine. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/13/13 7:48 AM, "Moriarty, Kathleen" wrote: >Hello, > >Both approaches will validate in the current schema. The representation >looks a little different for each, here is an example: > > > >Vs: > >85 > >Searching capability is a great point, agreed. I'd like to hear from >more people to make sure we don't lose a capability that others find >extremely useful (need to gauge that). Other options is that the >guidance can also discourage the use of the numeric in addition to >specifying how to select ranges. > >Any other opinions? > >Thanks, >Kathleen > >-----Original Message----- >From: Stoecker, Paul >Sent: Wednesday, February 13, 2013 7:14 AM >To: Brian Trammell >Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >Subject: Re: [mile] IOCs > >Cant we make Confidence a List that has only 3 values: High, Medium, and >Low? Any other value means that the Document will mot validate against >the schema. > >Sent from my iPhone > >On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >wrote: > >> Hi, Kathleen, all, >> >> I think 3.10.4 in 5070 takes the right approach here: trying to build >>interoperable numeric scales for assessment is a very hard problem. >>(Were I charged with defining such a scale, the value "70" would mean >>"we compared this incident report to N past similar incident reports >>according to similarity algorithm S, and 70% of the past reports had >>assessed impacts within E% of the actual, measured final impact -- I >>think for most applications this is vastly more difficult and rigorous >>than it needs to be.) >> >> Unless a numeric Confidence value is based on some actual, repeatably >>measurable aspect of the Assessment report -- which I suspect in >>many/most/all cases it's not -- then it just represents a guess, however >>educated. Each team will probably naturally tune its own scales such >>that each value generally means the same thing in each report. Across >>teams, I don't know. >> >> On the other hand, Assessments are by their very nature educated >>guesses, anyway, so I don't know that I'd find much use in automating a >>response based on the assessment confidence. Chris has a good point, >>though -- it makes searching difficult and sorting kind of pointless. >> >> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>agree, we should put that in the guidance document (along with a note >>that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, >>unless we want to do it non-linearly). If the _vast_majority_ of the >>users of this field use a 100-point scale with 100 meaning "yes" and 0 >>meaning "any resemblance these values may have to actual fact is purely >>coincidental", then let's consider renaming it "percent" in 5070-bis. >> >> Best regards, >> >> Brian (as contributor) >> >> >> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >> wrote: >> >>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>change it if it needs to be changed. The value is for a confidence >>>rating on the indicators shared. The definitions may be helpful for >>>anyone who wants to work on this discussion. IODEF has various markers >>>that can be used in a complimentary way without conflating the markers >>>meaning. >>> >>> I think some people using IODEF find the numerical values more >>>helpful, and it would be good to understand what people have learned >>>from using the current structure (what works/does not work). The >>>scales I have seen are 0-100. There is of course a subjective element >>>to assigning a numerical value to the confidence and it may vary from >>>entity to entity. With this type of rating you may need to consider >>>who it came from and how they scored the confidence rating to map to >>>your own rating. It would be good to hear more thoughts on this. >>> >>> Thanks, >>> Kathleen >>> >>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>> Sent: Tuesday, February 12, 2013 2:46 PM >>> To: MILE IETF >>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>> Subject: Re: [mile] IOCs >>> >>> >>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>point. Different Confidence levels will cause confusion. It appears >>>that there maybe a need for some type of simplified standardization to >>>be established between all Sharing Groups in this regard. >>> >>> Perhaps numerical scoring set at lower values should express levels of >>>urgency. >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>> >>> Thanks, >>> C. Henry Adams >>> >>> >>> >>> I see some confusion coming down the pike if we start using Confidence >>>the >>> way it is supported. If I am using low/med/high and someone sends me >>>an IoC >>> with a score of 70, what does that mean to me? What if I am using a >>>scale of >>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to >>> describe something with a consistent language. It really gets ugly >>>when we >>> store IoC from multiple sources. I have confidence values that are >>>numeric >>> as well as text. Makes searching / sorting very problematic. >>> >>> At this point we have to roll with what we have. I would strongly >>>recommend >>> that we revisit this at some point. >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Tuesday, February 12, 2013 9:59 AM >>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> Hi Chris & Take, >>> >>> I'll just focus on the confidence scoring. Right now, the schema >>>allows for >>> you to either use a numerical score OR the ratings of low, medium, and >>>high. >>> Different sharing groups can decide how they want to share the data. >>>If >>> people were to use the numerical values, I agree it would be helpful >>>to have >>> guidance. This could go in the IODE guidance document. >>> >>> I have seen examples of current users that use each of the approaches, >>>so >>> we'll need to keep the option for backwards compatibility and it is >>>nice to >>> keep in flexible options where we can. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: Harrington, Christopher >>> Sent: Tuesday, February 12, 2013 9:22 AM >>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>IETF' >>> Subject: RE: [mile] IOCs >>> >>> The number of indicators wouldn't necessarily drive the use of >>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>> addresses that were used as C2 for 3 different campaigns I would have >>> separate indicator_set_ids, each with one of the 3 C2 IPs >>> >>> My suggestion would be a simple low, medium, high. I think if we break >>>it >>> down to more levels than that we would need to provide guidance on >>>scoring, >>> rating, etc. I think most people should be able to understand >>>low/med/high >>> without having to have a mathematical method for arriving at the level. >>> >>> Low - I am not sure >>> Medium - I am reasonably sure >>> High - I am very sure >>> >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 12, 2013 4:21 AM >>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>IETF' >>> Subject: RE: [mile] IOCs >>> >>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>deal >>> with large sets of indicators. >>> Since indicator_set_id attribute is optional (right?), it could be >>>omitted >>> if we need to deal with only small number of indicators. >>> >>> Regarding the use case, I like the idea of using the confidence >>>attribute >>> for the reason Chris kindly described. >>> I would like to hear a bit more on this: is it going to be numerical? >>>For >>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>etc? >>> >>> Thank you. >>> Take >>> >>> >>>> -----Original Message----- >>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>>> Sent: Friday, February 08, 2013 4:11 AM >>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>> With respect to tying things back to threat actors, from what I have >>>> seen and use this is a generally accepted grouping: >>>> >>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>> >>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>> would be beneficial as making those associations is not a perfect >>>> science by any means. >>>> >>>> Thanks, >>>> >>>> --Chris >>>> >>>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Thursday, February 07, 2013 2:00 PM >>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>> Hi Take & others, >>>> >>>> Thanks for chiming in, I've been talking about this with Chris and a >>>> few others on their use cases and would like more opinions. I'll >>>> provide an option below from what we have discussed from a CIRC view >>>> point. We are also wondering how to also provide logic in IODEF that >>>> could cross over into SCI attached schemas or IODEF extensions (the >>>> solutions may all tie together with this discussion - or there may be >>>> better/more elegant solutions others would like to propose). >>>> >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>>> I like this discussion. >>>>> I agree, it would be good idea to have indicator identifiers inside >>>>> the IOC-related classes. >>>> >>>> KMM: At the class level, we may have several indicators listed that >>>> should be viewed as a set and may have another instance of that same >>>> class that is a related issue, but a separate set. We could as you >>>> say, list the indicator IDs connected through the reference class. >>>> The set IDs might give us other ways to group the values when we get >>>> into logic and relationships between sets or indicators. This could >>>> also be a way to connect indicators or sets across XML documents that >>>> could have been shared previously. If there are a large number of >>>> indicators in the set, then this becomes useful, for smaller sets, I >>>> agree it doesn't make as much sense. >>>> >>>> What do others think? >>>> >>>>>> Then for indicators not included in the base schema that may not >>>>>> fit into a category in the SCI draft, do we create a place for >>>>>> these off of SCI or right off of the IODE schema in EventData? >>>>>> (more details >>>> on >>>>>> this in my first message). >>>>> >>>>> If we could see any indicator of compromise as computer event >>>>> record, we could use SCI:EventReport class as the place for the >>>>> XML-based IOCs that couldn't fit anywhere else. >>>> >>>> KMM: That sounds like a good idea to me. This should go into guidance >>>> in the SCI draft. Does anyone else want to weigh in? >>>> >>>>> >>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>> KMM: Sounds good, thanks! >>>> >>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>> the indicator_set_id. >>>>> I understand we could do some grouping of individual indicator_uids >>>>> and its usability, but I am not sure whether we do not have any >>>>> other way to express these groupings. >>>>> For instance, a Reference class refers to several indicadtor_uids. >>>> In >>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>> >>>> KMM: It may be, what do you think about large sets of indicators or >>>> subsequent messages that add indicators to existing sets? Would this >>>> happen? Would it be easier to express relationships with sets of >>>> indicators in addition to individual indicators? By using this, it >>>> could give us a unique way to also provide the logic and relationships >>>> in a new class of IODEF so we don't have to worry about adding it into >>>> the current >>> structure. >>>> If there are better ways to handle that, and others can provide some >>>> options, that would be appreciated! >>>> >>>> Thank you, >>>> Kathleen >>>> >>>>> I would appreciate if anybody could share expertise on this. Though >>>> I >>>>> think I have read all the emails in the list, I might have >>>>> mis-understood some points. >>>>> >>>>> By the way, I think the indicator_uids should be added to the SCI >>> classes' >>>>> attributes so that they can be correlated with another information >>>>> as >>>> well. >>>>> >>>>> Thanks >>>>> Take >>>> >>>> >>>> >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Harrington, Christopher >>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>> Subject: Re: [mile] IOCs >>>> >>>> I think some sort of group ID would do the trick. We also need a >>>> logical and / or somewhere to show relationship between indicators. If >>>> I give you >>>> 2 >>>> registry keys do they both have to be present to be an indication of >>>> compromise or is either one by themselves an indicator? Both would >>>> have the same group ID since they are related. >>>> >>>> Thanks, >>>> --Chris >>>> >>>> From: Stoecker, Paul >>>> Sent: Sunday, February 03, 2013 8:26 PM >>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>> Subject: Re: [mile] IOCs >>>> >>>> What if we added indicator group ID along with the indicator_uid? >>>> This would allow you to group indicators that are related into the >>>> same group ID. >>>> Would this resolve the issue? >>>> >>>> It is either that or going back to adding a Detection (or Indicators) >>>> class that will should be used to take all of the indicators put them >>>> into one place and have the ability to group the ones that go >>>> together. I don't mean a place to put indicators that are missing >>>> from IODEF.I mean a place in the IODEF document where you put the >>>> indicators that are used for detection and prevention of the shared >>>> Incident. I don't know the answer here, but there has got to be a >>>> good way for indicators to be identified and being able to group them >>>> as Chris has suggested without basically recreating something >>>> complicated like STIX. >>>> >>>> Paul >>>> >>>> >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>> >>>> >>>> From: , Kathleen >>>> Date: Sunday, February 3, 2013 5:11 PM >>>> To: "Harrington, Christopher" , MILE >>>> IETF >>>> Subject: Re: [mile] IOCs >>>> >>>> Hi Chris, >>>> >>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>> >>>> The list has already said they would like to see indicators added to >>>> the definitions in RFC5070-bis, to be more explicit about including >>>> indicators and sets of indicators in IODE documents as opposed to >>>> 'parts of an incident or the useful information on an incident for >>>> sharing purposes. It was written before we used terms like >>>> indicators. With that in mind, Rosella proposed a number of changes >>>> back in July, both for guidance and for >>> format >>>> updates. It may help to have the first draft try to address at least >>>> some of these issues so people can understand the problems and at >>>> least a proposed solution. >>>> >>>> As you point out, we need to be able to show relationships between >>>> sets of indicators, where we may have a few sets of indicators that >>>> could have a relationship to each other within a document. In the >>>> July presentation, one of the questions was to see if we should add >>>> new category attribute values for the System class that would connect >>>> the list of included indicators. I think we should still keep the >>>> concept of a Node to a single node, but perhaps within System, list >>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>> help solve the issue as NodeRole values would compliment an AttackType >>>> (FraudType values could be included in AttackType or some broader >>>> term). It may be better to have the FraudTypes, plus attribute values >>>> like "C2-server", "sinkhole", "MalwareDistribution" for added context >>>> so you know what to do with the received set of indicators. >>>> >>>> I am proposing that we change IODEF to include multiple sets of >>> indicators, >>>> add an AttackType attribute (or some other name), a method to connect >>>> indicators and indicator sets within an IODEF using an attribute of >>>> indicator_uid (or some other name) with a string value to make the >>>> connection points, and add a few indicators that are commonly shared >>>> into the base IODEF. >>>> >>>> Back in July, we talked about adding Registry Key/Value pairs and >>>> hashes to the main IODEF document (trying to see if this will help >>>> Chris below). What if we added the Registry Key/Value pairs as a >>>> class off of RecordData, using a similar structure to what is in >>>> RFC5901, and also added the ability to include hashes in RecordData? >>>> I think if we then had the indicator_uid at the RecordData level, we >>>> could connect a set within that structure and repeat the structure for >>>> other sets in the same way we would do with Node inside of the System >>>> class, using the indicator_uid to tie the set together. Then at the >>>> more specific level for the hash, registry Key/value, IP, etc. use an >>>> indicator_uid if we needed them marked at this level as well? Maybe >>>> we want indicator_set at the higher level? I'd like some opinions on >>>> this approach. +1 if you agree, suggestions if you have other ideas >>>> that may work better. >>>> >>>> We'll also need to worry about marking the indicators to prevent >>>> forward sharing when not permitted. We may want to use these values >>>> or something else. >>>> >>>> Thank you! >>>> Kathleen >>>> >>>> From: Harrington, Christopher >>>> Sent: Friday, February 01, 2013 12:01 PM >>>> To: Moriarty, Kathleen; MILE IETF >>>> Subject: RE: [mile] IOCs >>>> >>>> I think we have a bigger relationship issue to address. Let use the >>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>> that message we could have groupings of indicators that we need to >>>> show are >>>> related: >>>> >>>> Two or more indicators of different type that relate to the same >>>>threat: >>>> The file hash of a malicious file and the URL of the C2 that >>>> the file uses. Either or both may be present to indicate a compromise. >>>> >>>> Two or more indicators of the same type that relate to the same >>>>threat: >>>> 2 different registry values for the same registry key. If >>>> either value is present it is a compromise indicator but both will not >>>> be >>> present. >>>> >>>> The problem compounds itself very quickly. Consider the scenario where >>>> both groupings above are part of the same threat. I need to show that >>>> logical groupings of Indicators are related as well. We can't send >>>> multiple IODEF messages for this from what I remember reading. >>>> >>>> The last one I can think of would be when you have 2 different >>>> indicators that represent the same indicator. It's not uncommon to >>>> send both the >>>> MD5 >>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>> IOCs are the 2 hash values. How do we show they are related? If we use >>>> a unique Inidcator ID for each hash value there needs to be a higher >>>> level >>> grouping. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> >>>> --Chris >>>> >>>> Christopher Harrington >>>> Consulting Security Engineer >>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>> 174 Middlesex Turnpike >>>> Bedford, MA 01730 >>>> 781-515-5862 (work) >>>> 603-583-1585 (cell) >>>> >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Moriarty, Kathleen >>>> Sent: Friday, February 01, 2013 11:28 AM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>> >>>> All - >>>> >>>> I'd like your input and will refocus the thread to get opinions from >>>> the list on options to help solve the problems raised in my message >>>> and additionally in Paul's message. >>>> >>>> Interesting point, C. Henry. Our objective here is to have machine >>>> automated exchanges, so we rely on encryption rather than obfuscation >>>> to achieve the necessary level of confidentiality. >>>> >>>> Paul mentioned the need to distinguish indicators of compromise from >>>> context information that may also include IP address or other data >>>> that could be indicators. The question I raised was on how to connect >>>> sets of indicators in the same IODEF document, assuming the ability to >>>> have watchlists that could have several sets of indicators included, >>>> as well as to connect indicators that may be included in embedded >>>> schemas. >>>> >>>> If we add an attribute on all of the relevant indicators, let's say >>>> 'indicator-uid' how do we mark the indicators? Do we use this to mark >>>> who sent the indicator as well so that we can prevent forward sharing >>>> when it is not permitted or handle that separately? >>>> >>>> Then for indicators not included in the base schema that may not fit >>>> into a category in the SCI draft, do we create a place for these off >>>> of SCI or right off of the IODE schema in EventData? (more details on >>>> this in my first message). >>>> >>>> Comments and questions encouraged to figure out the right technical >>>> solution to have this machine automatable. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of C. >>>> Henry Adams & BIE >>>> Sent: Monday, January 28, 2013 11:25 PM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>> >>>> Temporal Dependency sounds interesting. I remember when I first ran >>>> across this particular craft, an experienced colleague asked me a >>>> peculiar question. He said, " How do you stop someone from tracking >>>> the IP Address to your computer?" >>>> >>>> I replied, "I don't know, how?" >>>> >>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>> connected- which is constantly on!" LOL >>>> >>>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>>> searching a Neighborhood for Survivors which were hit by a Disaster or >>>> let's just say "Live" Terrorist Situation. He /or She needs to >>>> communication back to other Officials that he /or somehow is in >>>> Danger. The device used to communicate has been captured by the great >>>> minds of the enemy. It's only a matter of time before they utilize >>>> reverse engineering to figure out how it functions. However, their >>>> pride comes before a fall when seeking the location of other similar >>>> devices to attack. Why? Perhaps the less thought of concepts that >>>> makes the device function properly, saves the day by disguise or >>>> cutting it off (figuratively speaking). >>>> >>>> Just a visionary thought. >>>> >>>> C. Henry Adams >>>> chenryadams@biemediagroup.com >>>> http://biemediagroup.com >>>> >>>> >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>> >>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>> >>>> From: Dave Misell >>>> Subject: Re: [mile] IOCs >>>> To: "C. Henry Adams & BIE" >>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS >>>> SEC a pemanent and temporal key, with a temporal Id? >>>> >>>> Yours Faithfully, >>>> >>>> Dave Misell MSc CISSP >>>> SilentCircle dsm >>>> 07710 380044 >>>> david.misell@bcs.org >>>> >>>> >>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>> wrote: >>>> >>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>> was >>>> closely related to what I attempted to express when I stated, >>>> "consider to a degree what appears to be illogical in brilliant minds >>>> in some instances." >>>>> >>>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>>> would >>>> be nice if the UID was in some way disguised from those who study this >>>> Security Art Form in a negative way. >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original >>>> recipient. This information is granted for limited distribution within >>>> the >>>> recipient's place of business for planning purposes only. Further >>>> dissemination, whether private or public is prohibited. >>>>> >>>>> Re: [mile] IOCs >>>>> >>>>> Sunday, January 27, 2013 8:52 PM >>>>> From: >>>>> "Stoecker, Paul" >>>>> To: >>>>> "mile@ietf.org" >>>>> I would like to look at this from a slightly different >>>>> perspective=A9let's say I get an XML document that tells me about an >>>>> incident. This document has source IP and destination IP that is >>>>> being shared. However, what I don't know is which IP address is my >>>>> indicator and which is just a contextual piece of information. This >>>>> means that my detection product isn't going to know which one to use >>>>> either, because there is nothing to tell me which IP is the one, even >>>>> if the roles are set it still might not be enough to tell my system >>>> which >>>> one I should use as the indicator. >>>>> >>>>> If we had something like indicator_id as an attribute, it would allow >>>>> us to easily identify indicators from contextual data. I do admit to >>>>> being biased as I have spent much of my career working on the >>>>> monitoring and detection side of these things, so I am just thinking >>>>> of ways to make it very clear what the indicators are in the XML >>>>> document and the other data that may be important as I investigate >>>>> activity that I have detected off of those indicators. >>>>> >>>>> >>>>> I did suggest the detection class, but I think we may get more >>>>> flexibility with the indicator_uid. One thing that I haven't >>>>> considered is the UID portion of this=A9how do we use that UID? How = is >>>>> the UID created? Are there standards for UIDs? >>>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>>wrote: >>>>> >>>>> From: C. Henry Adams & BIE >>>>> Subject: RE: [mile] IOCs >>>>> To: "KathleenMoriarty" >>>>> Cc: mile@ietf.org >>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>> >>>>> Greetings Kathleen, >>>>> >>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>> many >>>> avenues you review with this approach at once. However, could you >>>>share >>>> a >>>> few advantages and disadvantages to the latter? >>>> -------------------------------------------------------------------- >>>> -------- >>>> ---------------------------------------------- >>>>> "we could continue to group items in logical places as is done now in >>>> IODEF and then have the extension point for combined indicators via >>>>SCI." >>>> -------------------------------------------------------------------- >>>> -------- >>>> --------------------------------------------- >>>>> >>>>> You pointed out what you consider to be logical places, but if I >>>>> wanted to >>>> protect information from parties capable of ascertaining it from your >>>> logical places, perhaps we should also consider to a degree what >>>>appears >>>> to >>>> be illogical in brilliant minds in some instances. >>>>> >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original >>>> recipient. This information is granted for limited distribution within >>>> the >>>> recipient's place of business for planning purposes only. Further >>>> dissemination, whether private or public is prohibited. >>>>> >>>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>> wrote: >>>>> >>>>> From: Moriarty, Kathleen >>>>> Subject: RE: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>> >>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>> >>>>> Hello C. Henry & others, >>>>> >>>>> Thanks for taking a look at this. We have a few considerations in >>>>> this >>>> email thread I would like to hear thoughts on (and there may be more >>>>once >>>> RFC5070-bis is actively edited). >>>>> >>>>> The AdditionalData class and the RecordItem class both allow for >>>>> non-XML >>>> extensions. Where you place the extensions should be specific to the >>>> logical grouping of the parent elements so you can understand more >>>>about >>>> the >>>> included data in most cases. >>>>> >>>>> The Impact class can be used to provide context information on the >>>> included data of the report and also can include a confidence rating >>>>on >>>> the >>>> report as a whole. Extensions related to impact would be one level >>>>higher >>>> (at the moment) in the Assessment class using the AdditionalData >>>>extension >>>> point. >>>>> >>>>> Take asked about including vulnerability information, I would think >>>>> that >>>> would fit under the Vulnerability extension point of the SCI draft in >>>> the >>>> Method class. He did ask about non-XML. RecordItem or AdditionalData >>>> do >>>> allow for non-XML extension points, we could either have the SCI draft >>>> handle these as well or have the extensions that are non-XML come >>>>directly >>>> off the AdditionalData or RecordItem classes according to what makes >>>>sense >>>> from a logical standpoint. >>>>> >>>>> As for my question, it was two-fold. >>>>> >>>>> Indicator based schemas have a reference number or a GUID for the >>>>> various >>>> indicators they share. If we are extending to embed other schemas >>>>that >>>> include such reference or GUID identifiers, do we want to add an >>>>attribute >>>> to the various elements in IODEF that could be indicators? Is this >>>>enough >>>> to make the connections or is something else else needed? We could >>>>add >>>> something like an Indicator_ID in RFC5070-bis which would then >>>>correlate >>>> to >>>> the reference or GUID identifiers. >>>>> >>>>> Then the other question was on how to include indicators that are not >>>>> in >>>> the base schema that may be related or have language with "and" "or" >>>>to >>>> specify the relationships. In some cases, you will want to group >>>>these >>>> indictors in one extension point, where they may fit logically in >>>>multiple >>>> places if the relationships did not need to be shown in the data >>>> format. If >>>> we have cases like this where you need more complex representations, >>>> should >>>> we use one extension point via the SCI draft off of the EventData >>>>class >>>> AdditionalData extension point? Opinions are needed here.... >>>>> >>>>> A few people have mentioned wanting to include some commonly shared >>>> indictors into the base IODEF document. We could have a catch-all >>>>class >>>> that does this and has an extension point off of it in EventData or we >>>> could >>>> continue to group items in logical places as is done now in IODEF and >>>> then >>>> have the extension point for combined indicators via SCI. I think I >>>>like >>>> the latter approach. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>> Henry >>>> Adams & BIE [chatlga2000@yahoo.com] >>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>> To: mile@ietf.org >>>>> Cc: C. Henry Adams >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Greetings Everyone, >>>>> >>>>> Take mentioned two types of indicators based on the : >>>> -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>>> 1) If the indicators are something like an XML-based alert/warning of >>>>> information leakage, it could be an event that are conveyed in the >>>>> SCI's EventReport class, IMHO. >>>>> >>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>> could >>>> be >>>>> conveyed without using SCI draft. >>>>> For instance, we could use Impact class of the base IODEF to convey >>>>> the indicators. >>>>> We could for instance extend the list of indicators of the Impact >>>>> class, >>>> if >>>>> needed. >>>> -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>>> >>>>> In doing so he pointed out the "Impact Class" >>>>> >>>>> Whereas, Kathleen stated, >>>> -------------------------------------------------------------------- >>>> -------- >>>> ------------------------- >>>>> For the discussion below, I was thinking more of combined set with >>>> relationships that may be included in a single extension point, so >>>>that's >>>> why I was thinking about the EventData class, but there may be better >>>> locations or a specific area within the EventData. >>>>> >>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>> -------------------------------------------------------------------- >>>> -------- >>>> ------------------------ >>>>> >>>>> Kathleen thoughts related yet still with other indicators and the >>>> EventData Class. >>>>> >>>>> Is there a possible way to create a new XML class which encompass >>>> combining the EventData, Detection and base IODEF classes to simplify >>>> this >>>> issue? >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original >>>> recipient. This information is granted for limited distribution within >>>> the >>>> recipient's place of business for planning purposes only. Further >>>> dissemination, whether private or public is prohibited. >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> From kathleen.moriarty@emc.com Wed Feb 13 05:09:21 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508BA21F8877 for ; Wed, 13 Feb 2013 05:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae2+IAK5Hwxo for ; Wed, 13 Feb 2013 05:09:19 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C740921F885B for ; Wed, 13 Feb 2013 05:09:18 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DCn0Bd030623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 07:49:00 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 13 Feb 2013 07:48:35 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DCmYYV014055; Wed, 13 Feb 2013 07:48:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 13 Feb 2013 07:48:34 -0500 From: "Moriarty, Kathleen" To: "Stoecker, Paul" , Brian Trammell Date: Wed, 13 Feb 2013 07:48:34 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J4448R+G80PyERrebAk419Xx+7gAA/qEg Message-ID: References: <1360698335.82136.YahooMailClassic@web121606.mail.ne1.yahoo.com> <40C79581-1FCD-4471-AC7B-51066C20982C@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:09:21 -0000 SGVsbG8sDQoNCkJvdGggYXBwcm9hY2hlcyB3aWxsIHZhbGlkYXRlIGluIHRoZSBjdXJyZW50IHNj aGVtYS4gIFRoZSByZXByZXNlbnRhdGlvbiBsb29rcyBhIGxpdHRsZSBkaWZmZXJlbnQgZm9yIGVh Y2gsIGhlcmUgaXMgYW4gZXhhbXBsZToNCg0KPENvbmZpZGVuY2UgcmF0aW5nPSJsb3ciLz4NCg0K VnM6DQoNCjxDb25maWRlbmNlIHJhdGluZz0ibnVtZXJpYyI+ODU8Lz4NCg0KU2VhcmNoaW5nIGNh cGFiaWxpdHkgaXMgYSBncmVhdCBwb2ludCwgYWdyZWVkLiAgSSdkIGxpa2UgdG8gaGVhciBmcm9t IG1vcmUgcGVvcGxlIHRvIG1ha2Ugc3VyZSB3ZSBkb24ndCBsb3NlIGEgY2FwYWJpbGl0eSB0aGF0 IG90aGVycyBmaW5kIGV4dHJlbWVseSB1c2VmdWwgKG5lZWQgdG8gZ2F1Z2UgdGhhdCkuICBPdGhl ciBvcHRpb25zIGlzIHRoYXQgdGhlIGd1aWRhbmNlIGNhbiBhbHNvIGRpc2NvdXJhZ2UgdGhlIHVz ZSBvZiB0aGUgbnVtZXJpYyBpbiBhZGRpdGlvbiB0byBzcGVjaWZ5aW5nIGhvdyB0byBzZWxlY3Qg cmFuZ2VzLg0KDQpBbnkgb3RoZXIgb3BpbmlvbnM/DQoNClRoYW5rcywNCkthdGhsZWVuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdG9lY2tlciwgUGF1bA0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAxMywgMjAxMyA3OjE0IEFNDQpUbzogQnJpYW4gVHJhbW1lbGwNCkNj OiBNb3JpYXJ0eSwgS2F0aGxlZW47IEMuIEhlbnJ5IEFkYW1zICYgQklFOyBNSUxFIElFVEYNClN1 YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KDQpDYW50IHdlIG1ha2UgQ29uZmlkZW5jZSBhIExpc3Qg dGhhdCBoYXMgb25seSAzIHZhbHVlczogIEhpZ2gsIE1lZGl1bSwgYW5kIExvdz8gIEFueSBvdGhl ciB2YWx1ZSBtZWFucyB0aGF0IHRoZSBEb2N1bWVudCB3aWxsIG1vdCB2YWxpZGF0ZSBhZ2FpbnN0 IHRoZSBzY2hlbWEuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gRmViIDEzLCAyMDEzLCBh dCAyOjE0IEFNLCAiQnJpYW4gVHJhbW1lbGwiIDx0cmFtbWVsbEB0aWsuZWUuZXRoei5jaD4gd3Jv dGU6DQoNCj4gSGksIEthdGhsZWVuLCBhbGwsDQo+DQo+IEkgdGhpbmsgMy4xMC40IGluIDUwNzAg dGFrZXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGhlcmU6IHRyeWluZyB0byBidWlsZCBpbnRlcm9wZXJh YmxlIG51bWVyaWMgc2NhbGVzIGZvciBhc3Nlc3NtZW50IGlzIGEgdmVyeSBoYXJkIHByb2JsZW0u IChXZXJlIEkgY2hhcmdlZCB3aXRoIGRlZmluaW5nIHN1Y2ggYSBzY2FsZSwgdGhlIHZhbHVlICI3 MCIgd291bGQgbWVhbiAid2UgY29tcGFyZWQgdGhpcyBpbmNpZGVudCByZXBvcnQgdG8gTiBwYXN0 IHNpbWlsYXIgaW5jaWRlbnQgcmVwb3J0cyBhY2NvcmRpbmcgdG8gc2ltaWxhcml0eSBhbGdvcml0 aG0gUywgYW5kIDcwJSBvZiB0aGUgcGFzdCByZXBvcnRzIGhhZCBhc3Nlc3NlZCBpbXBhY3RzIHdp dGhpbiBFJSBvZiB0aGUgYWN0dWFsLCBtZWFzdXJlZCBmaW5hbCBpbXBhY3QgLS0gSSB0aGluayBm b3IgbW9zdCBhcHBsaWNhdGlvbnMgdGhpcyBpcyB2YXN0bHkgbW9yZSBkaWZmaWN1bHQgYW5kIHJp Z29yb3VzIHRoYW4gaXQgbmVlZHMgdG8gYmUuKQ0KPg0KPiBVbmxlc3MgYSBudW1lcmljIENvbmZp ZGVuY2UgdmFsdWUgaXMgYmFzZWQgb24gc29tZSBhY3R1YWwsIHJlcGVhdGFibHkgbWVhc3VyYWJs ZSBhc3BlY3Qgb2YgdGhlIEFzc2Vzc21lbnQgcmVwb3J0IC0tIHdoaWNoIEkgc3VzcGVjdCBpbiBt YW55L21vc3QvYWxsIGNhc2VzIGl0J3Mgbm90IC0tIHRoZW4gaXQganVzdCByZXByZXNlbnRzIGEg Z3Vlc3MsIGhvd2V2ZXIgZWR1Y2F0ZWQuICBFYWNoIHRlYW0gd2lsbCBwcm9iYWJseSBuYXR1cmFs bHkgdHVuZSBpdHMgb3duIHNjYWxlcyBzdWNoIHRoYXQgZWFjaCB2YWx1ZSBnZW5lcmFsbHkgbWVh bnMgdGhlIHNhbWUgdGhpbmcgaW4gZWFjaCByZXBvcnQuIEFjcm9zcyB0ZWFtcywgSSBkb24ndCBr bm93Lg0KPg0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgQXNzZXNzbWVudHMgYXJlIGJ5IHRoZWlyIHZl cnkgbmF0dXJlIGVkdWNhdGVkIGd1ZXNzZXMsIGFueXdheSwgc28gSSBkb24ndCBrbm93IHRoYXQg SSdkIGZpbmQgbXVjaCB1c2UgaW4gYXV0b21hdGluZyBhIHJlc3BvbnNlIGJhc2VkIG9uIHRoZSBh c3Nlc3NtZW50IGNvbmZpZGVuY2UuIENocmlzIGhhcyBhIGdvb2QgcG9pbnQsIHRob3VnaCAtLSBp dCBtYWtlcyBzZWFyY2hpbmcgZGlmZmljdWx0IGFuZCBzb3J0aW5nIGtpbmQgb2YgcG9pbnRsZXNz Lg0KPg0KPiBJZiB3ZSd2ZSBzZWVuIGEgZ2VuZXJhbCB0cmVuZCB0b3dhcmQgIjAgPSAwJSwgMTAw ID0gMTAwJSIsIHRoZW4gSSBhZ3JlZSwgd2Ugc2hvdWxkIHB1dCB0aGF0IGluIHRoZSBndWlkYW5j ZSBkb2N1bWVudCAoYWxvbmcgd2l0aCBhIG5vdGUgdGhhdCAwLTMzIG1hcCB0byBsb3csIDM0IC0g NjYgbWFwIHRvIG1lZGl1bSwgYW5kIDY3IC0gMTAwIG1hcCB0byBoaWdoLCB1bmxlc3Mgd2Ugd2Fu dCB0byBkbyBpdCBub24tbGluZWFybHkpLiBJZiB0aGUgX3Zhc3RfbWFqb3JpdHlfIG9mIHRoZSB1 c2VycyBvZiB0aGlzIGZpZWxkIHVzZSBhIDEwMC1wb2ludCBzY2FsZSB3aXRoIDEwMCBtZWFuaW5n ICJ5ZXMiIGFuZCAwIG1lYW5pbmcgImFueSByZXNlbWJsYW5jZSB0aGVzZSB2YWx1ZXMgbWF5IGhh dmUgdG8gYWN0dWFsIGZhY3QgaXMgcHVyZWx5IGNvaW5jaWRlbnRhbCIsIHRoZW4gbGV0J3MgY29u c2lkZXIgcmVuYW1pbmcgaXQgInBlcmNlbnQiIGluIDUwNzAtYmlzLg0KPg0KPiBCZXN0IHJlZ2Fy ZHMsDQo+DQo+IEJyaWFuIChhcyBjb250cmlidXRvcikNCj4NCj4NCj4gT24gRmViIDEyLCAyMDEz LCBhdCA5OjU2IFBNLCAiTW9yaWFydHksIEthdGhsZWVuIiA8a2F0aGxlZW4ubW9yaWFydHlAZW1j LmNvbT4gd3JvdGU6DQo+DQo+PiBQbGVhc2Ugc2VlIHNlY3Rpb24gMy4xMC40IG9mIFJGQzUwNzAg YXMgYSBzdGFydGluZyBwb2ludC4gIFdlIGNhbiBjaGFuZ2UgaXQgaWYgaXQgbmVlZHMgdG8gYmUg Y2hhbmdlZC4gIFRoZSB2YWx1ZSBpcyBmb3IgYSBjb25maWRlbmNlIHJhdGluZyBvbiB0aGUgaW5k aWNhdG9ycyBzaGFyZWQuICBUaGUgZGVmaW5pdGlvbnMgbWF5IGJlIGhlbHBmdWwgZm9yIGFueW9u ZSB3aG8gd2FudHMgdG8gd29yayBvbiB0aGlzIGRpc2N1c3Npb24uICBJT0RFRiBoYXMgdmFyaW91 cyBtYXJrZXJzIHRoYXQgY2FuIGJlIHVzZWQgaW4gYSBjb21wbGltZW50YXJ5IHdheSB3aXRob3V0 IGNvbmZsYXRpbmcgdGhlIG1hcmtlcnMgbWVhbmluZy4NCj4+DQo+PiBJIHRoaW5rIHNvbWUgcGVv cGxlIHVzaW5nIElPREVGIGZpbmQgdGhlIG51bWVyaWNhbCB2YWx1ZXMgbW9yZSBoZWxwZnVsLCBh bmQgaXQgd291bGQgYmUgZ29vZCB0byB1bmRlcnN0YW5kIHdoYXQgcGVvcGxlIGhhdmUgbGVhcm5l ZCBmcm9tIHVzaW5nIHRoZSBjdXJyZW50IHN0cnVjdHVyZSAod2hhdCB3b3Jrcy9kb2VzIG5vdCB3 b3JrKS4gIFRoZSBzY2FsZXMgSSBoYXZlIHNlZW4gYXJlIDAtMTAwLiAgVGhlcmUgaXMgb2YgY291 cnNlIGEgc3ViamVjdGl2ZSBlbGVtZW50IHRvIGFzc2lnbmluZyBhIG51bWVyaWNhbCB2YWx1ZSB0 byB0aGUgY29uZmlkZW5jZSBhbmQgaXQgbWF5IHZhcnkgZnJvbSBlbnRpdHkgdG8gZW50aXR5LiAg V2l0aCB0aGlzIHR5cGUgb2YgcmF0aW5nIHlvdSBtYXkgbmVlZCB0byBjb25zaWRlciB3aG8gaXQg Y2FtZSBmcm9tIGFuZCBob3cgdGhleSBzY29yZWQgdGhlIGNvbmZpZGVuY2UgcmF0aW5nIHRvIG1h cCB0byB5b3VyIG93biByYXRpbmcuICBJdCB3b3VsZCBiZSBnb29kIHRvIGhlYXIgbW9yZSB0aG91 Z2h0cyBvbiB0aGlzLg0KPj4NCj4+IFRoYW5rcywNCj4+IEthdGhsZWVuDQo+Pg0KPj4gRnJvbTog Qy4gSGVucnkgQWRhbXMgJiBCSUUgW21haWx0bzpjaGF0bGdhMjAwMEB5YWhvby5jb21dDQo+PiBT ZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyAyOjQ2IFBNDQo+PiBUbzogTUlMRSBJRVRG DQo+PiBDYzogTW9yaWFydHksIEthdGhsZWVuOyAnVGFrZXNoaSBUYWthaGFzaGknOyBTdG9lY2tl ciwgUGF1bA0KPj4gU3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQo+Pg0KPj4NCj4+IFJlZ2FyZGlu ZyB0aGUgSU9DcyBvciBJbmRpY2F0b3JzIG9mIENvbXByb21pc2UsIENocmlzIG1hZGUgYSB2aXRh bCBwb2ludC4gIERpZmZlcmVudCBDb25maWRlbmNlIGxldmVscyB3aWxsIGNhdXNlIGNvbmZ1c2lv bi4gIEl0IGFwcGVhcnMgdGhhdCB0aGVyZSBtYXliZSBhIG5lZWQgZm9yIHNvbWUgdHlwZSBvZiBz aW1wbGlmaWVkIHN0YW5kYXJkaXphdGlvbiB0byBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIGFsbCBT aGFyaW5nIEdyb3VwcyBpbiB0aGlzIHJlZ2FyZC4NCj4+DQo+PiBQZXJoYXBzIG51bWVyaWNhbCBz Y29yaW5nIHNldCBhdCBsb3dlciB2YWx1ZXMgc2hvdWxkIGV4cHJlc3MgbGV2ZWxzIG9mIHVyZ2Vu Y3kuDQo+PiAoIGkuZS4gIDEgPSBMZXNzIExpa2VseSwgICAyID0gUHJvYmFibGUsICAzID0gQSBD b25jZXJuLCAgNCA9ICBVcmdlbnQsICA1ID0gSW1taW5lbnQgKQ0KPj4NCj4+IFRoYW5rcywNCj4+ IEMuIEhlbnJ5IEFkYW1zDQo+Pg0KPj4NCj4+DQo+PiBJIHNlZSBzb21lIGNvbmZ1c2lvbiBjb21p bmcgZG93biB0aGUgcGlrZSBpZiB3ZSBzdGFydCB1c2luZyBDb25maWRlbmNlIHRoZQ0KPj4gd2F5 IGl0IGlzIHN1cHBvcnRlZC4gSWYgSSBhbSB1c2luZyBsb3cvbWVkL2hpZ2ggYW5kIHNvbWVvbmUg c2VuZHMgbWUgYW4gSW9DDQo+PiB3aXRoIGEgc2NvcmUgb2YgNzAsIHdoYXQgZG9lcyB0aGF0IG1l YW4gdG8gbWU/IFdoYXQgaWYgSSBhbSB1c2luZyBhIHNjYWxlIG9mDQo+PiAxIHRvIDQgYW5kIHNv bWVvbmUgZWxzZSBpcyBvbiBhIHNjYWxlIG9mIDEgdG8gNT8gV2UgbG9zZSB0aGUgYWJpbGl0eSB0 bw0KPj4gZGVzY3JpYmUgc29tZXRoaW5nIHdpdGggYSBjb25zaXN0ZW50IGxhbmd1YWdlLiBJdCBy ZWFsbHkgZ2V0cyB1Z2x5IHdoZW4gd2UNCj4+IHN0b3JlIElvQyBmcm9tIG11bHRpcGxlIHNvdXJj ZXMuIEkgaGF2ZSBjb25maWRlbmNlIHZhbHVlcyB0aGF0IGFyZSBudW1lcmljDQo+PiBhcyB3ZWxs IGFzIHRleHQuICBNYWtlcyBzZWFyY2hpbmcgLyBzb3J0aW5nIHZlcnkgcHJvYmxlbWF0aWMuDQo+ Pg0KPj4gQXQgdGhpcyBwb2ludCB3ZSBoYXZlIHRvIHJvbGwgd2l0aCB3aGF0IHdlIGhhdmUuIEkg d291bGQgc3Ryb25nbHkgcmVjb21tZW5kDQo+PiB0aGF0IHdlIHJldmlzaXQgdGhpcyBhdCBzb21l IHBvaW50Lg0KPj4NCj4+IFRoYW5rcywNCj4+DQo+PiAtLUNocmlzDQo+Pg0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE1vcmlhcnR5LCBLYXRobGVlbg0KPj4gU2VudDog VHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgOTo1OSBBTQ0KPj4gVG86IEhhcnJpbmd0b24sIENo cmlzdG9waGVyOyAnVGFrZXNoaSBUYWthaGFzaGknOyBTdG9lY2tlciwgUGF1bDsgJ01JTEUNCj4+ IElFVEYnDQo+PiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCj4+DQo+PiBIaSBDaHJpcyAmIFRh a2UsDQo+Pg0KPj4gSSdsbCBqdXN0IGZvY3VzIG9uIHRoZSBjb25maWRlbmNlIHNjb3JpbmcuICBS aWdodCBub3csIHRoZSBzY2hlbWEgYWxsb3dzIGZvcg0KPj4geW91IHRvIGVpdGhlciB1c2UgYSBu dW1lcmljYWwgc2NvcmUgT1IgdGhlIHJhdGluZ3Mgb2YgbG93LCBtZWRpdW0sIGFuZCBoaWdoLg0K Pj4gRGlmZmVyZW50IHNoYXJpbmcgZ3JvdXBzIGNhbiBkZWNpZGUgaG93IHRoZXkgd2FudCB0byBz aGFyZSB0aGUgZGF0YS4gIElmDQo+PiBwZW9wbGUgd2VyZSB0byB1c2UgdGhlIG51bWVyaWNhbCB2 YWx1ZXMsIEkgYWdyZWUgaXQgd291bGQgYmUgaGVscGZ1bCB0byBoYXZlDQo+PiBndWlkYW5jZS4g IFRoaXMgY291bGQgZ28gaW4gdGhlIElPREUgZ3VpZGFuY2UgZG9jdW1lbnQuDQo+Pg0KPj4gSSBo YXZlIHNlZW4gZXhhbXBsZXMgb2YgY3VycmVudCB1c2VycyB0aGF0IHVzZSBlYWNoIG9mIHRoZSBh cHByb2FjaGVzLCBzbw0KPj4gd2UnbGwgbmVlZCB0byBrZWVwIHRoZSBvcHRpb24gZm9yIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IGFuZCBpdCBpcyBuaWNlIHRvDQo+PiBrZWVwIGluIGZsZXhpYmxl IG9wdGlvbnMgd2hlcmUgd2UgY2FuLg0KPj4NCj4+IFRoYW5rIHlvdSwNCj4+IEthdGhsZWVuDQo+ Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEhhcnJpbmd0b24sIENo cmlzdG9waGVyDQo+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyA5OjIyIEFNDQo+ PiBUbzogJ1Rha2VzaGkgVGFrYWhhc2hpJzsgTW9yaWFydHksIEthdGhsZWVuOyBTdG9lY2tlciwg UGF1bDsgJ01JTEUgSUVURicNCj4+IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KPj4NCj4+IFRo ZSBudW1iZXIgb2YgaW5kaWNhdG9ycyB3b3VsZG4ndCBuZWNlc3NhcmlseSBkcml2ZSB0aGUgdXNl IG9mDQo+PiBpbmRpY2F0b3Jfc2V0X2lkLiBUaGUgcHVycG9zZSBpcyB0byBzaG93IHJlbGF0aW9u c2hpcC4gSWYgSSBzZW50IDMgSVANCj4+IGFkZHJlc3NlcyB0aGF0IHdlcmUgdXNlZCBhcyBDMiBm b3IgMyBkaWZmZXJlbnQgY2FtcGFpZ25zIEkgd291bGQgaGF2ZQ0KPj4gc2VwYXJhdGUgaW5kaWNh dG9yX3NldF9pZHMsIGVhY2ggd2l0aCBvbmUgb2YgdGhlIDMgQzIgSVBzDQo+Pg0KPj4gTXkgc3Vn Z2VzdGlvbiB3b3VsZCBiZSBhIHNpbXBsZSBsb3csIG1lZGl1bSwgaGlnaC4gSSB0aGluayBpZiB3 ZSBicmVhayBpdA0KPj4gZG93biB0byBtb3JlIGxldmVscyB0aGFuIHRoYXQgd2Ugd291bGQgbmVl ZCB0byBwcm92aWRlIGd1aWRhbmNlIG9uIHNjb3JpbmcsDQo+PiByYXRpbmcsIGV0Yy4gSSB0aGlu ayBtb3N0IHBlb3BsZSBzaG91bGQgYmUgYWJsZSB0byB1bmRlcnN0YW5kIGxvdy9tZWQvaGlnaA0K Pj4gd2l0aG91dCBoYXZpbmcgdG8gaGF2ZSBhIG1hdGhlbWF0aWNhbCBtZXRob2QgZm9yIGFycml2 aW5nIGF0IHRoZSBsZXZlbC4NCj4+DQo+PiBMb3cgLSBJIGFtIG5vdCBzdXJlDQo+PiBNZWRpdW0g LSBJIGFtIHJlYXNvbmFibHkgc3VyZQ0KPj4gSGlnaCAtIEkgYW0gdmVyeSBzdXJlDQo+Pg0KPj4N Cj4+IFRoYW5rcywNCj4+DQo+PiAtLUNocmlzDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IFRha2VzaGkgVGFrYWhhc2hpIFttYWlsdG86dGFrZXNoaV90YWthaGFz aGlAbmljdC5nby5qcF0NCj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEzIDQ6MjEg QU0NCj4+IFRvOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgTW9yaWFydHksIEthdGhsZWVuOyBT dG9lY2tlciwgUGF1bDsgJ01JTEUgSUVURicNCj4+IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0K Pj4NCj4+IFJlZ2FyZGluZyB0aGUgaW5kaWNhdG9yX3NldF9pZCwgSSBhZ3JlZSwgaXQgaXMgdXNl ZnVsIHdoZW4gd2UgbmVlZCB0byBkZWFsDQo+PiB3aXRoIGxhcmdlIHNldHMgb2YgaW5kaWNhdG9y cy4NCj4+IFNpbmNlIGluZGljYXRvcl9zZXRfaWQgYXR0cmlidXRlIGlzIG9wdGlvbmFsIChyaWdo dD8pLCBpdCBjb3VsZCBiZSBvbWl0dGVkDQo+PiBpZiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBvbmx5 IHNtYWxsIG51bWJlciBvZiBpbmRpY2F0b3JzLg0KPj4NCj4+IFJlZ2FyZGluZyB0aGUgdXNlIGNh c2UsIEkgbGlrZSB0aGUgaWRlYSBvZiB1c2luZyB0aGUgY29uZmlkZW5jZSBhdHRyaWJ1dGUNCj4+ IGZvciB0aGUgcmVhc29uIENocmlzIGtpbmRseSBkZXNjcmliZWQuDQo+PiBJIHdvdWxkIGxpa2Ug dG8gaGVhciBhIGJpdCBtb3JlIG9uIHRoaXM6IGlzIGl0IGdvaW5nIHRvIGJlIG51bWVyaWNhbD8g Rm9yDQo+PiBpbnN0YW5jZSwgMSBtZWFucyAibm8gY29uZmlkZW5jZSIgd2hpbGUgNSBtZWFucyAi c3Ryb25nIGNvbmZpZGVuY2UiLCBldGM/DQo+Pg0KPj4gVGhhbmsgeW91Lg0KPj4gVGFrZQ0KPj4N Cj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBIYXJyaW5ndG9u LCBDaHJpc3RvcGhlciBbbWFpbHRvOkNocmlzdG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbV0NCj4+ PiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA4LCAyMDEzIDQ6MTEgQU0NCj4+PiBUbzogTW9yaWFy dHksIEthdGhsZWVuOyBUYWtlc2hpIFRha2FoYXNoaTsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFIElF VEYnDQo+Pj4gU3ViamVjdDogUkU6IFttaWxlXSBJT0NzDQo+Pj4NCj4+PiBXaXRoIHJlc3BlY3Qg dG8gdHlpbmcgdGhpbmdzIGJhY2sgdG8gdGhyZWF0IGFjdG9ycywgZnJvbSB3aGF0IEkgaGF2ZQ0K Pj4+IHNlZW4gYW5kIHVzZSB0aGlzIGlzIGEgZ2VuZXJhbGx5IGFjY2VwdGVkIGdyb3VwaW5nOg0K Pj4+DQo+Pj4gSW5kaWNhdG9yIC0tPiBJbmRpY3RvciBTZXQgLS0+IENhbXBhaWduIC0tPiBUaHJl YXQgQWN0b3INCj4+Pg0KPj4+IENhbXBhaWduIGFuZCBUaHJlYXQgQWN0b3IgYXJlIHdoZXJlIGhh dmluZyBhICJDb25maWRlbmNlIiBhdHRyaWJ1dGUNCj4+PiB3b3VsZCBiZSBiZW5lZmljaWFsIGFz IG1ha2luZyB0aG9zZSBhc3NvY2lhdGlvbnMgaXMgbm90IGEgcGVyZmVjdA0KPj4+IHNjaWVuY2Ug YnkgYW55IG1lYW5zLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gLS1DaHJpcw0KPj4+DQo+ Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IE1vcmlhcnR5LCBL YXRobGVlbg0KPj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNywgMjAxMyAyOjAwIFBNDQo+ Pj4gVG86IFRha2VzaGkgVGFrYWhhc2hpOyBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgU3RvZWNr ZXIsIFBhdWw7ICdNSUxFDQo+Pj4gSUVURicNCj4+PiBTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MN Cj4+Pg0KPj4+IEhpIFRha2UgJiBvdGhlcnMsDQo+Pj4NCj4+PiBUaGFua3MgZm9yIGNoaW1pbmcg aW4sIEkndmUgYmVlbiB0YWxraW5nIGFib3V0IHRoaXMgd2l0aCBDaHJpcyBhbmQgYQ0KPj4+IGZl dyBvdGhlcnMgb24gdGhlaXIgdXNlIGNhc2VzIGFuZCB3b3VsZCBsaWtlIG1vcmUgb3BpbmlvbnMu ICBJJ2xsDQo+Pj4gcHJvdmlkZSBhbiBvcHRpb24gYmVsb3cgZnJvbSB3aGF0IHdlIGhhdmUgZGlz Y3Vzc2VkIGZyb20gYSBDSVJDIHZpZXcNCj4+PiBwb2ludC4gIFdlIGFyZSBhbHNvIHdvbmRlcmlu ZyBob3cgdG8gYWxzbyBwcm92aWRlIGxvZ2ljIGluIElPREVGIHRoYXQNCj4+PiBjb3VsZCBjcm9z cyBvdmVyIGludG8gU0NJIGF0dGFjaGVkIHNjaGVtYXMgb3IgSU9ERUYgZXh0ZW5zaW9ucyAodGhl DQo+Pj4gc29sdXRpb25zIG1heSBhbGwgdGllIHRvZ2V0aGVyIHdpdGggdGhpcyBkaXNjdXNzaW9u IC0gb3IgdGhlcmUgbWF5IGJlDQo+Pj4gYmV0dGVyL21vcmUgZWxlZ2FudCBzb2x1dGlvbnMgb3Ro ZXJzIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSkuDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+IEZyb206IFRha2VzaGkgVGFrYWhhc2hpIFttYWlsdG86dGFrZXNoaV90YWth aGFzaGlAbmljdC5nby5qcF0NCj4+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxMyAx MjowNCBQTQ0KPj4+IFRvOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgU3RvZWNrZXIsIFBhdWw7 IE1vcmlhcnR5LCBLYXRobGVlbjsgJ01JTEUNCj4+PiBJRVRGJw0KPj4+IFN1YmplY3Q6IFJFOiBb bWlsZV0gSU9Dcw0KPj4+DQo+Pj4+IEkgbGlrZSB0aGlzIGRpc2N1c3Npb24uDQo+Pj4+IEkgYWdy ZWUsIGl0IHdvdWxkIGJlIGdvb2QgaWRlYSB0byBoYXZlIGluZGljYXRvciBpZGVudGlmaWVycyBp bnNpZGUNCj4+Pj4gdGhlIElPQy1yZWxhdGVkIGNsYXNzZXMuDQo+Pj4NCj4+PiBLTU06IEF0IHRo ZSBjbGFzcyBsZXZlbCwgd2UgbWF5IGhhdmUgc2V2ZXJhbCBpbmRpY2F0b3JzIGxpc3RlZCB0aGF0 DQo+Pj4gc2hvdWxkIGJlIHZpZXdlZCBhcyBhIHNldCBhbmQgbWF5IGhhdmUgYW5vdGhlciBpbnN0 YW5jZSBvZiB0aGF0IHNhbWUNCj4+PiBjbGFzcyB0aGF0IGlzIGEgcmVsYXRlZCBpc3N1ZSwgYnV0 IGEgc2VwYXJhdGUgc2V0LiAgV2UgY291bGQgYXMgeW91DQo+Pj4gc2F5LCBsaXN0IHRoZSBpbmRp Y2F0b3IgSURzIGNvbm5lY3RlZCB0aHJvdWdoIHRoZSByZWZlcmVuY2UgY2xhc3MuDQo+Pj4gVGhl IHNldCBJRHMgbWlnaHQgZ2l2ZSB1cyBvdGhlciB3YXlzIHRvIGdyb3VwIHRoZSB2YWx1ZXMgd2hl biB3ZSBnZXQNCj4+PiBpbnRvIGxvZ2ljIGFuZCByZWxhdGlvbnNoaXBzIGJldHdlZW4gc2V0cyBv ciBpbmRpY2F0b3JzLiAgVGhpcyBjb3VsZA0KPj4+IGFsc28gYmUgYSB3YXkgdG8gY29ubmVjdCBp bmRpY2F0b3JzIG9yIHNldHMgYWNyb3NzIFhNTCBkb2N1bWVudHMgdGhhdA0KPj4+IGNvdWxkIGhh dmUgYmVlbiBzaGFyZWQgcHJldmlvdXNseS4gIElmIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBv Zg0KPj4+IGluZGljYXRvcnMgaW4gdGhlIHNldCwgdGhlbiB0aGlzIGJlY29tZXMgdXNlZnVsLCBm b3Igc21hbGxlciBzZXRzLCBJDQo+Pj4gYWdyZWUgaXQgZG9lc24ndCBtYWtlIGFzIG11Y2ggc2Vu c2UuDQo+Pj4NCj4+PiBXaGF0IGRvIG90aGVycyB0aGluaz8NCj4+Pg0KPj4+Pj4gVGhlbiBmb3Ig aW5kaWNhdG9ycyBub3QgaW5jbHVkZWQgaW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IG5vdA0K Pj4+Pj4gZml0IGludG8gYSBjYXRlZ29yeSBpbiB0aGUgU0NJIGRyYWZ0LCBkbyB3ZSBjcmVhdGUg YSBwbGFjZSBmb3INCj4+Pj4+IHRoZXNlIG9mZiBvZiBTQ0kgb3IgcmlnaHQgb2ZmIG9mIHRoZSBJ T0RFIHNjaGVtYSBpbiBFdmVudERhdGE/DQo+Pj4+PiAobW9yZSBkZXRhaWxzDQo+Pj4gb24NCj4+ Pj4+IHRoaXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuDQo+Pj4+DQo+Pj4+IElmIHdlIGNvdWxkIHNl ZSBhbnkgaW5kaWNhdG9yIG9mIGNvbXByb21pc2UgYXMgY29tcHV0ZXIgZXZlbnQNCj4+Pj4gcmVj b3JkLCB3ZSBjb3VsZCB1c2UgU0NJOkV2ZW50UmVwb3J0IGNsYXNzIGFzIHRoZSBwbGFjZSBmb3Ig dGhlDQo+Pj4+IFhNTC1iYXNlZCBJT0NzIHRoYXQgY291bGRuJ3QgZml0IGFueXdoZXJlIGVsc2Uu DQo+Pj4NCj4+PiBLTU06IFRoYXQgc291bmRzIGxpa2UgYSBnb29kIGlkZWEgdG8gbWUuICBUaGlz IHNob3VsZCBnbyBpbnRvIGd1aWRhbmNlDQo+Pj4gaW4gdGhlIFNDSSBkcmFmdC4gIERvZXMgYW55 b25lIGVsc2Ugd2FudCB0byB3ZWlnaCBpbj8NCj4+Pg0KPj4+Pg0KPj4+PiBGb3IgdGhlIG5vbi1Y TUwgSU9Dcywgd2UgY291bGQgdXNlIFJlY29yZERhdGEgY2xhc3MsIGFzIHN1Z2dlc3RlZC4NCj4+ PiBLTU06IFNvdW5kcyBnb29kLCB0aGFua3MhDQo+Pj4NCj4+Pj4gSSBhZ3JlZSB0byBoYXZlIGlu ZGljYXRvcl91aWQsIGJ1dCBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBuZWVkcyBvZg0KPj4+PiB0 aGUgaW5kaWNhdG9yX3NldF9pZC4NCj4+Pj4gSSB1bmRlcnN0YW5kIHdlIGNvdWxkIGRvIHNvbWUg Z3JvdXBpbmcgb2YgaW5kaXZpZHVhbCBpbmRpY2F0b3JfdWlkcw0KPj4+PiBhbmQgaXRzIHVzYWJp bGl0eSwgYnV0IEkgYW0gbm90IHN1cmUgd2hldGhlciB3ZSBkbyBub3QgaGF2ZSBhbnkNCj4+Pj4g b3RoZXIgd2F5IHRvIGV4cHJlc3MgdGhlc2UgZ3JvdXBpbmdzLg0KPj4+PiBGb3IgaW5zdGFuY2Us ICBhIFJlZmVyZW5jZSBjbGFzcyByZWZlcnMgdG8gc2V2ZXJhbCBpbmRpY2FkdG9yX3VpZHMuDQo+ Pj4gSW4NCj4+Pj4gdGhpcyBjYXNlLCB0aGV5IGNvdWxkIGJlLCBpbiBhIHNlbnNlLCBncm91cGVk LiBJc24ndCBpdCBlbm91Z2g/DQo+Pj4NCj4+PiBLTU06IEl0IG1heSBiZSwgd2hhdCBkbyB5b3Ug dGhpbmsgYWJvdXQgbGFyZ2Ugc2V0cyBvZiBpbmRpY2F0b3JzIG9yDQo+Pj4gc3Vic2VxdWVudCBt ZXNzYWdlcyB0aGF0IGFkZCBpbmRpY2F0b3JzIHRvIGV4aXN0aW5nIHNldHM/ICBXb3VsZCB0aGlz DQo+Pj4gaGFwcGVuPyAgV291bGQgaXQgYmUgZWFzaWVyIHRvIGV4cHJlc3MgcmVsYXRpb25zaGlw cyB3aXRoIHNldHMgb2YNCj4+PiBpbmRpY2F0b3JzIGluIGFkZGl0aW9uIHRvIGluZGl2aWR1YWwg aW5kaWNhdG9ycz8gIEJ5IHVzaW5nIHRoaXMsIGl0DQo+Pj4gY291bGQgZ2l2ZSB1cyBhIHVuaXF1 ZSB3YXkgdG8gYWxzbyBwcm92aWRlIHRoZSBsb2dpYyBhbmQgcmVsYXRpb25zaGlwcw0KPj4+IGlu IGEgbmV3IGNsYXNzIG9mIElPREVGIHNvIHdlIGRvbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgYWRk aW5nIGl0IGludG8NCj4+PiB0aGUgY3VycmVudA0KPj4gc3RydWN0dXJlLg0KPj4+IElmIHRoZXJl IGFyZSBiZXR0ZXIgd2F5cyB0byBoYW5kbGUgdGhhdCwgYW5kIG90aGVycyBjYW4gcHJvdmlkZSBz b21lDQo+Pj4gb3B0aW9ucywgdGhhdCB3b3VsZCBiZSBhcHByZWNpYXRlZCENCj4+Pg0KPj4+IFRo YW5rIHlvdSwNCj4+PiBLYXRobGVlbg0KPj4+DQo+Pj4+IEkgd291bGQgYXBwcmVjaWF0ZSBpZiBh bnlib2R5IGNvdWxkIHNoYXJlIGV4cGVydGlzZSBvbiB0aGlzLiBUaG91Z2gNCj4+PiBJDQo+Pj4+ IHRoaW5rIEkgaGF2ZSByZWFkIGFsbCB0aGUgZW1haWxzIGluIHRoZSBsaXN0LCBJIG1pZ2h0IGhh dmUNCj4+Pj4gbWlzLXVuZGVyc3Rvb2Qgc29tZSBwb2ludHMuDQo+Pj4+DQo+Pj4+IEJ5IHRoZSB3 YXksIEkgdGhpbmsgdGhlIGluZGljYXRvcl91aWRzIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgU0NJ DQo+PiBjbGFzc2VzJw0KPj4+PiBhdHRyaWJ1dGVzIHNvIHRoYXQgdGhleSBjYW4gYmUgY29ycmVs YXRlZCB3aXRoIGFub3RoZXIgaW5mb3JtYXRpb24NCj4+Pj4gYXMNCj4+PiB3ZWxsLg0KPj4+Pg0K Pj4+PiBUaGFua3MNCj4+Pj4gVGFrZQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IEZyb206IG1pbGUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ Pj4gT2YgSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXINCj4+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAwNSwgMjAxMyA0OjI1IEFNDQo+Pj4gVG86IFN0b2Vja2VyLCBQYXVsOyBNb3JpYXJ0eSwgS2F0 aGxlZW47IE1JTEUgSUVURg0KPj4+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPj4+DQo+Pj4g SSB0aGluayBzb21lIHNvcnQgb2YgZ3JvdXAgSUQgd291bGQgZG8gdGhlIHRyaWNrLiBXZSBhbHNv IG5lZWQgYQ0KPj4+IGxvZ2ljYWwgYW5kIC8gb3Igc29tZXdoZXJlIHRvIHNob3cgcmVsYXRpb25z aGlwIGJldHdlZW4gaW5kaWNhdG9ycy4gSWYNCj4+PiBJIGdpdmUgeW91DQo+Pj4gMg0KPj4+IHJl Z2lzdHJ5IGtleXMgZG8gdGhleSBib3RoIGhhdmUgdG8gYmUgcHJlc2VudCB0byBiZSBhbiBpbmRp Y2F0aW9uIG9mDQo+Pj4gY29tcHJvbWlzZSBvciBpcyBlaXRoZXIgb25lIGJ5IHRoZW1zZWx2ZXMg YW4gaW5kaWNhdG9yPyBCb3RoIHdvdWxkDQo+Pj4gaGF2ZSB0aGUgc2FtZSBncm91cCBJRCBzaW5j ZSB0aGV5IGFyZSByZWxhdGVkLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IC0tQ2hyaXMNCj4+Pg0K Pj4+IEZyb206IFN0b2Vja2VyLCBQYXVsDQo+Pj4gU2VudDogU3VuZGF5LCBGZWJydWFyeSAwMywg MjAxMyA4OjI2IFBNDQo+Pj4gVG86IE1vcmlhcnR5LCBLYXRobGVlbjsgSGFycmluZ3RvbiwgQ2hy aXN0b3BoZXI7IE1JTEUgSUVURg0KPj4+IFN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KPj4+DQo+ Pj4gV2hhdCBpZiB3ZSBhZGRlZCBpbmRpY2F0b3IgZ3JvdXAgSUQgYWxvbmcgd2l0aCB0aGUgaW5k aWNhdG9yX3VpZD8NCj4+PiBUaGlzIHdvdWxkIGFsbG93IHlvdSB0byBncm91cCBpbmRpY2F0b3Jz IHRoYXQgYXJlIHJlbGF0ZWQgaW50byB0aGUNCj4+PiBzYW1lIGdyb3VwIElELg0KPj4+IFdvdWxk IHRoaXMgcmVzb2x2ZSB0aGUgaXNzdWU/DQo+Pj4NCj4+PiBJdCBpcyBlaXRoZXIgdGhhdCBvciBn b2luZyBiYWNrIHRvIGFkZGluZyBhIERldGVjdGlvbiAob3IgSW5kaWNhdG9ycykNCj4+PiBjbGFz cyB0aGF0IHdpbGwgc2hvdWxkIGJlIHVzZWQgdG8gdGFrZSBhbGwgb2YgdGhlIGluZGljYXRvcnMg cHV0IHRoZW0NCj4+PiBpbnRvIG9uZSBwbGFjZSBhbmQgaGF2ZSB0aGUgYWJpbGl0eSB0byBncm91 cCB0aGUgb25lcyB0aGF0IGdvDQo+Pj4gdG9nZXRoZXIuICBJIGRvbid0IG1lYW4gYSBwbGFjZSB0 byBwdXQgaW5kaWNhdG9ycyB0aGF0IGFyZSBtaXNzaW5nDQo+Pj4gZnJvbSBJT0RFRi5JIG1lYW4g YSBwbGFjZSBpbiB0aGUgSU9ERUYgZG9jdW1lbnQgd2hlcmUgeW91IHB1dCB0aGUNCj4+PiBpbmRp Y2F0b3JzIHRoYXQgYXJlIHVzZWQgZm9yIGRldGVjdGlvbiBhbmQgcHJldmVudGlvbiBvZiB0aGUg c2hhcmVkDQo+Pj4gSW5jaWRlbnQuICBJIGRvbid0IGtub3cgdGhlIGFuc3dlciBoZXJlLCBidXQg dGhlcmUgaGFzIGdvdCB0byBiZSBhDQo+Pj4gZ29vZCB3YXkgZm9yIGluZGljYXRvcnMgdG8gYmUg aWRlbnRpZmllZCBhbmQgYmVpbmcgYWJsZSB0byBncm91cCB0aGVtDQo+Pj4gYXMgQ2hyaXMgaGFz IHN1Z2dlc3RlZCB3aXRob3V0IGJhc2ljYWxseSByZWNyZWF0aW5nIHNvbWV0aGluZw0KPj4+IGNv bXBsaWNhdGVkIGxpa2UgU1RJWC4NCj4+Pg0KPj4+IFBhdWwNCj4+Pg0KPj4+DQo+Pj4gUGF1bCBX LiBTdG9lY2tlciwgUGguRC4NCj4+PiBTTUMgTGVhZCBDb250ZW50IEFyY2hpdGVjdA0KPj4+IFJT QSwgVGhlIFNlY3VyaXR5IERpdmlzaW9uIG9mIEVNQw0KPj4+IGNlbGw6IDMwMi4zNzkuMzM3NSB8 IGU6IHBhdWwuc3RvZWNrZXJAcnNhLmNvbQ0KPj4+DQo+Pj4NCj4+PiBGcm9tOiA8TW9yaWFydHk+ LCBLYXRobGVlbiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbT4NCj4+PiBEYXRlOiBTdW5kYXks IEZlYnJ1YXJ5IDMsIDIwMTMgNToxMSBQTQ0KPj4+IFRvOiAiSGFycmluZ3RvbiwgQ2hyaXN0b3Bo ZXIiIDxDaHJpc3RvcGhlci5IYXJyaW5ndG9uQGVtYy5jb20+LCBNSUxFDQo+Pj4gSUVURiA8bWls ZUBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW21pbGVdIElPQ3MNCj4+Pg0KPj4+IEhpIENo cmlzLA0KPj4+DQo+Pj4gSSBhZ3JlZSwgd2UgaGF2ZSBzb21lIHdvcmsgdG8gZG8gaW4gdGhlIHVw ZGF0ZWQgSU9ERUYsIFJGQzUwNzAtYmlzLg0KPj4+DQo+Pj4gVGhlIGxpc3QgaGFzIGFscmVhZHkg c2FpZCB0aGV5IHdvdWxkIGxpa2UgdG8gc2VlIGluZGljYXRvcnMgYWRkZWQgdG8NCj4+PiB0aGUg ZGVmaW5pdGlvbnMgaW4gUkZDNTA3MC1iaXMsIHRvIGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgaW5j bHVkaW5nDQo+Pj4gaW5kaWNhdG9ycyBhbmQgc2V0cyBvZiBpbmRpY2F0b3JzIGluIElPREUgZG9j dW1lbnRzIGFzIG9wcG9zZWQgdG8NCj4+PiAncGFydHMgb2YgYW4gaW5jaWRlbnQgb3IgdGhlIHVz ZWZ1bCBpbmZvcm1hdGlvbiBvbiBhbiBpbmNpZGVudCBmb3INCj4+PiBzaGFyaW5nIHB1cnBvc2Vz LiAgSXQgd2FzIHdyaXR0ZW4gYmVmb3JlIHdlIHVzZWQgdGVybXMgbGlrZQ0KPj4+IGluZGljYXRv cnMuICBXaXRoIHRoYXQgaW4gbWluZCwgUm9zZWxsYSBwcm9wb3NlZCBhIG51bWJlciBvZiBjaGFu Z2VzDQo+Pj4gYmFjayBpbiBKdWx5LCBib3RoIGZvciBndWlkYW5jZSBhbmQgZm9yDQo+PiBmb3Jt YXQNCj4+PiB1cGRhdGVzLiAgSXQgbWF5IGhlbHAgdG8gaGF2ZSB0aGUgZmlyc3QgZHJhZnQgdHJ5 IHRvIGFkZHJlc3MgYXQgbGVhc3QNCj4+PiBzb21lIG9mIHRoZXNlIGlzc3VlcyBzbyBwZW9wbGUg Y2FuIHVuZGVyc3RhbmQgdGhlIHByb2JsZW1zIGFuZCBhdA0KPj4+IGxlYXN0IGEgcHJvcG9zZWQg c29sdXRpb24uDQo+Pj4NCj4+PiBBcyB5b3UgcG9pbnQgb3V0LCB3ZSBuZWVkIHRvIGJlIGFibGUg dG8gc2hvdyByZWxhdGlvbnNoaXBzIGJldHdlZW4NCj4+PiBzZXRzIG9mIGluZGljYXRvcnMsIHdo ZXJlIHdlIG1heSBoYXZlIGEgZmV3IHNldHMgb2YgaW5kaWNhdG9ycyB0aGF0DQo+Pj4gY291bGQg aGF2ZSBhIHJlbGF0aW9uc2hpcCB0byBlYWNoIG90aGVyIHdpdGhpbiBhIGRvY3VtZW50LiAgSW4g dGhlDQo+Pj4gSnVseSBwcmVzZW50YXRpb24sIG9uZSBvZiB0aGUgcXVlc3Rpb25zIHdhcyB0byBz ZWUgaWYgd2Ugc2hvdWxkIGFkZA0KPj4+IG5ldyBjYXRlZ29yeSBhdHRyaWJ1dGUgdmFsdWVzIGZv ciB0aGUgU3lzdGVtIGNsYXNzIHRoYXQgd291bGQgY29ubmVjdA0KPj4+IHRoZSBsaXN0IG9mIGlu Y2x1ZGVkIGluZGljYXRvcnMuICBJIHRoaW5rIHdlIHNob3VsZCBzdGlsbCBrZWVwIHRoZQ0KPj4+ IGNvbmNlcHQgb2YgYSBOb2RlIHRvIGEgc2luZ2xlIG5vZGUsIGJ1dCBwZXJoYXBzIHdpdGhpbiBT eXN0ZW0sIGxpc3QNCj4+PiBtdWx0aXBsZSBzZXRzIG9mIE5vZGVzIHRoYXQgbWF5IGJlIG9uZSB0 eXBlIG9mIGF0dGFjay4gIFJvc2VsbGEgaGFkDQo+Pj4gc3VnZ2VzdGVkIHB1bGxpbmcgZm9yd2Fy ZCB0aGUgIkZyYXVkVHlwZSIgZnJvbSBSRkM1OTAxLCB0aGlzIHdvdWxkDQo+Pj4gaGVscCBzb2x2 ZSB0aGUgaXNzdWUgYXMgTm9kZVJvbGUgdmFsdWVzIHdvdWxkIGNvbXBsaW1lbnQgYW4gQXR0YWNr VHlwZQ0KPj4+IChGcmF1ZFR5cGUgdmFsdWVzIGNvdWxkIGJlIGluY2x1ZGVkIGluIEF0dGFja1R5 cGUgb3Igc29tZSBicm9hZGVyDQo+Pj4gdGVybSkuICBJdCBtYXkgYmUgYmV0dGVyIHRvIGhhdmUg dGhlIEZyYXVkVHlwZXMsIHBsdXMgYXR0cmlidXRlIHZhbHVlcw0KPj4+IGxpa2UgIkMyLXNlcnZl ciIsICJzaW5raG9sZSIsICAiTWFsd2FyZURpc3RyaWJ1dGlvbiIgZm9yIGFkZGVkIGNvbnRleHQN Cj4+PiBzbyB5b3Uga25vdyB3aGF0IHRvIGRvIHdpdGggdGhlIHJlY2VpdmVkIHNldCBvZiBpbmRp Y2F0b3JzLg0KPj4+DQo+Pj4gSSBhbSBwcm9wb3NpbmcgdGhhdCB3ZSBjaGFuZ2UgSU9ERUYgdG8g aW5jbHVkZSBtdWx0aXBsZSBzZXRzIG9mDQo+PiBpbmRpY2F0b3JzLA0KPj4+IGFkZCBhbiBBdHRh Y2tUeXBlIGF0dHJpYnV0ZSAob3Igc29tZSBvdGhlciBuYW1lKSwgYSBtZXRob2QgdG8gY29ubmVj dA0KPj4+IGluZGljYXRvcnMgYW5kIGluZGljYXRvciBzZXRzIHdpdGhpbiBhbiBJT0RFRiB1c2lu ZyBhbiBhdHRyaWJ1dGUgb2YNCj4+PiBpbmRpY2F0b3JfdWlkIChvciBzb21lIG90aGVyIG5hbWUp IHdpdGggYSBzdHJpbmcgdmFsdWUgdG8gbWFrZSB0aGUNCj4+PiBjb25uZWN0aW9uIHBvaW50cywg YW5kIGFkZCBhIGZldyBpbmRpY2F0b3JzIHRoYXQgYXJlIGNvbW1vbmx5IHNoYXJlZA0KPj4+IGlu dG8gdGhlIGJhc2UgSU9ERUYuDQo+Pj4NCj4+PiBCYWNrIGluIEp1bHksIHdlIHRhbGtlZCBhYm91 dCBhZGRpbmcgUmVnaXN0cnkgS2V5L1ZhbHVlIHBhaXJzIGFuZA0KPj4+IGhhc2hlcyB0byB0aGUg bWFpbiBJT0RFRiBkb2N1bWVudCAodHJ5aW5nIHRvIHNlZSBpZiB0aGlzIHdpbGwgaGVscA0KPj4+ IENocmlzIGJlbG93KS4gIFdoYXQgaWYgd2UgYWRkZWQgdGhlIFJlZ2lzdHJ5IEtleS9WYWx1ZSBw YWlycyBhcyBhDQo+Pj4gY2xhc3Mgb2ZmIG9mIFJlY29yZERhdGEsIHVzaW5nIGEgc2ltaWxhciBz dHJ1Y3R1cmUgdG8gd2hhdCBpcyBpbg0KPj4+IFJGQzU5MDEsIGFuZCBhbHNvIGFkZGVkIHRoZSBh YmlsaXR5IHRvIGluY2x1ZGUgaGFzaGVzIGluIFJlY29yZERhdGE/DQo+Pj4gSSB0aGluayBpZiB3 ZSB0aGVuIGhhZCB0aGUgaW5kaWNhdG9yX3VpZCBhdCB0aGUgUmVjb3JkRGF0YSBsZXZlbCwgd2UN Cj4+PiBjb3VsZCBjb25uZWN0IGEgc2V0IHdpdGhpbiB0aGF0IHN0cnVjdHVyZSBhbmQgcmVwZWF0 IHRoZSBzdHJ1Y3R1cmUgZm9yDQo+Pj4gb3RoZXIgc2V0cyBpbiB0aGUgc2FtZSB3YXkgd2Ugd291 bGQgZG8gd2l0aCBOb2RlIGluc2lkZSBvZiB0aGUgU3lzdGVtDQo+Pj4gY2xhc3MsIHVzaW5nIHRo ZSBpbmRpY2F0b3JfdWlkIHRvIHRpZSB0aGUgc2V0IHRvZ2V0aGVyLiAgVGhlbiBhdCB0aGUNCj4+ PiBtb3JlIHNwZWNpZmljIGxldmVsIGZvciB0aGUgaGFzaCwgcmVnaXN0cnkgS2V5L3ZhbHVlLCBJ UCwgZXRjLiB1c2UgYW4NCj4+PiBpbmRpY2F0b3JfdWlkIGlmIHdlIG5lZWRlZCB0aGVtIG1hcmtl ZCBhdCB0aGlzIGxldmVsIGFzIHdlbGw/ICBNYXliZQ0KPj4+IHdlIHdhbnQgaW5kaWNhdG9yX3Nl dCBhdCB0aGUgaGlnaGVyIGxldmVsPyAgSSdkIGxpa2Ugc29tZSBvcGluaW9ucyBvbg0KPj4+IHRo aXMgYXBwcm9hY2guICArMSBpZiB5b3UgYWdyZWUsIHN1Z2dlc3Rpb25zIGlmIHlvdSBoYXZlIG90 aGVyIGlkZWFzDQo+Pj4gdGhhdCBtYXkgd29yayBiZXR0ZXIuDQo+Pj4NCj4+PiBXZSdsbCBhbHNv IG5lZWQgdG8gd29ycnkgYWJvdXQgbWFya2luZyB0aGUgaW5kaWNhdG9ycyB0byBwcmV2ZW50DQo+ Pj4gZm9yd2FyZCBzaGFyaW5nIHdoZW4gbm90IHBlcm1pdHRlZC4gIFdlIG1heSB3YW50IHRvIHVz ZSB0aGVzZSB2YWx1ZXMNCj4+PiBvciBzb21ldGhpbmcgZWxzZS4NCj4+Pg0KPj4+IFRoYW5rIHlv dSENCj4+PiBLYXRobGVlbg0KPj4+DQo+Pj4gRnJvbTogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXIN Cj4+PiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAxLCAyMDEzIDEyOjAxIFBNDQo+Pj4gVG86IE1v cmlhcnR5LCBLYXRobGVlbjsgTUlMRSBJRVRGDQo+Pj4gU3ViamVjdDogUkU6IFttaWxlXSBJT0Nz DQo+Pj4NCj4+PiBJIHRoaW5rIHdlIGhhdmUgYSBiaWdnZXIgcmVsYXRpb25zaGlwIGlzc3VlIHRv IGFkZHJlc3MuIExldCB1c2UgdGhlDQo+Pj4gV2F0Y2hsaXN0IFVzZSBDYXNlLiBBIGJ1bmNoIG9m IGluZGljYXRvcnMgYXJlIHNlbnQgaW4gb25lIG1lc3NhZ2UuIEluDQo+Pj4gdGhhdCBtZXNzYWdl IHdlIGNvdWxkIGhhdmUgZ3JvdXBpbmdzIG9mIGluZGljYXRvcnMgdGhhdCB3ZSBuZWVkIHRvDQo+ Pj4gc2hvdyBhcmUNCj4+PiByZWxhdGVkOg0KPj4+DQo+Pj4gVHdvIG9yIG1vcmUgaW5kaWNhdG9y cyBvZiBkaWZmZXJlbnQgdHlwZSB0aGF0IHJlbGF0ZSB0byB0aGUgc2FtZSB0aHJlYXQ6DQo+Pj4g ICAgICAgVGhlIGZpbGUgaGFzaCBvZiBhIG1hbGljaW91cyBmaWxlIGFuZCB0aGUgVVJMIG9mIHRo ZSBDMiB0aGF0DQo+Pj4gdGhlIGZpbGUgdXNlcy4gRWl0aGVyIG9yIGJvdGggbWF5IGJlIHByZXNl bnQgdG8gaW5kaWNhdGUgYSBjb21wcm9taXNlLg0KPj4+DQo+Pj4gVHdvIG9yIG1vcmUgaW5kaWNh dG9ycyBvZiB0aGUgc2FtZSB0eXBlIHRoYXQgcmVsYXRlIHRvIHRoZSBzYW1lIHRocmVhdDoNCj4+ PiAgICAgICAyIGRpZmZlcmVudCByZWdpc3RyeSB2YWx1ZXMgZm9yIHRoZSBzYW1lIHJlZ2lzdHJ5 IGtleS4gSWYNCj4+PiBlaXRoZXIgdmFsdWUgaXMgcHJlc2VudCBpdCBpcyBhIGNvbXByb21pc2Ug aW5kaWNhdG9yIGJ1dCBib3RoIHdpbGwgbm90DQo+Pj4gYmUNCj4+IHByZXNlbnQuDQo+Pj4NCj4+ PiBUaGUgcHJvYmxlbSBjb21wb3VuZHMgaXRzZWxmIHZlcnkgcXVpY2tseS4gQ29uc2lkZXIgdGhl IHNjZW5hcmlvIHdoZXJlDQo+Pj4gYm90aCBncm91cGluZ3MgYWJvdmUgYXJlIHBhcnQgb2YgdGhl IHNhbWUgdGhyZWF0LiBJIG5lZWQgdG8gc2hvdyB0aGF0DQo+Pj4gbG9naWNhbCBncm91cGluZ3Mg b2YgSW5kaWNhdG9ycyBhcmUgcmVsYXRlZCBhcyB3ZWxsLiBXZSBjYW4ndCBzZW5kDQo+Pj4gbXVs dGlwbGUgSU9ERUYgbWVzc2FnZXMgZm9yIHRoaXMgZnJvbSB3aGF0IEkgcmVtZW1iZXIgcmVhZGlu Zy4NCj4+Pg0KPj4+IFRoZSBsYXN0IG9uZSBJIGNhbiB0aGluayBvZiB3b3VsZCBiZSB3aGVuIHlv dSBoYXZlIDIgZGlmZmVyZW50DQo+Pj4gaW5kaWNhdG9ycyB0aGF0IHJlcHJlc2VudCB0aGUgc2Ft ZSBpbmRpY2F0b3IuIEl0J3Mgbm90IHVuY29tbW9uIHRvDQo+Pj4gc2VuZCBib3RoIHRoZQ0KPj4+ IE1ENQ0KPj4+IGFuZCBTSEExIGhhc2ggb2YgYSBtYWxpY2lvdXMgZmlsZS4gVGhlIGluZGljYXRv ciBpcyB0aGUgZmlsZSBidXQgdGhlDQo+Pj4gSU9DcyBhcmUgdGhlIDIgaGFzaCB2YWx1ZXMuIEhv dyBkbyB3ZSBzaG93IHRoZXkgYXJlIHJlbGF0ZWQ/IElmIHdlIHVzZQ0KPj4+IGEgdW5pcXVlIElu aWRjYXRvciBJRCBmb3IgZWFjaCBoYXNoIHZhbHVlIHRoZXJlIG5lZWRzIHRvIGJlIGEgaGlnaGVy DQo+Pj4gbGV2ZWwNCj4+IGdyb3VwaW5nLg0KPj4+DQo+Pj4gVGhvdWdodHM/DQo+Pj4NCj4+PiBU aGFua3MsDQo+Pj4NCj4+PiAtLUNocmlzDQo+Pj4NCj4+PiBDaHJpc3RvcGhlciBIYXJyaW5ndG9u DQo+Pj4gQ29uc3VsdGluZyBTZWN1cml0eSBFbmdpbmVlcg0KPj4+IEdTTyAtIENyaXRpY2FsIElu Y2lkZW50IFJlc3BvbnNlIENlbnRlciBFTUMgLSBXaGVyZSBJbmZvcm1hdGlvbiBMaXZlcw0KPj4+ IDE3NCBNaWRkbGVzZXggVHVybnBpa2UNCj4+PiBCZWRmb3JkLCBNQSAwMTczMA0KPj4+IDc4MS01 MTUtNTg2MiAod29yaykNCj4+PiA2MDMtNTgzLTE1ODUgKGNlbGwpDQo+Pj4NCj4+PiBGcm9tOiBt aWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZg0KPj4+IE9mIE1vcmlhcnR5LCBLYXRobGVlbg0KPj4+IFNlbnQ6IEZyaWRheSwgRmVicnVh cnkgMDEsIDIwMTMgMTE6MjggQU0NCj4+PiBUbzogTUlMRSBJRVRGDQo+Pj4gU3ViamVjdDogUmU6 IFttaWxlXSBJT0NzDQo+Pj4NCj4+PiBBbGwgLQ0KPj4+DQo+Pj4gSSdkIGxpa2UgeW91ciBpbnB1 dCBhbmQgd2lsbCByZWZvY3VzIHRoZSB0aHJlYWQgdG8gZ2V0IG9waW5pb25zIGZyb20NCj4+PiB0 aGUgbGlzdCBvbiBvcHRpb25zIHRvIGhlbHAgc29sdmUgdGhlIHByb2JsZW1zIHJhaXNlZCBpbiBt eSBtZXNzYWdlDQo+Pj4gYW5kIGFkZGl0aW9uYWxseSBpbiBQYXVsJ3MgbWVzc2FnZS4NCj4+Pg0K Pj4+IEludGVyZXN0aW5nIHBvaW50LCBDLiBIZW5yeS4gIE91ciBvYmplY3RpdmUgaGVyZSBpcyB0 byBoYXZlIG1hY2hpbmUNCj4+PiBhdXRvbWF0ZWQgZXhjaGFuZ2VzLCBzbyB3ZSByZWx5IG9uIGVu Y3J5cHRpb24gcmF0aGVyIHRoYW4gb2JmdXNjYXRpb24NCj4+PiB0byBhY2hpZXZlIHRoZSBuZWNl c3NhcnkgbGV2ZWwgb2YgY29uZmlkZW50aWFsaXR5Lg0KPj4+DQo+Pj4gUGF1bCBtZW50aW9uZWQg dGhlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggaW5kaWNhdG9ycyBvZiBjb21wcm9taXNlIGZyb20NCj4+ PiBjb250ZXh0IGluZm9ybWF0aW9uIHRoYXQgbWF5IGFsc28gaW5jbHVkZSBJUCBhZGRyZXNzIG9y IG90aGVyIGRhdGENCj4+PiB0aGF0IGNvdWxkIGJlIGluZGljYXRvcnMuICBUaGUgcXVlc3Rpb24g SSByYWlzZWQgd2FzIG9uIGhvdyB0byBjb25uZWN0DQo+Pj4gc2V0cyBvZiBpbmRpY2F0b3JzIGlu IHRoZSBzYW1lIElPREVGIGRvY3VtZW50LCBhc3N1bWluZyB0aGUgYWJpbGl0eSB0bw0KPj4+IGhh dmUgd2F0Y2hsaXN0cyB0aGF0IGNvdWxkIGhhdmUgc2V2ZXJhbCBzZXRzIG9mIGluZGljYXRvcnMg aW5jbHVkZWQsDQo+Pj4gYXMgd2VsbCBhcyB0byBjb25uZWN0IGluZGljYXRvcnMgdGhhdCBtYXkg YmUgaW5jbHVkZWQgaW4gZW1iZWRkZWQNCj4+PiBzY2hlbWFzLg0KPj4+DQo+Pj4gSWYgd2UgYWRk IGFuIGF0dHJpYnV0ZSBvbiBhbGwgb2YgdGhlIHJlbGV2YW50IGluZGljYXRvcnMsIGxldCdzIHNh eQ0KPj4+ICdpbmRpY2F0b3ItdWlkJyBob3cgZG8gd2UgbWFyayB0aGUgaW5kaWNhdG9ycz8gIERv IHdlIHVzZSB0aGlzIHRvIG1hcmsNCj4+PiB3aG8gc2VudCB0aGUgaW5kaWNhdG9yIGFzIHdlbGwg c28gdGhhdCB3ZSBjYW4gcHJldmVudCBmb3J3YXJkIHNoYXJpbmcNCj4+PiB3aGVuIGl0IGlzIG5v dCBwZXJtaXR0ZWQgb3IgaGFuZGxlIHRoYXQgc2VwYXJhdGVseT8NCj4+Pg0KPj4+IFRoZW4gZm9y IGluZGljYXRvcnMgbm90IGluY2x1ZGVkIGluIHRoZSBiYXNlIHNjaGVtYSB0aGF0IG1heSBub3Qg Zml0DQo+Pj4gaW50byBhIGNhdGVnb3J5IGluIHRoZSBTQ0kgZHJhZnQsIGRvIHdlIGNyZWF0ZSBh IHBsYWNlIGZvciB0aGVzZSBvZmYNCj4+PiBvZiBTQ0kgb3IgcmlnaHQgb2ZmIG9mIHRoZSBJT0RF IHNjaGVtYSBpbiBFdmVudERhdGE/IChtb3JlIGRldGFpbHMgb24NCj4+PiB0aGlzIGluIG15IGZp cnN0IG1lc3NhZ2UpLg0KPj4+DQo+Pj4gQ29tbWVudHMgYW5kIHF1ZXN0aW9ucyBlbmNvdXJhZ2Vk IHRvIGZpZ3VyZSBvdXQgdGhlIHJpZ2h0IHRlY2huaWNhbA0KPj4+IHNvbHV0aW9uIHRvIGhhdmUg dGhpcyBtYWNoaW5lIGF1dG9tYXRhYmxlLg0KPj4+DQo+Pj4gVGhhbmsgeW91LA0KPj4+IEthdGhs ZWVuDQo+Pj4NCj4+PiBGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+IE9mIEMuDQo+Pj4gSGVucnkgQWRhbXMgJiBC SUUNCj4+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTMgMTE6MjUgUE0NCj4+PiBUbzog TUlMRSBJRVRGDQo+Pj4gU3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQo+Pj4NCj4+PiBUZW1wb3Jh bCBEZXBlbmRlbmN5IHNvdW5kcyBpbnRlcmVzdGluZy4gIEkgcmVtZW1iZXIgd2hlbiBJIGZpcnN0 IHJhbg0KPj4+IGFjcm9zcyB0aGlzIHBhcnRpY3VsYXIgY3JhZnQsIGFuIGV4cGVyaWVuY2VkIGNv bGxlYWd1ZSBhc2tlZCBtZSBhDQo+Pj4gcGVjdWxpYXIgcXVlc3Rpb24uICBIZSBzYWlkLCAiIEhv dyBkbyB5b3Ugc3RvcCBzb21lb25lIGZyb20gdHJhY2tpbmcNCj4+PiB0aGUgSVAgQWRkcmVzcyB0 byB5b3VyIGNvbXB1dGVyPyINCj4+Pg0KPj4+IEkgcmVwbGllZCwgIkkgZG9uJ3Qga25vdywgaG93 PyINCj4+Pg0KPj4+IFRoZW4gaGUgc2FpZCwgIkN1dCB0aGUgZG9nLWdvbmUgdGhpbmcgb2ZmICBh bmQgdGhlIG1vZGVtIHRoYXQgaXQgaXMNCj4+PiBjb25uZWN0ZWQtIHdoaWNoIGlzIGNvbnN0YW50 bHkgb24hIiAgIExPTA0KPj4+DQo+Pj4gSGVyZSdzIG15IHBvaW50IChIeXBvdGhldGljYWwgU2l0 dWF0aW9uKSA6ICBUaGVyZSBpcyBhIDFzdCBSZXNwb25kZXINCj4+PiBzZWFyY2hpbmcgYSBOZWln aGJvcmhvb2QgZm9yIFN1cnZpdm9ycyB3aGljaCB3ZXJlIGhpdCBieSBhIERpc2FzdGVyIG9yDQo+ Pj4gbGV0J3MganVzdCBzYXkgIkxpdmUiIFRlcnJvcmlzdCBTaXR1YXRpb24uICBIZSAvb3IgU2hl IG5lZWRzIHRvDQo+Pj4gY29tbXVuaWNhdGlvbiBiYWNrIHRvIG90aGVyIE9mZmljaWFscyB0aGF0 IGhlIC9vciBzb21laG93IGlzIGluDQo+Pj4gRGFuZ2VyLiAgVGhlIGRldmljZSB1c2VkIHRvIGNv bW11bmljYXRlIGhhcyBiZWVuIGNhcHR1cmVkIGJ5IHRoZSBncmVhdA0KPj4+IG1pbmRzIG9mIHRo ZSBlbmVteS4gIEl0J3Mgb25seSBhIG1hdHRlciBvZiB0aW1lIGJlZm9yZSB0aGV5IHV0aWxpemUN Cj4+PiByZXZlcnNlIGVuZ2luZWVyaW5nIHRvIGZpZ3VyZSBvdXQgaG93IGl0IGZ1bmN0aW9ucy4g IEhvd2V2ZXIsIHRoZWlyDQo+Pj4gcHJpZGUgY29tZXMgYmVmb3JlIGEgZmFsbCB3aGVuIHNlZWtp bmcgdGhlIGxvY2F0aW9uIG9mIG90aGVyIHNpbWlsYXINCj4+PiBkZXZpY2VzIHRvIGF0dGFjay4g IFdoeT8gUGVyaGFwcyB0aGUgbGVzcyB0aG91Z2h0IG9mIGNvbmNlcHRzIHRoYXQNCj4+PiBtYWtl cyB0aGUgZGV2aWNlIGZ1bmN0aW9uIHByb3Blcmx5LCBzYXZlcyB0aGUgZGF5IGJ5IGRpc2d1aXNl IG9yDQo+Pj4gY3V0dGluZyBpdCBvZmYgKGZpZ3VyYXRpdmVseSBzcGVha2luZykuDQo+Pj4NCj4+ PiBKdXN0IGEgdmlzaW9uYXJ5IHRob3VnaHQuDQo+Pj4NCj4+PiBDLiBIZW5yeSBBZGFtcw0KPj4+ IGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tDQo+Pj4gaHR0cDovL2JpZW1lZGlhZ3JvdXAu Y29tDQo+Pj4NCj4+Pg0KPj4+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUNCj4+PiBvcmlnaW5hbCByZWNpcGllbnQuIFRoaXMg aW5mb3JtYXRpb24gaXMgZ3JhbnRlZCBmb3IgbGltaXRlZA0KPj4+IGRpc3RyaWJ1dGlvbiB3aXRo aW4gdGhlIHJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZw0KPj4+IHB1 cnBvc2VzIG9ubHkuIEZ1cnRoZXIgZGlzc2VtaW5hdGlvbiwgd2hldGhlciBwcml2YXRlIG9yIHB1 YmxpYyBpcw0KPj4+IHByb2hpYml0ZWQuDQo+Pj4NCj4+PiAtLS0gT24gTW9uLCAxLzI4LzEzLCBE YXZlIE1pc2VsbCA8ZGF2aWQubWlzZWxsQGJjcy5vcmc+IHdyb3RlOg0KPj4+DQo+Pj4gRnJvbTog RGF2ZSBNaXNlbGwgPGRhdmlkLm1pc2VsbEBiY3Mub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbbWls ZV0gSU9Dcw0KPj4+IFRvOiAiQy4gSGVucnkgQWRhbXMgJiBCSUUiIDxjaGF0bGdhMjAwMEB5YWhv by5jb20+DQo+Pj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzLCA5OjI1IFBNIFVJRCBj b3VsZCBiZSBtaXJyb3JlZCB3aXRoIEROUw0KPj4+IFNFQyBhIHBlbWFuZW50IGFuZCB0ZW1wb3Jh bCBrZXksIHdpdGggYSB0ZW1wb3JhbCBJZD8NCj4+Pg0KPj4+IFlvdXJzIEZhaXRoZnVsbHksDQo+ Pj4NCj4+PiBEYXZlIE1pc2VsbCBNU2MgQ0lTU1ANCj4+PiBTaWxlbnRDaXJjbGUgIGRzbQ0KPj4+ IDA3NzEwIDM4MDA0NA0KPj4+IGRhdmlkLm1pc2VsbEBiY3Mub3JnDQo+Pj4NCj4+Pg0KPj4+IE9u IDI5IEphbiAyMDEzLCBhdCAwMDozOSwgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAw QHlhaG9vLmNvbT4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+PiBTZXJpYWxpemF0aW9uIG9mIGEgcGFy dGljdWxhciBMaXN0cyBvZiBYTUwgQ2xhc3NlcyBpbiBhIHVuaXF1ZSB3YXkNCj4+Pj4gd2FzDQo+ Pj4gY2xvc2VseSByZWxhdGVkIHRvIHdoYXQgSSBhdHRlbXB0ZWQgdG8gZXhwcmVzcyB3aGVuIEkg c3RhdGVkLA0KPj4+ICJjb25zaWRlciB0byBhIGRlZ3JlZSB3aGF0IGFwcGVhcnMgdG8gYmUgaWxs b2dpY2FsIGluIGJyaWxsaWFudCBtaW5kcw0KPj4+IGluIHNvbWUgaW5zdGFuY2VzLiINCj4+Pj4N Cj4+Pj4gSG93ZXZlciwgSSBzZWUgRHIuIFN0b2Vja2VyJ3MgcG9pbnQgYSBsaXR0bGUgY2xlYXJl ci4gIEhvd2V2ZXIsIGl0DQo+Pj4+IHdvdWxkDQo+Pj4gYmUgbmljZSBpZiB0aGUgVUlEIHdhcyBp biBzb21lIHdheSBkaXNndWlzZWQgZnJvbSB0aG9zZSB3aG8gc3R1ZHkgdGhpcw0KPj4+IFNlY3Vy aXR5IEFydCBGb3JtIGluIGEgbmVnYXRpdmUgd2F5Lg0KPj4+Pg0KPj4+PiBDLiBIZW5yeSBBZGFt cw0KPj4+PiBjaGF0bGdhMjAwMEB5YWhvby5jb20gKERpcmVjdCBFbWFpbCkgY2hlbnJ5YWRhbXNA YmllbWVkaWFncm91cC5jb20NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gaXMgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPj4+PiBvcmlnaW5h bA0KPj4+IHJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVk IGRpc3RyaWJ1dGlvbiB3aXRoaW4NCj4+PiB0aGUNCj4+PiByZWNpcGllbnQncyBwbGFjZSBvZiBi dXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlcg0KPj4+IGRpc3NlbWlu YXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGliaXRlZC4NCj4+Pj4NCj4+ Pj4gUmU6IFttaWxlXSBJT0NzDQo+Pj4+DQo+Pj4+IFN1bmRheSwgSmFudWFyeSAyNywgMjAxMyA4 OjUyIFBNDQo+Pj4+IEZyb206DQo+Pj4+ICJTdG9lY2tlciwgUGF1bCIgPFBhdWwuU3RvZWNrZXJA cnNhLmNvbT4NCj4+Pj4gVG86DQo+Pj4+ICJtaWxlQGlldGYub3JnIiA8bWlsZUBpZXRmLm9yZz4N Cj4+Pj4gSSB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgdGhpcyBmcm9tIGEgc2xpZ2h0bHkgZGlmZmVy ZW50DQo+Pj4+IHBlcnNwZWN0aXZlxaBsZXQncyBzYXkgSSBnZXQgYW4gWE1MIGRvY3VtZW50IHRo YXQgdGVsbHMgbWUgYWJvdXQgYW4NCj4+Pj4gaW5jaWRlbnQuICBUaGlzIGRvY3VtZW50IGhhcyBz b3VyY2UgSVAgYW5kIGRlc3RpbmF0aW9uIElQIHRoYXQgaXMNCj4+Pj4gYmVpbmcgc2hhcmVkLiAg SG93ZXZlciwgd2hhdCBJIGRvbid0IGtub3cgaXMgd2hpY2ggSVAgYWRkcmVzcyBpcyBteQ0KPj4+ PiBpbmRpY2F0b3IgYW5kIHdoaWNoIGlzIGp1c3QgYSBjb250ZXh0dWFsIHBpZWNlIG9mIGluZm9y bWF0aW9uLiAgVGhpcw0KPj4+PiBtZWFucyB0aGF0IG15IGRldGVjdGlvbiBwcm9kdWN0IGlzbid0 IGdvaW5nIHRvIGtub3cgd2hpY2ggb25lIHRvIHVzZQ0KPj4+PiBlaXRoZXIsIGJlY2F1c2UgdGhl cmUgaXMgbm90aGluZyB0byB0ZWxsIG1lIHdoaWNoIElQIGlzIHRoZSBvbmUsIGV2ZW4NCj4+Pj4g aWYgdGhlIHJvbGVzIGFyZSBzZXQgaXQgc3RpbGwgbWlnaHQgbm90IGJlIGVub3VnaCB0byB0ZWxs IG15IHN5c3RlbQ0KPj4+IHdoaWNoDQo+Pj4gb25lIEkgc2hvdWxkIHVzZSBhcyB0aGUgaW5kaWNh dG9yLg0KPj4+Pg0KPj4+PiBJZiB3ZSBoYWQgc29tZXRoaW5nIGxpa2UgaW5kaWNhdG9yX2lkIGFz IGFuIGF0dHJpYnV0ZSwgaXQgd291bGQgYWxsb3cNCj4+Pj4gdXMgdG8gZWFzaWx5IGlkZW50aWZ5 IGluZGljYXRvcnMgZnJvbSBjb250ZXh0dWFsIGRhdGEuICBJIGRvIGFkbWl0IHRvDQo+Pj4+IGJl aW5nIGJpYXNlZCBhcyBJIGhhdmUgc3BlbnQgbXVjaCBvZiBteSBjYXJlZXIgd29ya2luZyBvbiB0 aGUNCj4+Pj4gbW9uaXRvcmluZyBhbmQgZGV0ZWN0aW9uIHNpZGUgb2YgdGhlc2UgdGhpbmdzLCBz byBJIGFtIGp1c3QgdGhpbmtpbmcNCj4+Pj4gb2Ygd2F5cyB0byBtYWtlIGl0IHZlcnkgY2xlYXIg d2hhdCB0aGUgaW5kaWNhdG9ycyBhcmUgaW4gdGhlIFhNTA0KPj4+PiBkb2N1bWVudCBhbmQgdGhl IG90aGVyIGRhdGEgdGhhdCBtYXkgYmUgaW1wb3J0YW50IGFzIEkgaW52ZXN0aWdhdGUNCj4+Pj4g YWN0aXZpdHkgdGhhdCBJIGhhdmUgZGV0ZWN0ZWQgb2ZmIG9mIHRob3NlIGluZGljYXRvcnMuDQo+ Pj4+DQo+Pj4+DQo+Pj4+IEkgZGlkIHN1Z2dlc3QgdGhlIGRldGVjdGlvbiBjbGFzcywgYnV0IEkg dGhpbmsgd2UgbWF5IGdldCBtb3JlDQo+Pj4+IGZsZXhpYmlsaXR5IHdpdGggdGhlIGluZGljYXRv cl91aWQuICBPbmUgdGhpbmcgdGhhdCBJIGhhdmVuJ3QNCj4+Pj4gY29uc2lkZXJlZCBpcyB0aGUg VUlEIHBvcnRpb24gb2YgdGhpc8WgaG93IGRvIHdlIHVzZSB0aGF0IFVJRD8gIEhvdyBpcw0KPj4+ PiB0aGUgVUlEIGNyZWF0ZWQ/ICBBcmUgdGhlcmUgc3RhbmRhcmRzIGZvciBVSURzPw0KPj4+Pg0K Pj4+PiBSZWdhcmRzLA0KPj4+Pg0KPj4+PiBQYXVsDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFBh dWwgVy4gU3RvZWNrZXIsIFBoLkQuDQo+Pj4+IFNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0DQo+ Pj4+IFJTQSwgVGhlIFNlY3VyaXR5IERpdmlzaW9uIG9mIEVNQw0KPj4+PiBjZWxsOiAzMDIuMzc5 LjMzNzUgfCBlOiBwYXVsLnN0b2Vja2VyQHJzYS5jb20NCj4+Pj4NCj4+Pj4gLS0tIE9uIFNhdCwg MS8yNi8xMywgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbT4gd3Jv dGU6DQo+Pj4+DQo+Pj4+IEZyb206IEMuIEhlbnJ5IEFkYW1zICYgQklFIDxjaGF0bGdhMjAwMEB5 YWhvby5jb20+DQo+Pj4+IFN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KPj4+PiBUbzogIkthdGhs ZWVuTW9yaWFydHkiIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPg0KPj4+PiBDYzogbWlsZUBp ZXRmLm9yZw0KPj4+PiBEYXRlOiBTYXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMywgNjoxNyBQTQ0K Pj4+Pg0KPj4+PiBHcmVldGluZ3MgS2F0aGxlZW4sDQo+Pj4+DQo+Pj4+IFlvdXIgbG9naWMgc3Rp bXVsYXRlcyBteSB2aXNpb25hcnkgYnJhaW4gYmVjYXVzZSBJJ20gYW1hemVkIGF0IHRoZQ0KPj4+ PiBtYW55DQo+Pj4gYXZlbnVlcyB5b3UgcmV2aWV3IHdpdGggdGhpcyBhcHByb2FjaCBhdCBvbmNl LiAgSG93ZXZlciwgIGNvdWxkIHlvdSBzaGFyZQ0KPj4+IGENCj4+PiBmZXcgYWR2YW50YWdlcyBh bmQgZGlzYWR2YW50YWdlcyB0byB0aGUgbGF0dGVyPw0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gLS0t LS0tLS0NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+ICJ3ZSBjb3VsZCBjb250aW51ZSB0byBncm91cCBpdGVtcyBpbiBsb2dpY2FsIHBsYWNl cyBhcyBpcyBkb25lIG5vdyBpbg0KPj4+IElPREVGIGFuZCB0aGVuIGhhdmUgdGhlIGV4dGVuc2lv biBwb2ludCBmb3IgY29tYmluZWQgaW5kaWNhdG9ycyB2aWEgU0NJLiINCj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+IC0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4+DQo+Pj4+IFlvdSBwb2ludGVkIG91dCB3aGF0IHlvdSBjb25zaWRlciB0 byBiZSBsb2dpY2FsIHBsYWNlcywgYnV0IGlmIEkNCj4+Pj4gd2FudGVkIHRvDQo+Pj4gcHJvdGVj dCBpbmZvcm1hdGlvbiBmcm9tIHBhcnRpZXMgY2FwYWJsZSBvZiBhc2NlcnRhaW5pbmcgaXQgZnJv bSB5b3VyDQo+Pj4gbG9naWNhbCBwbGFjZXMsIHBlcmhhcHMgd2Ugc2hvdWxkIGFsc28gY29uc2lk ZXIgdG8gYSBkZWdyZWUgd2hhdCBhcHBlYXJzDQo+Pj4gdG8NCj4+PiBiZSBpbGxvZ2ljYWwgaW4g YnJpbGxpYW50IG1pbmRzIGluIHNvbWUgaW5zdGFuY2VzLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+ PiBDLiBIZW5yeSBBZGFtcw0KPj4+PiBjaGF0bGdhMjAwMEB5YWhvby5jb20gKERpcmVjdCBFbWFp bCkNCj4+Pj4gY2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20NCj4+Pj4NCj4+Pj4gVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZQ0KPj4+PiBvcmlnaW5hbA0KPj4+IHJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFu dGVkIGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbiB3aXRoaW4NCj4+PiB0aGUNCj4+PiByZWNpcGll bnQncyBwbGFjZSBvZiBidXNpbmVzcyBmb3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhl cg0KPj4+IGRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJvaGli aXRlZC4NCj4+Pj4NCj4+Pj4gLS0tIE9uIFNhdCwgMS8yNi8xMywgTW9yaWFydHksIEthdGhsZWVu IDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPg0KPj4+IHdyb3RlOg0KPj4+Pg0KPj4+PiBGcm9t OiBNb3JpYXJ0eSwgS2F0aGxlZW4gPGthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+DQo+Pj4+IFN1 YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KPj4+PiBUbzogIkMuIEhlbnJ5IEFkYW1zICYgQklFIiA8 Y2hhdGxnYTIwMDBAeWFob28uY29tPiwgIm1pbGVAaWV0Zi5vcmciDQo+Pj4gPG1pbGVAaWV0Zi5v cmc+DQo+Pj4+IERhdGU6IFNhdHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzLCAxMDoxMyBBTQ0KPj4+ Pg0KPj4+PiBIZWxsbyBDLiBIZW5yeSAmIG90aGVycywNCj4+Pj4NCj4+Pj4gVGhhbmtzIGZvciB0 YWtpbmcgYSBsb29rIGF0IHRoaXMuICBXZSBoYXZlIGEgZmV3IGNvbnNpZGVyYXRpb25zIGluDQo+ Pj4+IHRoaXMNCj4+PiBlbWFpbCB0aHJlYWQgSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhvdWdodHMg b24gKGFuZCB0aGVyZSBtYXkgYmUgbW9yZSBvbmNlDQo+Pj4gUkZDNTA3MC1iaXMgaXMgYWN0aXZl bHkgZWRpdGVkKS4NCj4+Pj4NCj4+Pj4gVGhlIEFkZGl0aW9uYWxEYXRhIGNsYXNzIGFuZCB0aGUg UmVjb3JkSXRlbSBjbGFzcyBib3RoIGFsbG93IGZvcg0KPj4+PiBub24tWE1MDQo+Pj4gZXh0ZW5z aW9ucy4gIFdoZXJlIHlvdSBwbGFjZSB0aGUgZXh0ZW5zaW9ucyBzaG91bGQgYmUgc3BlY2lmaWMg dG8gdGhlDQo+Pj4gbG9naWNhbCBncm91cGluZyBvZiB0aGUgcGFyZW50IGVsZW1lbnRzIHNvIHlv dSBjYW4gdW5kZXJzdGFuZCBtb3JlIGFib3V0DQo+Pj4gdGhlDQo+Pj4gaW5jbHVkZWQgZGF0YSBp biBtb3N0IGNhc2VzLg0KPj4+Pg0KPj4+PiBUaGUgSW1wYWN0IGNsYXNzIGNhbiBiZSB1c2VkIHRv IHByb3ZpZGUgY29udGV4dCBpbmZvcm1hdGlvbiBvbiB0aGUNCj4+PiBpbmNsdWRlZCBkYXRhIG9m IHRoZSByZXBvcnQgYW5kIGFsc28gY2FuIGluY2x1ZGUgYSBjb25maWRlbmNlIHJhdGluZyBvbg0K Pj4+IHRoZQ0KPj4+IHJlcG9ydCBhcyBhIHdob2xlLiAgRXh0ZW5zaW9ucyByZWxhdGVkIHRvIGlt cGFjdCB3b3VsZCBiZSBvbmUgbGV2ZWwgaGlnaGVyDQo+Pj4gKGF0IHRoZSBtb21lbnQpIGluIHRo ZSBBc3Nlc3NtZW50IGNsYXNzIHVzaW5nIHRoZSBBZGRpdGlvbmFsRGF0YSBleHRlbnNpb24NCj4+ PiBwb2ludC4NCj4+Pj4NCj4+Pj4gVGFrZSBhc2tlZCBhYm91dCBpbmNsdWRpbmcgdnVsbmVyYWJp bGl0eSBpbmZvcm1hdGlvbiwgSSB3b3VsZCB0aGluaw0KPj4+PiB0aGF0DQo+Pj4gd291bGQgZml0 IHVuZGVyIHRoZSBWdWxuZXJhYmlsaXR5IGV4dGVuc2lvbiBwb2ludCBvZiB0aGUgU0NJIGRyYWZ0 IGluDQo+Pj4gdGhlDQo+Pj4gTWV0aG9kIGNsYXNzLiAgSGUgZGlkIGFzayBhYm91dCBub24tWE1M LiAgUmVjb3JkSXRlbSBvciBBZGRpdGlvbmFsRGF0YQ0KPj4+IGRvDQo+Pj4gYWxsb3cgZm9yIG5v bi1YTUwgZXh0ZW5zaW9uIHBvaW50cywgd2UgY291bGQgZWl0aGVyIGhhdmUgdGhlIFNDSSBkcmFm dA0KPj4+IGhhbmRsZSB0aGVzZSBhcyB3ZWxsIG9yIGhhdmUgdGhlIGV4dGVuc2lvbnMgdGhhdCBh cmUgbm9uLVhNTCBjb21lIGRpcmVjdGx5DQo+Pj4gb2ZmIHRoZSBBZGRpdGlvbmFsRGF0YSBvciBS ZWNvcmRJdGVtIGNsYXNzZXMgYWNjb3JkaW5nIHRvIHdoYXQgbWFrZXMgc2Vuc2UNCj4+PiBmcm9t IGEgbG9naWNhbCBzdGFuZHBvaW50Lg0KPj4+Pg0KPj4+PiBBcyBmb3IgbXkgcXVlc3Rpb24sIGl0 IHdhcyB0d28tZm9sZC4NCj4+Pj4NCj4+Pj4gSW5kaWNhdG9yIGJhc2VkIHNjaGVtYXMgaGF2ZSBh IHJlZmVyZW5jZSBudW1iZXIgb3IgYSBHVUlEIGZvciB0aGUNCj4+Pj4gdmFyaW91cw0KPj4+IGlu ZGljYXRvcnMgdGhleSBzaGFyZS4gIElmIHdlIGFyZSBleHRlbmRpbmcgdG8gZW1iZWQgb3RoZXIg c2NoZW1hcyB0aGF0DQo+Pj4gaW5jbHVkZSBzdWNoIHJlZmVyZW5jZSBvciBHVUlEIGlkZW50aWZp ZXJzLCBkbyB3ZSB3YW50IHRvIGFkZCBhbiBhdHRyaWJ1dGUNCj4+PiB0byB0aGUgdmFyaW91cyBl bGVtZW50cyBpbiBJT0RFRiB0aGF0IGNvdWxkIGJlIGluZGljYXRvcnM/ICBJcyB0aGlzIGVub3Vn aA0KPj4+IHRvIG1ha2UgdGhlIGNvbm5lY3Rpb25zIG9yIGlzIHNvbWV0aGluZyBlbHNlIGVsc2Ug bmVlZGVkPyAgV2UgY291bGQgYWRkDQo+Pj4gc29tZXRoaW5nIGxpa2UgYW4gSW5kaWNhdG9yX0lE IGluIFJGQzUwNzAtYmlzIHdoaWNoIHdvdWxkIHRoZW4gY29ycmVsYXRlDQo+Pj4gdG8NCj4+PiB0 aGUgcmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMuDQo+Pj4+DQo+Pj4+IFRoZW4gdGhlIG90 aGVyIHF1ZXN0aW9uIHdhcyBvbiBob3cgdG8gaW5jbHVkZSBpbmRpY2F0b3JzIHRoYXQgYXJlIG5v dA0KPj4+PiBpbg0KPj4+IHRoZSBiYXNlIHNjaGVtYSB0aGF0IG1heSBiZSByZWxhdGVkIG9yIGhh dmUgbGFuZ3VhZ2Ugd2l0aCAiYW5kIiAib3IiIHRvDQo+Pj4gc3BlY2lmeSB0aGUgcmVsYXRpb25z aGlwcy4gIEluIHNvbWUgY2FzZXMsIHlvdSB3aWxsIHdhbnQgdG8gZ3JvdXAgdGhlc2UNCj4+PiBp bmRpY3RvcnMgaW4gb25lIGV4dGVuc2lvbiBwb2ludCwgd2hlcmUgdGhleSBtYXkgZml0IGxvZ2lj YWxseSBpbiBtdWx0aXBsZQ0KPj4+IHBsYWNlcyBpZiB0aGUgcmVsYXRpb25zaGlwcyBkaWQgbm90 IG5lZWQgdG8gYmUgc2hvd24gaW4gdGhlIGRhdGENCj4+PiBmb3JtYXQuICBJZg0KPj4+IHdlIGhh dmUgY2FzZXMgbGlrZSB0aGlzIHdoZXJlIHlvdSBuZWVkIG1vcmUgY29tcGxleCByZXByZXNlbnRh dGlvbnMsDQo+Pj4gc2hvdWxkDQo+Pj4gd2UgdXNlIG9uZSBleHRlbnNpb24gcG9pbnQgdmlhIHRo ZSBTQ0kgZHJhZnQgb2ZmIG9mIHRoZSBFdmVudERhdGEgY2xhc3MNCj4+PiBBZGRpdGlvbmFsRGF0 YSBleHRlbnNpb24gcG9pbnQ/ICBPcGluaW9ucyBhcmUgbmVlZGVkIGhlcmUuLi4uDQo+Pj4+DQo+ Pj4+IEEgZmV3IHBlb3BsZSBoYXZlIG1lbnRpb25lZCB3YW50aW5nIHRvIGluY2x1ZGUgc29tZSBj b21tb25seSBzaGFyZWQNCj4+PiBpbmRpY3RvcnMgaW50byB0aGUgYmFzZSBJT0RFRiBkb2N1bWVu dC4gIFdlIGNvdWxkIGhhdmUgYSBjYXRjaC1hbGwgY2xhc3MNCj4+PiB0aGF0IGRvZXMgdGhpcyBh bmQgaGFzIGFuIGV4dGVuc2lvbiBwb2ludCBvZmYgb2YgaXQgaW4gRXZlbnREYXRhIG9yIHdlDQo+ Pj4gY291bGQNCj4+PiBjb250aW51ZSB0byBncm91cCBpdGVtcyBpbiBsb2dpY2FsIHBsYWNlcyBh cyBpcyBkb25lIG5vdyBpbiBJT0RFRiBhbmQNCj4+PiB0aGVuDQo+Pj4gaGF2ZSB0aGUgZXh0ZW5z aW9uIHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZpYSBTQ0kuICBJIHRoaW5rIEkgbGlr ZQ0KPj4+IHRoZSBsYXR0ZXIgYXBwcm9hY2guDQo+Pj4+DQo+Pj4+IFRoYW5rIHlvdSwNCj4+Pj4g S2F0aGxlZW4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiBGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21pbGUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEMuDQo+Pj4+IEhlbnJ5DQo+Pj4gQWRhbXMgJiBCSUUgW2NoYXRsZ2EyMDAw QHlhaG9vLmNvbV0NCj4+Pj4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMjYsIDIwMTMgMzowNSBB TQ0KPj4+PiBUbzogbWlsZUBpZXRmLm9yZw0KPj4+PiBDYzogQy4gSGVucnkgQWRhbXMNCj4+Pj4g U3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQo+Pj4+DQo+Pj4+IEdyZWV0aW5ncyBFdmVyeW9uZSwN Cj4+Pj4NCj4+Pj4gVGFrZSBtZW50aW9uZWQgdHdvIHR5cGVzIG9mIGluZGljYXRvcnMgYmFzZWQg b24gdGhlIDoNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IC0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4gMSkgSWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGluZyBs aWtlIGFuIFhNTC1iYXNlZCBhbGVydC93YXJuaW5nIG9mDQo+Pj4+IGluZm9ybWF0aW9uIGxlYWth Z2UsIGl0IGNvdWxkIGJlIGFuIGV2ZW50IHRoYXQgYXJlIGNvbnZleWVkIGluIHRoZQ0KPj4+PiBT Q0kncyBFdmVudFJlcG9ydCBjbGFzcywgSU1ITy4NCj4+Pj4NCj4+Pj4gMikgSWYgdGhlIGluZGlj YXRvcnMgYXJlIHNvbWV0aGluZyBsaWtlIGFuIG5vbi1YTUwgb25lcywgSSBndWVzcyBpdA0KPj4+ PiBjb3VsZA0KPj4+IGJlDQo+Pj4+IGNvbnZleWVkIHdpdGhvdXQgdXNpbmcgU0NJIGRyYWZ0Lg0K Pj4+PiBGb3IgaW5zdGFuY2UsIHdlIGNvdWxkIHVzZSBJbXBhY3QgY2xhc3Mgb2YgdGhlIGJhc2Ug SU9ERUYgdG8gY29udmV5DQo+Pj4+IHRoZSBpbmRpY2F0b3JzLg0KPj4+PiBXZSBjb3VsZCBmb3Ig aW5zdGFuY2UgZXh0ZW5kIHRoZSBsaXN0IG9mIGluZGljYXRvcnMgb2YgdGhlIEltcGFjdA0KPj4+ PiBjbGFzcywNCj4+PiBpZg0KPj4+PiBuZWVkZWQuDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLS0t LS0tLQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+DQo+Pj4+IEluIGRvaW5n IHNvIGhlIHBvaW50ZWQgb3V0IHRoZSAiSW1wYWN0IENsYXNzIg0KPj4+Pg0KPj4+PiBXaGVyZWFz LCBLYXRobGVlbiBzdGF0ZWQsDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLS0tLS0tLQ0KPj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gRm9yIHRoZSBkaXNjdXNzaW9uIGJlbG93LCBJ IHdhcyB0aGlua2luZyBtb3JlIG9mIGNvbWJpbmVkIHNldCB3aXRoDQo+Pj4gcmVsYXRpb25zaGlw cyB0aGF0IG1heSBiZSBpbmNsdWRlZCBpbiBhIHNpbmdsZSBleHRlbnNpb24gcG9pbnQsIHNvIHRo YXQncw0KPj4+IHdoeSBJIHdhcyB0aGlua2luZyBhYm91dCB0aGUgRXZlbnREYXRhIGNsYXNzLCBi dXQgdGhlcmUgbWF5IGJlIGJldHRlcg0KPj4+IGxvY2F0aW9ucyBvciBhIHNwZWNpZmljIGFyZWEg d2l0aGluIHRoZSBFdmVudERhdGEuDQo+Pj4+DQo+Pj4+IFBhdWwgU3RvZWNrZXIgaGFkIHN1Z2dl c3RlZCBhICJEZXRlY3Rpb24iIGNsYXNzIGFzIGEgY29uc2lkZXJhdGlvbi4NCj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4+IC0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+DQo+ Pj4+IEthdGhsZWVuIHRob3VnaHRzIHJlbGF0ZWQgeWV0IHN0aWxsIHdpdGggb3RoZXIgaW5kaWNh dG9ycyBhbmQgdGhlDQo+Pj4gRXZlbnREYXRhIENsYXNzLg0KPj4+Pg0KPj4+PiBJcyB0aGVyZSBh IHBvc3NpYmxlIHdheSB0byBjcmVhdGUgYSBuZXcgWE1MIGNsYXNzIHdoaWNoIGVuY29tcGFzcw0K Pj4+IGNvbWJpbmluZyB0aGUgRXZlbnREYXRhLCBEZXRlY3Rpb24gYW5kIGJhc2UgSU9ERUYgY2xh c3NlcyB0byBzaW1wbGlmeQ0KPj4+IHRoaXMNCj4+PiBpc3N1ZT8NCj4+Pj4NCj4+Pj4NCj4+Pj4g Qy4gSGVucnkgQWRhbXMNCj4+Pj4gY2hhdGxnYTIwMDBAeWFob28uY29tIChEaXJlY3QgRW1haWwp DQo+Pj4+IGNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tDQo+Pj4+DQo+Pj4+DQo+Pj4+IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUNCj4+Pj4gb3JpZ2luYWwNCj4+PiByZWNpcGllbnQuIFRoaXMgaW5mb3JtYXRpb24gaXMg Z3JhbnRlZCBmb3IgbGltaXRlZCBkaXN0cmlidXRpb24gd2l0aGluDQo+Pj4gdGhlDQo+Pj4gcmVj aXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1cnBvc2VzIG9ubHkuIEZ1 cnRoZXINCj4+PiBkaXNzZW1pbmF0aW9uLCB3aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHBy b2hpYml0ZWQuDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+IG1pbGUgbWFpbGluZyBsaXN0DQo+Pj4+IG1pbGVAaWV0Zi5vcmcNCj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1pbGUgbWFpbGlu ZyBsaXN0DQo+PiBtaWxlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21pbGUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbWlsZSBtYWlsaW5nIGxpc3QNCj4gbWlsZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCj4NCg== From trammell@tik.ee.ethz.ch Wed Feb 13 05:14:02 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2E521F87F6 for ; Wed, 13 Feb 2013 05:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[AWL=-1.613, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CREkE+VXTBzT for ; Wed, 13 Feb 2013 05:14:00 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5187721F8835 for ; Wed, 13 Feb 2013 05:13:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7F2CDD930C; Wed, 13 Feb 2013 14:13:58 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nHxzf7Wp-9Xg; Wed, 13 Feb 2013 14:13:58 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9F8ACD9308; Wed, 13 Feb 2013 14:13:57 +0100 (MET) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Wed, 13 Feb 2013 14:13:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09F05794-81FD-4C0F-B064-201029BF68D1@tik.ee.ethz.ch> References: To: "Stoecker, Paul" X-Mailer: Apple Mail (2.1499) Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:14:02 -0000 Hi, Paul, I agree with this point; the main reason to support numeric confidence = values in 5070bis is that 5070 already does. Best regards, Brian On Feb 13, 2013, at 2:04 PM, "Stoecker, Paul" = wrote: > I may have been too succinct in my response ;-) >=20 > Confidence is a subjective thing, so I think we should use subjective > terms: Low, Medium, High. Having a numeric scale with a map that > essentially would say something like: >=20 > 1-33 =3D Low > 34-67=3D Medium > 68-100=3DHigh >=20 > Is just a more complicated way of saying that something is Low, = Medium, > High...do we really thing that how High something is makes that much = of a > difference? >=20 > This is like when you get your Performance review where it is Does Not > Meet, Meets and Exceeds...your boss tells you that you are a High = Meets...your > bonus tells you that you got the same bonus that all the other Meets = got > ;-) >=20 > Anyway, I digress but trying to prove a point that I would argue that > confidence in this case is going to be basically a gut feeling, so why = use > numeric values when Low, Medium, High would do just fine. >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 >=20 >=20 >=20 >=20 >=20 > On 2/13/13 7:48 AM, "Moriarty, Kathleen" = wrote: >=20 >> Hello, >>=20 >> Both approaches will validate in the current schema. The = representation >> looks a little different for each, here is an example: >>=20 >> >>=20 >> Vs: >>=20 >> 85 >>=20 >> Searching capability is a great point, agreed. I'd like to hear from >> more people to make sure we don't lose a capability that others find >> extremely useful (need to gauge that). Other options is that the >> guidance can also discourage the use of the numeric in addition to >> specifying how to select ranges. >>=20 >> Any other opinions? >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: Stoecker, Paul >> Sent: Wednesday, February 13, 2013 7:14 AM >> To: Brian Trammell >> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >> Subject: Re: [mile] IOCs >>=20 >> Cant we make Confidence a List that has only 3 values: High, Medium, = and >> Low? Any other value means that the Document will mot validate = against >> the schema. >>=20 >> Sent from my iPhone >>=20 >> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" = >> wrote: >>=20 >>> Hi, Kathleen, all, >>>=20 >>> I think 3.10.4 in 5070 takes the right approach here: trying to = build >>> interoperable numeric scales for assessment is a very hard problem. >>> (Were I charged with defining such a scale, the value "70" would = mean >>> "we compared this incident report to N past similar incident reports >>> according to similarity algorithm S, and 70% of the past reports had >>> assessed impacts within E% of the actual, measured final impact -- I >>> think for most applications this is vastly more difficult and = rigorous >>> than it needs to be.) >>>=20 >>> Unless a numeric Confidence value is based on some actual, = repeatably >>> measurable aspect of the Assessment report -- which I suspect in >>> many/most/all cases it's not -- then it just represents a guess, = however >>> educated. Each team will probably naturally tune its own scales = such >>> that each value generally means the same thing in each report. = Across >>> teams, I don't know. >>>=20 >>> On the other hand, Assessments are by their very nature educated >>> guesses, anyway, so I don't know that I'd find much use in = automating a >>> response based on the assessment confidence. Chris has a good point, >>> though -- it makes searching difficult and sorting kind of = pointless. >>>=20 >>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then = I >>> agree, we should put that in the guidance document (along with a = note >>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to = high, >>> unless we want to do it non-linearly). If the _vast_majority_ of the >>> users of this field use a 100-point scale with 100 meaning "yes" and = 0 >>> meaning "any resemblance these values may have to actual fact is = purely >>> coincidental", then let's consider renaming it "percent" in = 5070-bis. >>>=20 >>> Best regards, >>>=20 >>> Brian (as contributor) >>>=20 >>>=20 >>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>> wrote: >>>=20 >>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>> change it if it needs to be changed. The value is for a confidence >>>> rating on the indicators shared. The definitions may be helpful = for >>>> anyone who wants to work on this discussion. IODEF has various = markers >>>> that can be used in a complimentary way without conflating the = markers >>>> meaning. >>>>=20 >>>> I think some people using IODEF find the numerical values more >>>> helpful, and it would be good to understand what people have = learned >>>> from using the current structure (what works/does not work). The >>>> scales I have seen are 0-100. There is of course a subjective = element >>>> to assigning a numerical value to the confidence and it may vary = from >>>> entity to entity. With this type of rating you may need to = consider >>>> who it came from and how they scored the confidence rating to map = to >>>> your own rating. It would be good to hear more thoughts on this. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>> To: MILE IETF >>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>> Subject: Re: [mile] IOCs >>>>=20 >>>>=20 >>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>> point. Different Confidence levels will cause confusion. It = appears >>>> that there maybe a need for some type of simplified standardization = to >>>> be established between all Sharing Groups in this regard. >>>>=20 >>>> Perhaps numerical scoring set at lower values should express levels = of >>>> urgency. >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D= Urgent, >>>> 5 =3D Imminent ) >>>>=20 >>>> Thanks, >>>> C. Henry Adams >>>>=20 >>>>=20 >>>>=20 >>>> I see some confusion coming down the pike if we start using = Confidence >>>> the >>>> way it is supported. If I am using low/med/high and someone sends = me >>>> an IoC >>>> with a score of 70, what does that mean to me? What if I am using a >>>> scale of >>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the = ability to >>>> describe something with a consistent language. It really gets ugly >>>> when we >>>> store IoC from multiple sources. I have confidence values that are >>>> numeric >>>> as well as text. Makes searching / sorting very problematic. >>>>=20 >>>> At this point we have to roll with what we have. I would strongly >>>> recommend >>>> that we revisit this at some point. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; = 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Hi Chris & Take, >>>>=20 >>>> I'll just focus on the confidence scoring. Right now, the schema >>>> allows for >>>> you to either use a numerical score OR the ratings of low, medium, = and >>>> high. >>>> Different sharing groups can decide how they want to share the = data. >>>> If >>>> people were to use the numerical values, I agree it would be = helpful >>>> to have >>>> guidance. This could go in the IODE guidance document. >>>>=20 >>>> I have seen examples of current users that use each of the = approaches, >>>> so >>>> we'll need to keep the option for backwards compatibility and it is >>>> nice to >>>> keep in flexible options where we can. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: Harrington, Christopher >>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> The number of indicators wouldn't necessarily drive the use of >>>> indicator_set_id. The purpose is to show relationship. If I sent 3 = IP >>>> addresses that were used as C2 for 3 different campaigns I would = have >>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>=20 >>>> My suggestion would be a simple low, medium, high. I think if we = break >>>> it >>>> down to more levels than that we would need to provide guidance on >>>> scoring, >>>> rating, etc. I think most people should be able to understand >>>> low/med/high >>>> without having to have a mathematical method for arriving at the = level. >>>>=20 >>>> Low - I am not sure >>>> Medium - I am reasonably sure >>>> High - I am very sure >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; = 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Regarding the indicator_set_id, I agree, it is useful when we need = to >>>> deal >>>> with large sets of indicators. >>>> Since indicator_set_id attribute is optional (right?), it could be >>>> omitted >>>> if we need to deal with only small number of indicators. >>>>=20 >>>> Regarding the use case, I like the idea of using the confidence >>>> attribute >>>> for the reason Chris kindly described. >>>> I would like to hear a bit more on this: is it going to be = numerical? >>>> For >>>> instance, 1 means "no confidence" while 5 means "strong = confidence", >>>> etc? >>>>=20 >>>> Thank you. >>>> Take >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE = IETF' >>>>> Subject: RE: [mile] IOCs >>>>>=20 >>>>> With respect to tying things back to threat actors, from what I = have >>>>> seen and use this is a generally accepted grouping: >>>>>=20 >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>>=20 >>>>> Campaign and Threat Actor are where having a "Confidence" = attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> --Chris >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; = 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>>=20 >>>>> Hi Take & others, >>>>>=20 >>>>> Thanks for chiming in, I've been talking about this with Chris and = a >>>>> few others on their use cases and would like more opinions. I'll >>>>> provide an option below from what we have discussed from a CIRC = view >>>>> point. We are also wondering how to also provide logic in IODEF = that >>>>> could cross over into SCI attached schemas or IODEF extensions = (the >>>>> solutions may all tie together with this discussion - or there may = be >>>>> better/more elegant solutions others would like to propose). >>>>>=20 >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; = 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>>=20 >>>>>> I like this discussion. >>>>>> I agree, it would be good idea to have indicator identifiers = inside >>>>>> the IOC-related classes. >>>>>=20 >>>>> KMM: At the class level, we may have several indicators listed = that >>>>> should be viewed as a set and may have another instance of that = same >>>>> class that is a related issue, but a separate set. We could as = you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we = get >>>>> into logic and relationships between sets or indicators. This = could >>>>> also be a way to connect indicators or sets across XML documents = that >>>>> could have been shared previously. If there are a large number of >>>>> indicators in the set, then this becomes useful, for smaller sets, = I >>>>> agree it doesn't make as much sense. >>>>>=20 >>>>> What do others think? >>>>>=20 >>>>>>> Then for indicators not included in the base schema that may not >>>>>>> fit into a category in the SCI draft, do we create a place for >>>>>>> these off of SCI or right off of the IODE schema in EventData? >>>>>>> (more details >>>>> on >>>>>>> this in my first message). >>>>>>=20 >>>>>> If we could see any indicator of compromise as computer event >>>>>> record, we could use SCI:EventReport class as the place for the >>>>>> XML-based IOCs that couldn't fit anywhere else. >>>>>=20 >>>>> KMM: That sounds like a good idea to me. This should go into = guidance >>>>> in the SCI draft. Does anyone else want to weigh in? >>>>>=20 >>>>>>=20 >>>>>> For the non-XML IOCs, we could use RecordData class, as = suggested. >>>>> KMM: Sounds good, thanks! >>>>>=20 >>>>>> I agree to have indicator_uid, but I am not sure about the needs = of >>>>>> the indicator_set_id. >>>>>> I understand we could do some grouping of individual = indicator_uids >>>>>> and its usability, but I am not sure whether we do not have any >>>>>> other way to express these groupings. >>>>>> For instance, a Reference class refers to several = indicadtor_uids. >>>>> In >>>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>>=20 >>>>> KMM: It may be, what do you think about large sets of indicators = or >>>>> subsequent messages that add indicators to existing sets? Would = this >>>>> happen? Would it be easier to express relationships with sets of >>>>> indicators in addition to individual indicators? By using this, = it >>>>> could give us a unique way to also provide the logic and = relationships >>>>> in a new class of IODEF so we don't have to worry about adding it = into >>>>> the current >>>> structure. >>>>> If there are better ways to handle that, and others can provide = some >>>>> options, that would be appreciated! >>>>>=20 >>>>> Thank you, >>>>> Kathleen >>>>>=20 >>>>>> I would appreciate if anybody could share expertise on this. = Though >>>>> I >>>>>> think I have read all the emails in the list, I might have >>>>>> mis-understood some points. >>>>>>=20 >>>>>> By the way, I think the indicator_uids should be added to the SCI >>>> classes' >>>>>> attributes so that they can be correlated with another = information >>>>>> as >>>>> well. >>>>>>=20 >>>>>> Thanks >>>>>> Take >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>>=20 >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between = indicators. If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication = of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>>=20 >>>>> Thanks, >>>>> --Chris >>>>>=20 >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>>=20 >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>>=20 >>>>> It is either that or going back to adding a Detection (or = Indicators) >>>>> class that will should be used to take all of the indicators put = them >>>>> into one place and have the ability to group the ones that go >>>>> together. I don't mean a place to put indicators that are missing >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the = shared >>>>> Incident. I don't know the answer here, but there has got to be a >>>>> good way for indicators to be identified and being able to group = them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>>=20 >>>>>=20 >>>>> From: , Kathleen >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" , = MILE >>>>> IETF >>>>> Subject: Re: [mile] IOCs >>>>>=20 >>>>> Hi Chris, >>>>>=20 >>>>> I agree, we have some work to do in the updated IODEF, = RFC5070-bis. >>>>>=20 >>>>> The list has already said they would like to see indicators added = to >>>>> the definitions in RFC5070-bis, to be more explicit about = including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes. It was written before we used terms like >>>>> indicators. With that in mind, Rosella proposed a number of = changes >>>>> back in July, both for guidance and for >>>> format >>>>> updates. It may help to have the first draft try to address at = least >>>>> some of these issues so people can understand the problems and at >>>>> least a proposed solution. >>>>>=20 >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators = that >>>>> could have a relationship to each other within a document. In the >>>>> July presentation, one of the questions was to see if we should = add >>>>> new category attribute values for the System class that would = connect >>>>> the list of included indicators. I think we should still keep the >>>>> concept of a Node to a single node, but perhaps within System, = list >>>>> multiple sets of Nodes that may be one type of attack. Rosella = had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an = AttackType >>>>> (FraudType values could be included in AttackType or some broader >>>>> term). It may be better to have the FraudTypes, plus attribute = values >>>>> like "C2-server", "sinkhole", "MalwareDistribution" for added = context >>>>> so you know what to do with the received set of indicators. >>>>>=20 >>>>> I am proposing that we change IODEF to include multiple sets of >>>> indicators, >>>>> add an AttackType attribute (or some other name), a method to = connect >>>>> indicators and indicator sets within an IODEF using an attribute = of >>>>> indicator_uid (or some other name) with a string value to make the >>>>> connection points, and add a few indicators that are commonly = shared >>>>> into the base IODEF. >>>>>=20 >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below). What if we added the Registry Key/Value pairs as a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in = RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, = we >>>>> could connect a set within that structure and repeat the structure = for >>>>> other sets in the same way we would do with Node inside of the = System >>>>> class, using the indicator_uid to tie the set together. Then at = the >>>>> more specific level for the hash, registry Key/value, IP, etc. use = an >>>>> indicator_uid if we needed them marked at this level as well? = Maybe >>>>> we want indicator_set at the higher level? I'd like some opinions = on >>>>> this approach. +1 if you agree, suggestions if you have other = ideas >>>>> that may work better. >>>>>=20 >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted. We may want to use these = values >>>>> or something else. >>>>>=20 >>>>> Thank you! >>>>> Kathleen >>>>>=20 >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>>=20 >>>>> I think we have a bigger relationship issue to address. Let use = the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. = In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>>=20 >>>>> Two or more indicators of different type that relate to the same >>>>> threat: >>>>> The file hash of a malicious file and the URL of the C2 that >>>>> the file uses. Either or both may be present to indicate a = compromise. >>>>>=20 >>>>> Two or more indicators of the same type that relate to the same >>>>> threat: >>>>> 2 different registry values for the same registry key. If >>>>> either value is present it is a compromise indicator but both will = not >>>>> be >>>> present. >>>>>=20 >>>>> The problem compounds itself very quickly. Consider the scenario = where >>>>> both groupings above are part of the same threat. I need to show = that >>>>> logical groupings of Indicators are related as well. We can't send >>>>> multiple IODEF messages for this from what I remember reading. >>>>>=20 >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but = the >>>>> IOCs are the 2 hash values. How do we show they are related? If we = use >>>>> a unique Inidcator ID for each hash value there needs to be a = higher >>>>> level >>>> grouping. >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> --Chris >>>>>=20 >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information = Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>>=20 >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>>=20 >>>>> All - >>>>>=20 >>>>> I'd like your input and will refocus the thread to get opinions = from >>>>> the list on options to help solve the problems raised in my = message >>>>> and additionally in Paul's message. >>>>>=20 >>>>> Interesting point, C. Henry. Our objective here is to have = machine >>>>> automated exchanges, so we rely on encryption rather than = obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>>=20 >>>>> Paul mentioned the need to distinguish indicators of compromise = from >>>>> context information that may also include IP address or other data >>>>> that could be indicators. The question I raised was on how to = connect >>>>> sets of indicators in the same IODEF document, assuming the = ability to >>>>> have watchlists that could have several sets of indicators = included, >>>>> as well as to connect indicators that may be included in embedded >>>>> schemas. >>>>>=20 >>>>> If we add an attribute on all of the relevant indicators, let's = say >>>>> 'indicator-uid' how do we mark the indicators? Do we use this to = mark >>>>> who sent the indicator as well so that we can prevent forward = sharing >>>>> when it is not permitted or handle that separately? >>>>>=20 >>>>> Then for indicators not included in the base schema that may not = fit >>>>> into a category in the SCI draft, do we create a place for these = off >>>>> of SCI or right off of the IODE schema in EventData? (more details = on >>>>> this in my first message). >>>>>=20 >>>>> Comments and questions encouraged to figure out the right = technical >>>>> solution to have this machine automatable. >>>>>=20 >>>>> Thank you, >>>>> Kathleen >>>>>=20 >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>>=20 >>>>> Temporal Dependency sounds interesting. I remember when I first = ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question. He said, " How do you stop someone from = tracking >>>>> the IP Address to your computer?" >>>>>=20 >>>>> I replied, "I don't know, how?" >>>>>=20 >>>>> Then he said, "Cut the dog-gone thing off and the modem that it = is >>>>> connected- which is constantly on!" LOL >>>>>=20 >>>>> Here's my point (Hypothetical Situation) : There is a 1st = Responder >>>>> searching a Neighborhood for Survivors which were hit by a = Disaster or >>>>> let's just say "Live" Terrorist Situation. He /or She needs to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger. The device used to communicate has been captured by the = great >>>>> minds of the enemy. It's only a matter of time before they = utilize >>>>> reverse engineering to figure out how it functions. However, = their >>>>> pride comes before a fall when seeking the location of other = similar >>>>> devices to attack. Why? Perhaps the less thought of concepts that >>>>> makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>>=20 >>>>> Just a visionary thought. >>>>>=20 >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>>=20 >>>>>=20 >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>>=20 >>>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>>=20 >>>>> From: Dave Misell >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with = DNS >>>>> SEC a pemanent and temporal key, with a temporal Id? >>>>>=20 >>>>> Yours Faithfully, >>>>>=20 >>>>> Dave Misell MSc CISSP >>>>> SilentCircle dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>>=20 >>>>>=20 >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE = >>>>> wrote: >>>>>=20 >>>>>> Serialization of a particular Lists of XML Classes in a unique = way >>>>>> was >>>>> closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant = minds >>>>> in some instances." >>>>>>=20 >>>>>> However, I see Dr. Stoecker's point a little clearer. However, = it >>>>>> would >>>>> be nice if the UID was in some way disguised from those who study = this >>>>> Security Art Form in a negative way. >>>>>>=20 >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) = chenryadams@biemediagroup.com >>>>>>=20 >>>>>>=20 >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution = within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>>=20 >>>>>> Re: [mile] IOCs >>>>>>=20 >>>>>> Sunday, January 27, 2013 8:52 PM >>>>>> From: >>>>>> "Stoecker, Paul" >>>>>> To: >>>>>> "mile@ietf.org" >>>>>> I would like to look at this from a slightly different >>>>>> perspective=A9let's say I get an XML document that tells me about = an >>>>>> incident. This document has source IP and destination IP that is >>>>>> being shared. However, what I don't know is which IP address is = my >>>>>> indicator and which is just a contextual piece of information. = This >>>>>> means that my detection product isn't going to know which one to = use >>>>>> either, because there is nothing to tell me which IP is the one, = even >>>>>> if the roles are set it still might not be enough to tell my = system >>>>> which >>>>> one I should use as the indicator. >>>>>>=20 >>>>>> If we had something like indicator_id as an attribute, it would = allow >>>>>> us to easily identify indicators from contextual data. I do = admit to >>>>>> being biased as I have spent much of my career working on the >>>>>> monitoring and detection side of these things, so I am just = thinking >>>>>> of ways to make it very clear what the indicators are in the XML >>>>>> document and the other data that may be important as I = investigate >>>>>> activity that I have detected off of those indicators. >>>>>>=20 >>>>>>=20 >>>>>> I did suggest the detection class, but I think we may get more >>>>>> flexibility with the indicator_uid. One thing that I haven't >>>>>> considered is the UID portion of this=A9how do we use that UID? = How is >>>>>> the UID created? Are there standards for UIDs? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Paul W. Stoecker, Ph.D. >>>>>> SMC Lead Content Architect >>>>>> RSA, The Security Division of EMC >>>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>>>=20 >>>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>>> wrote: >>>>>>=20 >>>>>> From: C. Henry Adams & BIE >>>>>> Subject: RE: [mile] IOCs >>>>>> To: "KathleenMoriarty" >>>>>> Cc: mile@ietf.org >>>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>>>=20 >>>>>> Greetings Kathleen, >>>>>>=20 >>>>>> Your logic stimulates my visionary brain because I'm amazed at = the >>>>>> many >>>>> avenues you review with this approach at once. However, could = you >>>>> share >>>>> a >>>>> few advantages and disadvantages to the latter? >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>>> "we could continue to group items in logical places as is done = now in >>>>> IODEF and then have the extension point for combined indicators = via >>>>> SCI." >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>>>=20 >>>>>> You pointed out what you consider to be logical places, but if I >>>>>> wanted to >>>>> protect information from parties capable of ascertaining it from = your >>>>> logical places, perhaps we should also consider to a degree what >>>>> appears >>>>> to >>>>> be illogical in brilliant minds in some instances. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) >>>>>> chenryadams@biemediagroup.com >>>>>>=20 >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution = within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>>=20 >>>>>> --- On Sat, 1/26/13, Moriarty, Kathleen = >>>>> wrote: >>>>>>=20 >>>>>> From: Moriarty, Kathleen >>>>>> Subject: RE: [mile] IOCs >>>>>> To: "C. Henry Adams & BIE" , = "mile@ietf.org" >>>>> >>>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>>>=20 >>>>>> Hello C. Henry & others, >>>>>>=20 >>>>>> Thanks for taking a look at this. We have a few considerations = in >>>>>> this >>>>> email thread I would like to hear thoughts on (and there may be = more >>>>> once >>>>> RFC5070-bis is actively edited). >>>>>>=20 >>>>>> The AdditionalData class and the RecordItem class both allow for >>>>>> non-XML >>>>> extensions. Where you place the extensions should be specific to = the >>>>> logical grouping of the parent elements so you can understand more >>>>> about >>>>> the >>>>> included data in most cases. >>>>>>=20 >>>>>> The Impact class can be used to provide context information on = the >>>>> included data of the report and also can include a confidence = rating >>>>> on >>>>> the >>>>> report as a whole. Extensions related to impact would be one = level >>>>> higher >>>>> (at the moment) in the Assessment class using the AdditionalData >>>>> extension >>>>> point. >>>>>>=20 >>>>>> Take asked about including vulnerability information, I would = think >>>>>> that >>>>> would fit under the Vulnerability extension point of the SCI draft = in >>>>> the >>>>> Method class. He did ask about non-XML. RecordItem or = AdditionalData >>>>> do >>>>> allow for non-XML extension points, we could either have the SCI = draft >>>>> handle these as well or have the extensions that are non-XML come >>>>> directly >>>>> off the AdditionalData or RecordItem classes according to what = makes >>>>> sense >>>>> from a logical standpoint. >>>>>>=20 >>>>>> As for my question, it was two-fold. >>>>>>=20 >>>>>> Indicator based schemas have a reference number or a GUID for the >>>>>> various >>>>> indicators they share. If we are extending to embed other schemas >>>>> that >>>>> include such reference or GUID identifiers, do we want to add an >>>>> attribute >>>>> to the various elements in IODEF that could be indicators? Is = this >>>>> enough >>>>> to make the connections or is something else else needed? We = could >>>>> add >>>>> something like an Indicator_ID in RFC5070-bis which would then >>>>> correlate >>>>> to >>>>> the reference or GUID identifiers. >>>>>>=20 >>>>>> Then the other question was on how to include indicators that are = not >>>>>> in >>>>> the base schema that may be related or have language with "and" = "or" >>>>> to >>>>> specify the relationships. In some cases, you will want to group >>>>> these >>>>> indictors in one extension point, where they may fit logically in >>>>> multiple >>>>> places if the relationships did not need to be shown in the data >>>>> format. If >>>>> we have cases like this where you need more complex = representations, >>>>> should >>>>> we use one extension point via the SCI draft off of the EventData >>>>> class >>>>> AdditionalData extension point? Opinions are needed here.... >>>>>>=20 >>>>>> A few people have mentioned wanting to include some commonly = shared >>>>> indictors into the base IODEF document. We could have a catch-all >>>>> class >>>>> that does this and has an extension point off of it in EventData = or we >>>>> could >>>>> continue to group items in logical places as is done now in IODEF = and >>>>> then >>>>> have the extension point for combined indicators via SCI. I think = I >>>>> like >>>>> the latter approach. >>>>>>=20 >>>>>> Thank you, >>>>>> Kathleen >>>>>> ________________________________________ >>>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = C. >>>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>>> To: mile@ietf.org >>>>>> Cc: C. Henry Adams >>>>>> Subject: Re: [mile] IOCs >>>>>>=20 >>>>>> Greetings Everyone, >>>>>>=20 >>>>>> Take mentioned two types of indicators based on the : >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>>> 1) If the indicators are something like an XML-based = alert/warning of >>>>>> information leakage, it could be an event that are conveyed in = the >>>>>> SCI's EventReport class, IMHO. >>>>>>=20 >>>>>> 2) If the indicators are something like an non-XML ones, I guess = it >>>>>> could >>>>> be >>>>>> conveyed without using SCI draft. >>>>>> For instance, we could use Impact class of the base IODEF to = convey >>>>>> the indicators. >>>>>> We could for instance extend the list of indicators of the Impact >>>>>> class, >>>>> if >>>>>> needed. >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>>>=20 >>>>>> In doing so he pointed out the "Impact Class" >>>>>>=20 >>>>>> Whereas, Kathleen stated, >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>>> For the discussion below, I was thinking more of combined set = with >>>>> relationships that may be included in a single extension point, so >>>>> that's >>>>> why I was thinking about the EventData class, but there may be = better >>>>> locations or a specific area within the EventData. >>>>>>=20 >>>>>> Paul Stoecker had suggested a "Detection" class as a = consideration. >>>>> = -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>>>=20 >>>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>>>=20 >>>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to = simplify >>>>> this >>>>> issue? >>>>>>=20 >>>>>>=20 >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) >>>>>> chenryadams@biemediagroup.com >>>>>>=20 >>>>>>=20 >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution = within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 From john.banghart@nist.gov Wed Feb 13 05:16:18 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264E521F862E for ; Wed, 13 Feb 2013 05:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPo+803vHkdp for ; Wed, 13 Feb 2013 05:16:15 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5B81C21F8628 for ; Wed, 13 Feb 2013 05:16:13 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Feb 2013 08:16:07 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 13 Feb 2013 08:16:12 -0500 From: "Banghart, John" To: "Stoecker, Paul" , "Moriarty, Kathleen" , Brian Trammell Date: Wed, 13 Feb 2013 08:16:08 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J7EtYUFgHtl0SQkO/e+m2gB0CbQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "C. Henry Adams & BIE" , MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:16:18 -0000 Paul, I agree that confidence is subjective, but subjectivity can be reduced within communities that interact frequently. Prioritization of indicators and response between tightly connected sharing partners might require a more specific level of detail, particularly during a crisis situation. >From that perspective, I think the guidance should allow for additional granularity, while stressing the "high, medium, low" as preferred for broad interoperability. -John On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >I may have been too succinct in my response ;-) > >Confidence is a subjective thing, so I think we should use subjective >terms: Low, Medium, High. Having a numeric scale with a map that >essentially would say something like: > >1-33 =3D Low >34-67=3D Medium >68-100=3DHigh > >Is just a more complicated way of saying that something is Low, Medium, >High...do we really thing that how High something is makes that much of a >difference? > >This is like when you get your Performance review where it is Does Not >Meet, Meets and Exceeds...your boss tells you that you are a High >Meets...your >bonus tells you that you got the same bonus that all the other Meets got >;-) > >Anyway, I digress but trying to prove a point that I would argue that >confidence in this case is going to be basically a gut feeling, so why use >numeric values when Low, Medium, High would do just fine. > > >Paul W. Stoecker, Ph.D. >SMC Lead Content Architect >RSA, The Security Division of EMC >cell: 302.379.3375 | e: paul.stoecker@rsa.com > > > > > > >On 2/13/13 7:48 AM, "Moriarty, Kathleen" >wrote: > >>Hello, >> >>Both approaches will validate in the current schema. The representation >>looks a little different for each, here is an example: >> >> >> >>Vs: >> >>85 >> >>Searching capability is a great point, agreed. I'd like to hear from >>more people to make sure we don't lose a capability that others find >>extremely useful (need to gauge that). Other options is that the >>guidance can also discourage the use of the numeric in addition to >>specifying how to select ranges. >> >>Any other opinions? >> >>Thanks, >>Kathleen >> >>-----Original Message----- >>From: Stoecker, Paul >>Sent: Wednesday, February 13, 2013 7:14 AM >>To: Brian Trammell >>Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>Subject: Re: [mile] IOCs >> >>Cant we make Confidence a List that has only 3 values: High, Medium, and >>Low? Any other value means that the Document will mot validate against >>the schema. >> >>Sent from my iPhone >> >>On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>wrote: >> >>> Hi, Kathleen, all, >>> >>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>>interoperable numeric scales for assessment is a very hard problem. >>>(Were I charged with defining such a scale, the value "70" would mean >>>"we compared this incident report to N past similar incident reports >>>according to similarity algorithm S, and 70% of the past reports had >>>assessed impacts within E% of the actual, measured final impact -- I >>>think for most applications this is vastly more difficult and rigorous >>>than it needs to be.) >>> >>> Unless a numeric Confidence value is based on some actual, repeatably >>>measurable aspect of the Assessment report -- which I suspect in >>>many/most/all cases it's not -- then it just represents a guess, however >>>educated. Each team will probably naturally tune its own scales such >>>that each value generally means the same thing in each report. Across >>>teams, I don't know. >>> >>> On the other hand, Assessments are by their very nature educated >>>guesses, anyway, so I don't know that I'd find much use in automating a >>>response based on the assessment confidence. Chris has a good point, >>>though -- it makes searching difficult and sorting kind of pointless. >>> >>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>>agree, we should put that in the guidance document (along with a note >>>that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, >>>unless we want to do it non-linearly). If the _vast_majority_ of the >>>users of this field use a 100-point scale with 100 meaning "yes" and 0 >>>meaning "any resemblance these values may have to actual fact is purely >>>coincidental", then let's consider renaming it "percent" in 5070-bis. >>> >>> Best regards, >>> >>> Brian (as contributor) >>> >>> >>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>> wrote: >>> >>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>>change it if it needs to be changed. The value is for a confidence >>>>rating on the indicators shared. The definitions may be helpful for >>>>anyone who wants to work on this discussion. IODEF has various markers >>>>that can be used in a complimentary way without conflating the markers >>>>meaning. >>>> >>>> I think some people using IODEF find the numerical values more >>>>helpful, and it would be good to understand what people have learned >>>>from using the current structure (what works/does not work). The >>>>scales I have seen are 0-100. There is of course a subjective element >>>>to assigning a numerical value to the confidence and it may vary from >>>>entity to entity. With this type of rating you may need to consider >>>>who it came from and how they scored the confidence rating to map to >>>>your own rating. It would be good to hear more thoughts on this. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>> To: MILE IETF >>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>> Subject: Re: [mile] IOCs >>>> >>>> >>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>>point. Different Confidence levels will cause confusion. It appears >>>>that there maybe a need for some type of simplified standardization to >>>>be established between all Sharing Groups in this regard. >>>> >>>> Perhaps numerical scoring set at lower values should express levels of >>>>urgency. >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>>> 5 =3D Imminent ) >>>> >>>> Thanks, >>>> C. Henry Adams >>>> >>>> >>>> >>>> I see some confusion coming down the pike if we start using Confidence >>>>the >>>> way it is supported. If I am using low/med/high and someone sends me >>>>an IoC >>>> with a score of 70, what does that mean to me? What if I am using a >>>>scale of >>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>>>to >>>> describe something with a consistent language. It really gets ugly >>>>when we >>>> store IoC from multiple sources. I have confidence values that are >>>>numeric >>>> as well as text. Makes searching / sorting very problematic. >>>> >>>> At this point we have to roll with what we have. I would strongly >>>>recommend >>>> that we revisit this at some point. >>>> >>>> Thanks, >>>> >>>> --Chris >>>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>>'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>> Hi Chris & Take, >>>> >>>> I'll just focus on the confidence scoring. Right now, the schema >>>>allows for >>>> you to either use a numerical score OR the ratings of low, medium, and >>>>high. >>>> Different sharing groups can decide how they want to share the data. >>>>If >>>> people were to use the numerical values, I agree it would be helpful >>>>to have >>>> guidance. This could go in the IODE guidance document. >>>> >>>> I have seen examples of current users that use each of the approaches, >>>>so >>>> we'll need to keep the option for backwards compatibility and it is >>>>nice to >>>> keep in flexible options where we can. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: Harrington, Christopher >>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>> The number of indicators wouldn't necessarily drive the use of >>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>>> addresses that were used as C2 for 3 different campaigns I would have >>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>> >>>> My suggestion would be a simple low, medium, high. I think if we break >>>>it >>>> down to more levels than that we would need to provide guidance on >>>>scoring, >>>> rating, etc. I think most people should be able to understand >>>>low/med/high >>>> without having to have a mathematical method for arriving at the >>>>level. >>>> >>>> Low - I am not sure >>>> Medium - I am reasonably sure >>>> High - I am very sure >>>> >>>> >>>> Thanks, >>>> >>>> --Chris >>>> >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>IETF' >>>> Subject: RE: [mile] IOCs >>>> >>>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>>deal >>>> with large sets of indicators. >>>> Since indicator_set_id attribute is optional (right?), it could be >>>>omitted >>>> if we need to deal with only small number of indicators. >>>> >>>> Regarding the use case, I like the idea of using the confidence >>>>attribute >>>> for the reason Chris kindly described. >>>> I would like to hear a bit more on this: is it going to be numerical? >>>>For >>>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>>etc? >>>> >>>> Thank you. >>>> Take >>>> >>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>>>IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> With respect to tying things back to threat actors, from what I have >>>>> seen and use this is a generally accepted grouping: >>>>> >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>> >>>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Take & others, >>>>> >>>>> Thanks for chiming in, I've been talking about this with Chris and a >>>>> few others on their use cases and would like more opinions. I'll >>>>> provide an option below from what we have discussed from a CIRC view >>>>> point. We are also wondering how to also provide logic in IODEF that >>>>> could cross over into SCI attached schemas or IODEF extensions (the >>>>> solutions may all tie together with this discussion - or there may be >>>>> better/more elegant solutions others would like to propose). >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>>>'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>>> I like this discussion. >>>>>> I agree, it would be good idea to have indicator identifiers inside >>>>>> the IOC-related classes. >>>>> >>>>> KMM: At the class level, we may have several indicators listed that >>>>> should be viewed as a set and may have another instance of that same >>>>> class that is a related issue, but a separate set. We could as you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we get >>>>> into logic and relationships between sets or indicators. This could >>>>> also be a way to connect indicators or sets across XML documents that >>>>> could have been shared previously. If there are a large number of >>>>> indicators in the set, then this becomes useful, for smaller sets, I >>>>> agree it doesn't make as much sense. >>>>> >>>>> What do others think? >>>>> >>>>>>> Then for indicators not included in the base schema that may not >>>>>>> fit into a category in the SCI draft, do we create a place for >>>>>>> these off of SCI or right off of the IODE schema in EventData? >>>>>>> (more details >>>>> on >>>>>>> this in my first message). >>>>>> >>>>>> If we could see any indicator of compromise as computer event >>>>>> record, we could use SCI:EventReport class as the place for the >>>>>> XML-based IOCs that couldn't fit anywhere else. >>>>> >>>>> KMM: That sounds like a good idea to me. This should go into >>>>>guidance >>>>> in the SCI draft. Does anyone else want to weigh in? >>>>> >>>>>> >>>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>>> KMM: Sounds good, thanks! >>>>> >>>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>>> the indicator_set_id. >>>>>> I understand we could do some grouping of individual indicator_uids >>>>>> and its usability, but I am not sure whether we do not have any >>>>>> other way to express these groupings. >>>>>> For instance, a Reference class refers to several indicadtor_uids. >>>>> In >>>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>> >>>>> KMM: It may be, what do you think about large sets of indicators or >>>>> subsequent messages that add indicators to existing sets? Would this >>>>> happen? Would it be easier to express relationships with sets of >>>>> indicators in addition to individual indicators? By using this, it >>>>> could give us a unique way to also provide the logic and >>>>>relationships >>>>> in a new class of IODEF so we don't have to worry about adding it >>>>>into >>>>> the current >>>> structure. >>>>> If there are better ways to handle that, and others can provide some >>>>> options, that would be appreciated! >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>>> I would appreciate if anybody could share expertise on this. Though >>>>> I >>>>>> think I have read all the emails in the list, I might have >>>>>> mis-understood some points. >>>>>> >>>>>> By the way, I think the indicator_uids should be added to the SCI >>>> classes' >>>>>> attributes so that they can be correlated with another information >>>>>> as >>>>> well. >>>>>> >>>>>> Thanks >>>>>> Take >>>>> >>>>> >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between indicators. >>>>>If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>> >>>>> Thanks, >>>>> --Chris >>>>> >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>> >>>>> It is either that or going back to adding a Detection (or Indicators) >>>>> class that will should be used to take all of the indicators put them >>>>> into one place and have the ability to group the ones that go >>>>> together. I don't mean a place to put indicators that are missing >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the shared >>>>> Incident. I don't know the answer here, but there has got to be a >>>>> good way for indicators to be identified and being able to group them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> From: , Kathleen >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" , MILE >>>>> IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>> >>>>> The list has already said they would like to see indicators added to >>>>> the definitions in RFC5070-bis, to be more explicit about including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes. It was written before we used terms like >>>>> indicators. With that in mind, Rosella proposed a number of changes >>>>> back in July, both for guidance and for >>>> format >>>>> updates. It may help to have the first draft try to address at least >>>>> some of these issues so people can understand the problems and at >>>>> least a proposed solution. >>>>> >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators that >>>>> could have a relationship to each other within a document. In the >>>>> July presentation, one of the questions was to see if we should add >>>>> new category attribute values for the System class that would connect >>>>> the list of included indicators. I think we should still keep the >>>>> concept of a Node to a single node, but perhaps within System, list >>>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an >>>>>AttackType >>>>> (FraudType values could be included in AttackType or some broader >>>>> term). It may be better to have the FraudTypes, plus attribute >>>>>values >>>>> like "C2-server", "sinkhole", "MalwareDistribution" for added >>>>>context >>>>> so you know what to do with the received set of indicators. >>>>> >>>>> I am proposing that we change IODEF to include multiple sets of >>>> indicators, >>>>> add an AttackType attribute (or some other name), a method to connect >>>>> indicators and indicator sets within an IODEF using an attribute of >>>>> indicator_uid (or some other name) with a string value to make the >>>>> connection points, and add a few indicators that are commonly shared >>>>> into the base IODEF. >>>>> >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below). What if we added the Registry Key/Value pairs as a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, we >>>>> could connect a set within that structure and repeat the structure >>>>>for >>>>> other sets in the same way we would do with Node inside of the System >>>>> class, using the indicator_uid to tie the set together. Then at the >>>>> more specific level for the hash, registry Key/value, IP, etc. use an >>>>> indicator_uid if we needed them marked at this level as well? Maybe >>>>> we want indicator_set at the higher level? I'd like some opinions on >>>>> this approach. +1 if you agree, suggestions if you have other ideas >>>>> that may work better. >>>>> >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted. We may want to use these values >>>>> or something else. >>>>> >>>>> Thank you! >>>>> Kathleen >>>>> >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I think we have a bigger relationship issue to address. Let use the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>> >>>>> Two or more indicators of different type that relate to the same >>>>>threat: >>>>> The file hash of a malicious file and the URL of the C2 that >>>>> the file uses. Either or both may be present to indicate a >>>>>compromise. >>>>> >>>>> Two or more indicators of the same type that relate to the same >>>>>threat: >>>>> 2 different registry values for the same registry key. If >>>>> either value is present it is a compromise indicator but both will >>>>>not >>>>> be >>>> present. >>>>> >>>>> The problem compounds itself very quickly. Consider the scenario >>>>>where >>>>> both groupings above are part of the same threat. I need to show that >>>>> logical groupings of Indicators are related as well. We can't send >>>>> multiple IODEF messages for this from what I remember reading. >>>>> >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>>> IOCs are the 2 hash values. How do we show they are related? If we >>>>>use >>>>> a unique Inidcator ID for each hash value there needs to be a higher >>>>> level >>>> grouping. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> All - >>>>> >>>>> I'd like your input and will refocus the thread to get opinions from >>>>> the list on options to help solve the problems raised in my message >>>>> and additionally in Paul's message. >>>>> >>>>> Interesting point, C. Henry. Our objective here is to have machine >>>>> automated exchanges, so we rely on encryption rather than obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>> >>>>> Paul mentioned the need to distinguish indicators of compromise from >>>>> context information that may also include IP address or other data >>>>> that could be indicators. The question I raised was on how to >>>>>connect >>>>> sets of indicators in the same IODEF document, assuming the ability >>>>>to >>>>> have watchlists that could have several sets of indicators included, >>>>> as well as to connect indicators that may be included in embedded >>>>> schemas. >>>>> >>>>> If we add an attribute on all of the relevant indicators, let's say >>>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>>>mark >>>>> who sent the indicator as well so that we can prevent forward sharing >>>>> when it is not permitted or handle that separately? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? (more details on >>>>> this in my first message). >>>>> >>>>> Comments and questions encouraged to figure out the right technical >>>>> solution to have this machine automatable. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Temporal Dependency sounds interesting. I remember when I first ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question. He said, " How do you stop someone from tracking >>>>> the IP Address to your computer?" >>>>> >>>>> I replied, "I don't know, how?" >>>>> >>>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>>> connected- which is constantly on!" LOL >>>>> >>>>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>>>or >>>>> let's just say "Live" Terrorist Situation. He /or She needs to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger. The device used to communicate has been captured by the >>>>>great >>>>> minds of the enemy. It's only a matter of time before they utilize >>>>> reverse engineering to figure out how it functions. However, their >>>>> pride comes before a fall when seeking the location of other similar >>>>> devices to attack. Why? Perhaps the less thought of concepts that >>>>> makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>> >>>>> Just a visionary thought. >>>>> >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>> >>>>> From: Dave Misell >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>>>DNS >>>>> SEC a pemanent and temporal key, with a temporal Id? >>>>> >>>>> Yours Faithfully, >>>>> >>>>> Dave Misell MSc CISSP >>>>> SilentCircle dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>> >>>>> >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>>> >>>>> wrote: >>>>> >>>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>>> was >>>>> closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant minds >>>>> in some instances." >>>>>> >>>>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>>>> would >>>>> be nice if the UID was in some way disguised from those who study >>>>>this >>>>> Security Art Form in a negative way. >>>>>> >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>>> >>>>>> >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution >>>>>within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>> >>>>>> Re: [mile] IOCs >>>>>> >>>>>> Sunday, January 27, 2013 8:52 PM >>>>>> From: >>>>>> "Stoecker, Paul" >>>>>> To: >>>>>> "mile@ietf.org" >>>>>> I would like to look at this from a slightly different >>>>>> perspective=A9let's say I get an XML document that tells me about an >>>>>> incident. This document has source IP and destination IP that is >>>>>> being shared. However, what I don't know is which IP address is my >>>>>> indicator and which is just a contextual piece of information. This >>>>>> means that my detection product isn't going to know which one to use >>>>>> either, because there is nothing to tell me which IP is the one, >>>>>>even >>>>>> if the roles are set it still might not be enough to tell my system >>>>> which >>>>> one I should use as the indicator. >>>>>> >>>>>> If we had something like indicator_id as an attribute, it would >>>>>>allow >>>>>> us to easily identify indicators from contextual data. I do admit >>>>>>to >>>>>> being biased as I have spent much of my career working on the >>>>>> monitoring and detection side of these things, so I am just thinking >>>>>> of ways to make it very clear what the indicators are in the XML >>>>>> document and the other data that may be important as I investigate >>>>>> activity that I have detected off of those indicators. >>>>>> >>>>>> >>>>>> I did suggest the detection class, but I think we may get more >>>>>> flexibility with the indicator_uid. One thing that I haven't >>>>>> considered is the UID portion of this=A9how do we use that UID? How >>>>>>is >>>>>> the UID created? Are there standards for UIDs? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> Paul W. Stoecker, Ph.D. >>>>>> SMC Lead Content Architect >>>>>> RSA, The Security Division of EMC >>>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>>> >>>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>>>wrote: >>>>>> >>>>>> From: C. Henry Adams & BIE >>>>>> Subject: RE: [mile] IOCs >>>>>> To: "KathleenMoriarty" >>>>>> Cc: mile@ietf.org >>>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>>> >>>>>> Greetings Kathleen, >>>>>> >>>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>>> many >>>>> avenues you review with this approach at once. However, could you >>>>>share >>>>> a >>>>> few advantages and disadvantages to the latter? >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>>> "we could continue to group items in logical places as is done now >>>>>>in >>>>> IODEF and then have the extension point for combined indicators via >>>>>SCI." >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>>> >>>>>> You pointed out what you consider to be logical places, but if I >>>>>> wanted to >>>>> protect information from parties capable of ascertaining it from your >>>>> logical places, perhaps we should also consider to a degree what >>>>>appears >>>>> to >>>>> be illogical in brilliant minds in some instances. >>>>>> >>>>>> >>>>>> >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) >>>>>> chenryadams@biemediagroup.com >>>>>> >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution >>>>>within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>> >>>>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>>> wrote: >>>>>> >>>>>> From: Moriarty, Kathleen >>>>>> Subject: RE: [mile] IOCs >>>>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>>> >>>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>>> >>>>>> Hello C. Henry & others, >>>>>> >>>>>> Thanks for taking a look at this. We have a few considerations in >>>>>> this >>>>> email thread I would like to hear thoughts on (and there may be more >>>>>once >>>>> RFC5070-bis is actively edited). >>>>>> >>>>>> The AdditionalData class and the RecordItem class both allow for >>>>>> non-XML >>>>> extensions. Where you place the extensions should be specific to the >>>>> logical grouping of the parent elements so you can understand more >>>>>about >>>>> the >>>>> included data in most cases. >>>>>> >>>>>> The Impact class can be used to provide context information on the >>>>> included data of the report and also can include a confidence rating >>>>>on >>>>> the >>>>> report as a whole. Extensions related to impact would be one level >>>>>higher >>>>> (at the moment) in the Assessment class using the AdditionalData >>>>>extension >>>>> point. >>>>>> >>>>>> Take asked about including vulnerability information, I would think >>>>>> that >>>>> would fit under the Vulnerability extension point of the SCI draft in >>>>> the >>>>> Method class. He did ask about non-XML. RecordItem or >>>>>AdditionalData >>>>> do >>>>> allow for non-XML extension points, we could either have the SCI >>>>>draft >>>>> handle these as well or have the extensions that are non-XML come >>>>>directly >>>>> off the AdditionalData or RecordItem classes according to what makes >>>>>sense >>>>> from a logical standpoint. >>>>>> >>>>>> As for my question, it was two-fold. >>>>>> >>>>>> Indicator based schemas have a reference number or a GUID for the >>>>>> various >>>>> indicators they share. If we are extending to embed other schemas >>>>>that >>>>> include such reference or GUID identifiers, do we want to add an >>>>>attribute >>>>> to the various elements in IODEF that could be indicators? Is this >>>>>enough >>>>> to make the connections or is something else else needed? We could >>>>>add >>>>> something like an Indicator_ID in RFC5070-bis which would then >>>>>correlate >>>>> to >>>>> the reference or GUID identifiers. >>>>>> >>>>>> Then the other question was on how to include indicators that are >>>>>>not >>>>>> in >>>>> the base schema that may be related or have language with "and" "or" >>>>>to >>>>> specify the relationships. In some cases, you will want to group >>>>>these >>>>> indictors in one extension point, where they may fit logically in >>>>>multiple >>>>> places if the relationships did not need to be shown in the data >>>>> format. If >>>>> we have cases like this where you need more complex representations, >>>>> should >>>>> we use one extension point via the SCI draft off of the EventData >>>>>class >>>>> AdditionalData extension point? Opinions are needed here.... >>>>>> >>>>>> A few people have mentioned wanting to include some commonly shared >>>>> indictors into the base IODEF document. We could have a catch-all >>>>>class >>>>> that does this and has an extension point off of it in EventData or >>>>>we >>>>> could >>>>> continue to group items in logical places as is done now in IODEF and >>>>> then >>>>> have the extension point for combined indicators via SCI. I think I >>>>>like >>>>> the latter approach. >>>>>> >>>>>> Thank you, >>>>>> Kathleen >>>>>> ________________________________________ >>>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>>> To: mile@ietf.org >>>>>> Cc: C. Henry Adams >>>>>> Subject: Re: [mile] IOCs >>>>>> >>>>>> Greetings Everyone, >>>>>> >>>>>> Take mentioned two types of indicators based on the : >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>>> 1) If the indicators are something like an XML-based alert/warning >>>>>>of >>>>>> information leakage, it could be an event that are conveyed in the >>>>>> SCI's EventReport class, IMHO. >>>>>> >>>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>>> could >>>>> be >>>>>> conveyed without using SCI draft. >>>>>> For instance, we could use Impact class of the base IODEF to convey >>>>>> the indicators. >>>>>> We could for instance extend the list of indicators of the Impact >>>>>> class, >>>>> if >>>>>> needed. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>>> >>>>>> In doing so he pointed out the "Impact Class" >>>>>> >>>>>> Whereas, Kathleen stated, >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>>> For the discussion below, I was thinking more of combined set with >>>>> relationships that may be included in a single extension point, so >>>>>that's >>>>> why I was thinking about the EventData class, but there may be better >>>>> locations or a specific area within the EventData. >>>>>> >>>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>>> >>>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>>> >>>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to simplify >>>>> this >>>>> issue? >>>>>> >>>>>> >>>>>> C. Henry Adams >>>>>> chatlga2000@yahoo.com (Direct Email) >>>>>> chenryadams@biemediagroup.com >>>>>> >>>>>> >>>>>> The information contained herein is for the exclusive use of the >>>>>> original >>>>> recipient. This information is granted for limited distribution >>>>>within >>>>> the >>>>> recipient's place of business for planning purposes only. Further >>>>> dissemination, whether private or public is prohibited. >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From Kent_Landfield@mcafee.com Wed Feb 13 05:47:41 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8321F86EF for ; Wed, 13 Feb 2013 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5U5AMKCwbUm for ; Wed, 13 Feb 2013 05:47:36 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id D9FDB21F86F0 for ; Wed, 13 Feb 2013 05:47:35 -0800 (PST) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 3554_2b02_9c818890_c0fb_4023_ac3e_2ee6c7dbf820; Wed, 13 Feb 2013 07:47:15 -0600 Received: from MIVEXAPP2N2.corp.nai.org (10.48.48.72) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Feb 2013 08:45:03 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.252]) by MIVEXAPP2N2.corp.nai.org ([169.254.3.95]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 08:45:03 -0500 From: To: , , , Thread-Topic: [mile] IOCs Thread-Index: AQHOCfBSa5Jx1DXCz0Xe6yJsWBsaUw== Date: Wed, 13 Feb 2013 13:45:02 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF14CC18@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF14CC18MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: chatlga2000@yahoo.com, mile@ietf.org Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:47:41 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF14CC18MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I agree that what we really need is both. In most situations a low, medium= and high may be acceptable but there are times when we will want to show t= hat confidence in a situation is increasing or decreasing. If we are only = looking at a three levels, we cannot express what is needed to show confide= nce is trending up on the data being exchanged about the event. Kathleen included the following in a previous message. Vs: 85 I really think we need to include both capabilities as John alluded to sinc= e confidence is not a three tiered item but something that is indeed subjec= tive and we need a means to show a reasonably accurate confidence index tha= t the sender is trying to convey. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , John Banghart > Date: Wednesday, February 13, 2013 7:16 AM To: "Stoecker, Paul" >,= Kathleen Moriarty >, Brian Trammell > Cc: "C. Henry Adams & BIE" >, MILE IETF > Subject: Re: [mile] IOCs Paul, I agree that confidence is subjective, but subjectivity can be reduced within communities that interact frequently. Prioritization of indicators and response between tightly connected sharing partners might require a more specific level of detail, particularly during a crisis situation. >From that perspective, I think the guidance should allow for additional granularity, while stressing the "high, medium, low" as preferred for broad interoperability. -John On 2/13/13 8:04 AM, "Stoecker, Paul" > wrote: I may have been too succinct in my response ;-) Confidence is a subjective thing, so I think we should use subjective terms: Low, Medium, High. Having a numeric scale with a map that essentially would say something like: 1-33 =3D Low 34-67=3D Medium 68-100=3DHigh Is just a more complicated way of saying that something is Low, Medium, High...do we really thing that how High something is makes that much of a difference? This is like when you get your Performance review where it is Does Not Meet, Meets and Exceeds...your boss tells you that you are a High Meets...your bonus tells you that you got the same bonus that all the other Meets got ;-) Anyway, I digress but trying to prove a point that I would argue that confidence in this case is going to be basically a gut feeling, so why use numeric values when Low, Medium, High would do just fine. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/13/13 7:48 AM, "Moriarty, Kathleen" > wrote: Hello, Both approaches will validate in the current schema. The representation looks a little different for each, here is an example: Vs: 85 Searching capability is a great point, agreed. I'd like to hear from more people to make sure we don't lose a capability that others find extremely useful (need to gauge that). Other options is that the guidance can also discourage the use of the numeric in addition to specifying how to select ranges. Any other opinions? Thanks, Kathleen -----Original Message----- From: Stoecker, Paul Sent: Wednesday, February 13, 2013 7:14 AM To: Brian Trammell Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF Subject: Re: [mile] IOCs Cant we make Confidence a List that has only 3 values: High, Medium, and Low? Any other value means that the Document will mot validate against the schema. Sent from my iPhone On Feb 13, 2013, at 2:14 AM, "Brian Trammell" > wrote: Hi, Kathleen, all, I think 3.10.4 in 5070 takes the right approach here: trying to build interoperable numeric scales for assessment is a very hard problem. (Were I charged with defining such a scale, the value "70" would mean "we compared this incident report to N past similar incident reports according to similarity algorithm S, and 70% of the past reports had assessed impacts within E% of the actual, measured final impact -- I think for most applications this is vastly more difficult and rigorous than it needs to be.) Unless a numeric Confidence value is based on some actual, repeatably measurable aspect of the Assessment report -- which I suspect in many/most/all cases it's not -- then it just represents a guess, however educated. Each team will probably naturally tune its own scales such that each value generally means the same thing in each report. Across teams, I don't know. On the other hand, Assessments are by their very nature educated guesses, anyway, so I don't know that I'd find much use in automating a response based on the assessment confidence. Chris has a good point, though -- it makes searching difficult and sorting kind of pointless. If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I agree, we should put that in the guidance document (along with a note that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, unless we want to do it non-linearly). If the _vast_majority_ of the users of this field use a 100-point scale with 100 meaning "yes" and 0 meaning "any resemblance these values may have to actual fact is purely coincidental", then let's consider renaming it "percent" in 5070-bis. Best regards, Brian (as contributor) On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" > wrote: Please see section 3.10.4 of RFC5070 as a starting point. We can change it if it needs to be changed. The value is for a confidence rating on the indicators shared. The definitions may be helpful for anyone who wants to work on this discussion. IODEF has various markers that can be used in a complimentary way without conflating the markers meaning. I think some people using IODEF find the numerical values more helpful, and it would be good to understand what people have learned from using the current structure (what works/does not work). The scales I have seen are 0-100. There is of course a subjective element to assigning a numerical value to the confidence and it may vary from entity to entity. With this type of rating you may need to consider who it came from and how they scored the confidence rating to map to your own rating. It would be good to hear more thoughts on this. Thanks, Kathleen From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] Sent: Tuesday, February 12, 2013 2:46 PM To: MILE IETF Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul Subject: Re: [mile] IOCs Regarding the IOCs or Indicators of Compromise, Chris made a vital point. Different Confidence levels will cause confusion. It appears that there maybe a need for some type of simplified standardization to be established between all Sharing Groups in this regard. Perhaps numerical scoring set at lower values should express levels of urgency. ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D Urge= nt, 5 =3D Imminent ) Thanks, C. Henry Adams I see some confusion coming down the pike if we start using Confidence the way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale of 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text. Makes searching / sorting very problematic. At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point. Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Chris & Take, I'll just focus on the confidence scoring. Right now, the schema allows for you to either use a numerical score OR the ratings of low, medium, and high. Different sharing groups can decide how they want to share the data. If people were to use the numerical values, I agree it would be helpful to have guidance. This could go in the IODE guidance document. I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level. Low - I am not sure Medium - I am reasonably sure High - I am very sure Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? Thank you. Take -----Original Message----- From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Friday, February 08, 2013 4:11 AM To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs With respect to tying things back to threat actors, from what I have seen and use this is a generally accepted grouping: Indicator --> Indictor Set --> Campaign --> Threat Actor Campaign and Threat Actor are where having a "Confidence" attribute would be beneficial as making those associations is not a perfect science by any means. Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen Sent: Thursday, February 07, 2013 2:00 PM To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Take & others, Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions. I'll provide an option below from what we have discussed from a CIRC view point. We are also wondering how to also provide logic in IODEF that could cross over into SCI attached schemas or IODEF extensions (the solutions may all tie together with this discussion - or there may be better/more elegant solutions others would like to propose). -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF' Subject: RE: [mile] IOCs I like this discussion. I agree, it would be good idea to have indicator identifiers inside the IOC-related classes. KMM: At the class level, we may have several indicators listed that should be viewed as a set and may have another instance of that same class that is a related issue, but a separate set. We could as you say, list the indicator IDs connected through the reference class. The set IDs might give us other ways to group the values when we get into logic and relationships between sets or indicators. This could also be a way to connect indicators or sets across XML documents that could have been shared previously. If there are a large number of indicators in the set, then this becomes useful, for smaller sets, I agree it doesn't make as much sense. What do others think? Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). If we could see any indicator of compromise as computer event record, we could use SCI:EventReport class as the place for the XML-based IOCs that couldn't fit anywhere else. KMM: That sounds like a good idea to me. This should go into guidance in the SCI draft. Does anyone else want to weigh in? For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! I agree to have indicator_uid, but I am not sure about the needs of the indicator_set_id. I understand we could do some grouping of individual indicator_uids and its usability, but I am not sure whether we do not have any other way to express these groupings. For instance, a Reference class refers to several indicadtor_uids. In this case, they could be, in a sense, grouped. Isn't it enough? KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets? Would this happen? Would it be easier to express relationships with sets of indicators in addition to individual indicators? By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current structure. If there are better ways to handle that, and others can provide some options, that would be appreciated! Thank you, Kathleen I would appreciate if anybody could share expertise on this. Though I think I have read all the emails in the list, I might have mis-understood some points. By the way, I think the indicator_uids should be added to the SCI classes' attributes so that they can be correlated with another information as well. Thanks Take From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs I think some sort of group ID would do the trick. We also need a logical and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have the same group ID since they are related. Thanks, --Chris From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group ID. Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't mean a place to put indicators that are missing from IODEF.I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident. I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs Hi Chris, I agree, we have some work to do in the updated IODEF, RFC5070-bis. The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an incident or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates. It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution. As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators. I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack. Rosella had suggested pulling forward the "FraudType" from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term). It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF. Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below). What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together. Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well? Maybe we want indicator_set at the higher level? I'd like some opinions on this approach. +1 if you agree, suggestions if you have other ideas that may work better. We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or something else. Thank you! Kathleen From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related: Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses. Either or both may be present to indicate a compromise. Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading. The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. Thoughts? Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs All - I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. Paul mentioned the need to distinguish indicators of compromise from context information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately? Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). Comments and questions encouraged to figure out the right technical solution to have this machine automatable. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs Temporal Dependency sounds interesting. I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP Address to your computer?" I replied, "I don't know, how?" Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let's just say "Live" Terrorist Situation. He /or She needs to communication back to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's only a matter of time before they utilize reverse engineering to figure out how it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell > wrote: From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to a degree what appears to be illogical in brilliant minds in some instances." However, I see Dr. Stoecker's point a little clearer. However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryad= ams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. Re: [mile] IOCs Sunday, January 27, 2013 8:52 PM From: "Stoecker, Paul" > To: "mile@ietf.org" > I would like to look at this from a slightly different perspective=A9let's say I get an XML document that tells me about an incident. This document has source IP and destination IP that is being shared. However, what I don't know is which IP address is my indicator and which is just a contextual piece of information. This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data. I do admit to being biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. I did suggest the detection class, but I think we may get more flexibility with the indicator_uid. One thing that I haven't considered is the UID portion of this=A9how do we use that UID? How is the UID created? Are there standards for UIDs? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs To: "KathleenMoriarty" > Cc: mile@ietf.org Date: Saturday, January 26, 2013, 6:17 PM Greetings Kathleen, Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once. However, could you share a few advantages and disadvantages to the latter? -------------------------------------------------------------------- -------- ---------------------------------------------- "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI." -------------------------------------------------------------------- -------- --------------------------------------------- You pointed out what you consider to be logical places, but if I wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: From: Moriarty, Kathleen > Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" >, "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM Hello C. Henry & others, Thanks for taking a look at this. We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited). The AdditionalData class and the RecordItem class both allow for non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about the included data in most cases. The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole. Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point. Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class. He did ask about non-XML. RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint. As for my question, it was two-fold. Indicator based schemas have a reference number or a GUID for the various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators? Is this enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers. Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format. If we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here.... A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI. I think I like the latter approach. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@iet= f.org] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org Cc: C. Henry Adams Subject: Re: [mile] IOCs Greetings Everyone, Take mentioned two types of indicators based on the : -------------------------------------------------------------------- -------- -------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. -------------------------------------------------------------------- -------- -------------------------- In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, -------------------------------------------------------------------- -------- ------------------------- For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. -------------------------------------------------------------------- -------- ------------------------ Kathleen thoughts related yet still with other indicators and the EventData Class. Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF14CC18MIVEXAMER1N1corpn_ Content-Type: text/html; charset="iso-8859-2" Content-ID: <1A93FCE1F84ADC4B804E281306FC4EAF@McAfee.com> Content-Transfer-Encoding: quoted-printable
I agree that what we really need is both.  In most situations a l= ow, medium and high may be acceptable but there are times when we will want= to show that confidence in a situation is increasing or decreasing.  = If we are only looking at a three levels, we cannot express what is needed to show confidence is trending up on the = data being exchanged about the event.

Kathleen included the following in a previous message.

<Confidence ra= ting=3D"low"/>

Vs:

<Confidence ra= ting=3D"numeric">85</>

I really think we need to include both capabilities as John alluded to= since confidence is not a three tiered item but something that is indeed s= ubjective and we need a means to show a reasonably accurate confidence inde= x that the sender is trying to convey.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Banghart>, John Bangha= rt <john.banghart@nist.gov= >
Date: Wednesday, February 13, 2013 = 7:16 AM
To: "Stoecker, Paul" <= Paul.Stoecker@rsa.com>, Kat= hleen Moriarty <kathleen.mo= riarty@emc.com>, Brian Trammell <trammell@tik.ee.ethz.ch>
Cc: "C. Henry Adams & BIE&= quot; <chatlga2000@yahoo.com>, MILE IETF <mile@ietf.org>=
Subject: Re: [mile] IOCs

Paul,

I agree that confidence is subjective, but subjectivity can be reduced=
within communities that interact frequently.  Prioritization= of indicators
and response between tightly connected sharing partners might require = a
more specific level of detail, particularly during a crisis situation.=

From that perspective, I think the guidance should allow for additiona= l
granularity, while stressing the "high, medium, low" as pref= erred for
broad interoperability.

-John

On 2/13/13 8:04 AM, "Stoecker, Paul" <Paul.Stoecker@rsa.com> wrote:

I may have been too succinct in my response ;-)

Confidence is a subjective thing, so I think we should use subjective<= /div>
terms:  Low, Medium, High.  Having a numeric scale= with a map that
essentially would say something like:

1-33 =3D Low
34-67=3D Medium
68-100=3DHigh

Is just a more complicated way of saying that something is Low, Medium= ,
High...do we really thing that how High something is makes that much o= f a
difference?

This is like when you get your Performance review where it is Does Not=
Meet, Meets and Exceeds...your boss tells you that you are a High
Meets...your
bonus tells you that you got the same bonus that all the other Meets g= ot
;-)

Anyway, I digress but trying to prove a point that I would argue that<= /div>
confidence in this case is going to be basically a gut feeling, so why= use
numeric values when Low, Medium, High would do just fine.


Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.= stoecker@rsa.com






On 2/13/13 7:48 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
wrote:

Hello,

Both approaches will validate in the current schema.  The re= presentation
looks a little different for each, here is an example:

<Confidence rating=3D"low"/>

Vs:

<Confidence rating=3D"numeric">85</>

Searching capability is a great point, agreed.  I'd like to = hear from
more people to make sure we don't lose a capability that others find
extremely useful (need to gauge that).  Other options is tha= t the
guidance can also discourage the use of the numeric in addition to
specifying how to select ranges.

Any other opinions?

Thanks,
Kathleen

-----Original Message-----
From: Stoecker, Paul
Sent: Wednesday, February 13, 2013 7:14 AM
To: Brian Trammell
Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF
Subject: Re: [mile] IOCs

Cant we make Confidence a List that has only 3 values:  High= , Medium, and
Low?  Any other value means that the Document will mot valid= ate against
the schema.

Sent from my iPhone

On Feb 13, 2013, at 2:14 AM, "Brian Trammell" <trammell@tik.ee.ethz.ch>
wrote:

Hi, Kathleen, all,

I think 3.10.4 in 5070 takes the right approach here: trying to build<= /div>
interoperable numeric scales for assessment is a very hard problem.
(Were I charged with defining such a scale, the value "70" w= ould mean
"we compared this incident report to N past similar incident repo= rts
according to similarity algorithm S, and 70% of the past reports had
assessed impacts within E% of the actual, measured final impact -- I
think for most applications this is vastly more difficult and rigorous=
than it needs to be.)

Unless a numeric Confidence value is based on some actual, repeatably<= /div>
measurable aspect of the Assessment report -- which I suspect in
many/most/all cases it's not -- then it just represents a guess, howev= er
educated.  Each team will probably naturally tune its own sc= ales such
that each value generally means the same thing in each report. Across<= /div>
teams, I don't know.

On the other hand, Assessments are by their very nature educated
guesses, anyway, so I don't know that I'd find much use in automating = a
response based on the assessment confidence. Chris has a good point,
though -- it makes searching difficult and sorting kind of pointless.<= /div>

If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%"= ;, then I
agree, we should put that in the guidance document (along with a note<= /div>
that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high,=
unless we want to do it non-linearly). If the _vast_majority_ of the
users of this field use a 100-point scale with 100 meaning "yes&q= uot; and 0
meaning "any resemblance these values may have to actual fact is = purely
coincidental", then let's consider renaming it "percent"= ; in 5070-bis.

Best regards,

Brian (as contributor)


On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"

Please see section 3.10.4 of RFC5070 as a starting point.  W= e can
change it if it needs to be changed.  The value is for a con= fidence
rating on the indicators shared.  The definitions may be hel= pful for
anyone who wants to work on this discussion.  IODEF has vari= ous markers
that can be used in a complimentary way without conflating the markers=
meaning.

I think some people using IODEF find the numerical values more
helpful, and it would be good to understand what people have learned
from using the current structure (what works/does not work). &nbs= p;The
scales I have seen are 0-100.  There is of course a subjecti= ve element
to assigning a numerical value to the confidence and it may vary from<= /div>
entity to entity.  With this type of rating you may need to = consider
who it came from and how they scored the confidence rating to map to
your own rating.  It would be good to hear more thoughts on = this.

Thanks,
Kathleen

From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]
Sent: Tuesday, February 12, 2013 2:46 PM
To: MILE IETF
Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
Subject: Re: [mile] IOCs


Regarding the IOCs or Indicators of Compromise, Chris made a vital
point.  Different Confidence levels will cause confusion.&nb= sp; It appears
that there maybe a need for some type of simplified standardization to=
be established between all Sharing Groups in this regard.

Perhaps numerical scoring set at lower values should express levels of=
urgency.
( i.e.  1 =3D Less Likely,   2 =3D Probable, =  3 =3D A Concern,  4 =3D  Urgent,
5 =3D Imminent )

Thanks,
C. Henry Adams



I see some confusion coming down the pike if we start using Confidence=
the
way it is supported. If I am using low/med/high and someone sends me
an IoC
with a score of 70, what does that mean to me? What if I am using a
scale of
1 to 4 and someone else is on a scale of 1 to 5? We lose the ability
to
describe something with a consistent language. It really gets ugly
when we
store IoC from multiple sources. I have confidence values that are
numeric
as well as text.  Makes searching / sorting very problematic= .

At this point we have to roll with what we have. I would strongly
recommend
that we revisit this at some point.

Thanks,

--Chris

-----Original Message-----
From: Moriarty, Kathleen
Sent: Tuesday, February 12, 2013 9:59 AM
To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;
'MILE
IETF'
Subject: RE: [mile] IOCs

Hi Chris & Take,

I'll just focus on the confidence scoring.  Right now, the s= chema
allows for
you to either use a numerical score OR the ratings of low, medium, and=
high.
Different sharing groups can decide how they want to share the data.
If
people were to use the numerical values, I agree it would be helpful
to have
guidance.  This could go in the IODE guidance document.

I have seen examples of current users that use each of the approaches,=
so
we'll need to keep the option for backwards compatibility and it is
nice to
keep in flexible options where we can.

Thank you,
Kathleen

-----Original Message-----
From: Harrington, Christopher
Sent: Tuesday, February 12, 2013 9:22 AM
To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

The number of indicators wouldn't necessarily drive the use of
indicator_set_id. The purpose is to show relationship. If I sent 3 IP<= /div>
addresses that were used as C2 for 3 different campaigns I would have<= /div>
separate indicator_set_ids, each with one of the 3 C2 IPs

My suggestion would be a simple low, medium, high. I think if we break=
it
down to more levels than that we would need to provide guidance on
scoring,
rating, etc. I think most people should be able to understand
low/med/high
without having to have a mathematical method for arriving at the
level.

Low - I am not sure
Medium - I am reasonably sure
High - I am very sure


Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE=
IETF'
Subject: RE: [mile] IOCs

Regarding the indicator_set_id, I agree, it is useful when we need to<= /div>
deal
with large sets of indicators.
Since indicator_set_id attribute is optional (right?), it could be
omitted
if we need to deal with only small number of indicators.

Regarding the use case, I like the idea of using the confidence
attribute
for the reason Chris kindly described.
I would like to hear a bit more on this: is it going to be numerical?<= /div>
For
instance, 1 means "no confidence" while 5 means "strong= confidence",
etc?

Thank you.
Take


-----Original Message-----
From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]
Sent: Friday, February 08, 2013 4:11 AM
To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

With respect to tying things back to threat actors, from what I have
seen and use this is a generally accepted grouping:

Indicator --> Indictor Set --> Campaign --> Threat Actor

Campaign and Threat Actor are where having a "Confidence" at= tribute
would be beneficial as making those associations is not a perfect
science by any means.

Thanks,

--Chris


-----Original Message-----
From: Moriarty, Kathleen
Sent: Thursday, February 07, 2013 2:00 PM
To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE<= /div>
IETF'
Subject: RE: [mile] IOCs

Hi Take & others,

Thanks for chiming in, I've been talking about this with Chris and a
few others on their use cases and would like more opinions.  = ;I'll
provide an option below from what we have discussed from a CIRC view
point.  We are also wondering how to also provide logic in I= ODEF that
could cross over into SCI attached schemas or IODEF extensions (the
solutions may all tie together with this discussion - or there may be<= /div>
better/more elegant solutions others would like to propose).

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Tuesday, February 05, 2013 12:04 PM
To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;
'MILE
IETF'
Subject: RE: [mile] IOCs

I like this discussion.
I agree, it would be good idea to have indicator identifiers inside
the IOC-related classes.

KMM: At the class level, we may have several indicators listed that
should be viewed as a set and may have another instance of that same
class that is a related issue, but a separate set.  We could= as you
say, list the indicator IDs connected through the reference class.
The set IDs might give us other ways to group the values when we get
into logic and relationships between sets or indicators.  Th= is could
also be a way to connect indicators or sets across XML documents that<= /div>
could have been shared previously.  If there are a large num= ber of
indicators in the set, then this becomes useful, for smaller sets, I
agree it doesn't make as much sense.

What do others think?

Then for indicators not included in the base schema that may not
fit into a category in the SCI draft, do we create a place for
these off of SCI or right off of the IODE schema in EventData?
(more details
on
this in my first message).

If we could see any indicator of compromise as computer event
record, we could use SCI:EventReport class as the place for the
XML-based IOCs that couldn't fit anywhere else.

KMM: That sounds like a good idea to me.  This should go int= o
guidance
in the SCI draft.  Does anyone else want to weigh in?


For the non-XML IOCs, we could use RecordData class, as suggested.
KMM: Sounds good, thanks!

I agree to have indicator_uid, but I am not sure about the needs of
the indicator_set_id.
I understand we could do some grouping of individual indicator_uids
and its usability, but I am not sure whether we do not have any
other way to express these groupings.
For instance,  a Reference class refers to several indicadto= r_uids.
In
this case, they could be, in a sense, grouped. Isn't it enough?

KMM: It may be, what do you think about large sets of indicators or
subsequent messages that add indicators to existing sets?  W= ould this
happen?  Would it be easier to express relationships with se= ts of
indicators in addition to individual indicators?  By using t= his, it
could give us a unique way to also provide the logic and
relationships
in a new class of IODEF so we don't have to worry about adding it
into
the current
structure.
If there are better ways to handle that, and others can provide some
options, that would be appreciated!

Thank you,
Kathleen

I would appreciate if anybody could share expertise on this. Though
I
think I have read all the emails in the list, I might have
mis-understood some points.

By the way, I think the indicator_uids should be added to the SCI
classes'
attributes so that they can be correlated with another information
as
well.

Thanks
Take



Of Harrington, Christopher
Sent: Tuesday, February 05, 2013 4:25 AM
To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF
Subject: Re: [mile] IOCs

I think some sort of group ID would do the trick. We also need a
logical and / or somewhere to show relationship between indicators.
If
I give you
2
registry keys do they both have to be present to be an indication of
compromise or is either one by themselves an indicator? Both would
have the same group ID since they are related.

Thanks,
--Chris

From: Stoecker, Paul
Sent: Sunday, February 03, 2013 8:26 PM
To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF
Subject: Re: [mile] IOCs

What if we added indicator group ID along with the indicator_uid?
This would allow you to group indicators that are related into the
same group ID.
Would this resolve the issue?

It is either that or going back to adding a Detection (or Indicators)<= /div>
class that will should be used to take all of the indicators put them<= /div>
into one place and have the ability to group the ones that go
together.  I don't mean a place to put indicators that are m= issing
from IODEF.I mean a place in the IODEF document where you put the
indicators that are used for detection and prevention of the shared
Incident.  I don't know the answer here, but there has got t= o be a
good way for indicators to be identified and being able to group them<= /div>
as Chris has suggested without basically recreating something
complicated like STIX.

Paul


Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.= stoecker@rsa.com
Date: Sunday, February 3, 2013 5:11 PM
To: "Harrington, Christopher" <Christopher.Harrington@emc.com>, MILE
Subject: Re: [mile] IOCs

Hi Chris,

I agree, we have some work to do in the updated IODEF, RFC5070-bis.

The list has already said they would like to see indicators added to
the definitions in RFC5070-bis, to be more explicit about including
indicators and sets of indicators in IODE documents as opposed to
'parts of an incident or the useful information on an incident for
sharing purposes.  It was written before we used terms like<= /div>
indicators.  With that in mind, Rosella proposed a number of= changes
back in July, both for guidance and for
format
updates.  It may help to have the first draft try to address= at least
some of these issues so people can understand the problems and at
least a proposed solution.

As you point out, we need to be able to show relationships between
sets of indicators, where we may have a few sets of indicators that
could have a relationship to each other within a document.  = In the
July presentation, one of the questions was to see if we should add
new category attribute values for the System class that would connect<= /div>
the list of included indicators.  I think we should still ke= ep the
concept of a Node to a single node, but perhaps within System, list
multiple sets of Nodes that may be one type of attack.  Rose= lla had
suggested pulling forward the "FraudType" from RFC5901, this= would
help solve the issue as NodeRole values would compliment an
AttackType
(FraudType values could be included in AttackType or some broader
term).  It may be better to have the FraudTypes, plus attrib= ute
values
like "C2-server", "sinkhole",  "Mal= wareDistribution" for added
context
so you know what to do with the received set of indicators.

I am proposing that we change IODEF to include multiple sets of
indicators,
add an AttackType attribute (or some other name), a method to connect<= /div>
indicators and indicator sets within an IODEF using an attribute of
indicator_uid (or some other name) with a string value to make the
connection points, and add a few indicators that are commonly shared
into the base IODEF.

Back in July, we talked about adding Registry Key/Value pairs and
hashes to the main IODEF document (trying to see if this will help
Chris below).  What if we added the Registry Key/Value pairs= as a
class off of RecordData, using a similar structure to what is in
RFC5901, and also added the ability to include hashes in RecordData?
I think if we then had the indicator_uid at the RecordData level, we
could connect a set within that structure and repeat the structure
for
other sets in the same way we would do with Node inside of the System<= /div>
class, using the indicator_uid to tie the set together.  The= n at the
more specific level for the hash, registry Key/value, IP, etc. use an<= /div>
indicator_uid if we needed them marked at this level as well? &nb= sp;Maybe
we want indicator_set at the higher level?  I'd like some op= inions on
this approach.  +1 if you agree, suggestions if you have= other ideas
that may work better.

We'll also need to worry about marking the indicators to prevent
forward sharing when not permitted.  We may want to use thes= e values
or something else.

Thank you!
Kathleen

From: Harrington, Christopher
Sent: Friday, February 01, 2013 12:01 PM
To: Moriarty, Kathleen; MILE IETF
Subject: RE: [mile] IOCs

I think we have a bigger relationship issue to address. Let use the
Watchlist Use Case. A bunch of indicators are sent in one message. In<= /div>
that message we could have groupings of indicators that we need to
show are
related:

Two or more indicators of different type that relate to the same
threat:
       The file hash of a malicious file= and the URL of the C2 that
the file uses. Either or both may be present to indicate a
compromise.

Two or more indicators of the same type that relate to the same
threat:
       2 different registry values for t= he same registry key. If
either value is present it is a compromise indicator but both will
not
be
present.

The problem compounds itself very quickly. Consider the scenario
where
both groupings above are part of the same threat. I need to show that<= /div>
logical groupings of Indicators are related as well. We can't send
multiple IODEF messages for this from what I remember reading.

The last one I can think of would be when you have 2 different
indicators that represent the same indicator. It's not uncommon to
send both the
MD5
and SHA1 hash of a malicious file. The indicator is the file but the
IOCs are the 2 hash values. How do we show they are related? If we
use
a unique Inidcator ID for each hash value there needs to be a higher
level
grouping.

Thoughts?

Thanks,

--Chris

Christopher Harrington
Consulting Security Engineer
GSO - Critical Incident Response Center EMC - Where Information Lives<= /div>
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

Of Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All -

I'd like your input and will refocus the thread to get opinions from
the list on options to help solve the problems raised in my message
and additionally in Paul's message.

Interesting point, C. Henry.  Our objective here is to have = machine
automated exchanges, so we rely on encryption rather than obfuscation<= /div>
to achieve the necessary level of confidentiality.

Paul mentioned the need to distinguish indicators of compromise from
context information that may also include IP address or other data
that could be indicators.  The question I raised was on how = to
connect
sets of indicators in the same IODEF document, assuming the ability
to
have watchlists that could have several sets of indicators included,
as well as to connect indicators that may be included in embedded
schemas.

If we add an attribute on all of the relevant indicators, let's say
'indicator-uid' how do we mark the indicators?  Do we use th= is to
mark
who sent the indicator as well so that we can prevent forward sharing<= /div>
when it is not permitted or handle that separately?

Then for indicators not included in the base schema that may not fit
into a category in the SCI draft, do we create a place for these off
of SCI or right off of the IODE schema in EventData? (more details on<= /div>
this in my first message).

Comments and questions encouraged to figure out the right technical
solution to have this machine automatable.

Thank you,
Kathleen

Of C.
Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

Temporal Dependency sounds interesting.  I remember when I f= irst ran
across this particular craft, an experienced colleague asked me a
peculiar question.  He said, " How do you stop someone = from tracking
the IP Address to your computer?"

I replied, "I don't know, how?"

Then he said, "Cut the dog-gone thing off  and the mode= m that it is
connected- which is constantly on!"   LOL

Here's my point (Hypothetical Situation) :  There is a 1st R= esponder
searching a Neighborhood for Survivors which were hit by a Disaster
or
let's just say "Live" Terrorist Situation.  He /or= She needs to
communication back to other Officials that he /or somehow is in
Danger.  The device used to communicate has been captured by= the
great
minds of the enemy.  It's only a matter of time before they = utilize
reverse engineering to figure out how it functions.  However= , their
pride comes before a fall when seeking the location of other similar
devices to attack.  Why? Perhaps the less thought of concept= s that
makes the device function properly, saves the day by disguise or
cutting it off (figuratively speaking).

Just a visionary thought.

C. Henry Adams
http://biemediagroup.com


The information contained herein is for the exclusive use of the
original recipient. This information is granted for limited
distribution within the recipient's place of business for planning
purposes only. Further dissemination, whether private or public is
prohibited.

From: Dave Misell <david.mi= sell@bcs.org>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with
DNS
SEC a pemanent and temporal key, with a temporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044


On 29 Jan 2013, at 00:39, C. Henry Adams & BIE
wrote:

Serialization of a particular Lists of XML Classes in a unique way
was
closely related to what I attempted to express when I stated,
"consider to a degree what appears to be illogical in brilliant m= inds
in some instances."

However, I see Dr. Stoecker's point a little clearer.  Howev= er, it
would
be nice if the UID was in some way disguised from those who study
this
Security Art Form in a negative way.

C. Henry Adams


The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

Re: [mile] IOCs

Sunday, January 27, 2013 8:52 PM
From:
"Stoecker, Paul" <Paul.Stoecker@rsa.com>
To:
I would like to look at this from a slightly different
perspective=A9let's say I get an XML document that tells me about an
incident.  This document has source IP and destination IP th= at is
being shared.  However, what I don't know is which IP addres= s is my
indicator and which is just a contextual piece of information. &n= bsp;This
means that my detection product isn't going to know which one to use
either, because there is nothing to tell me which IP is the one,
even
if the roles are set it still might not be enough to tell my system
which
one I should use as the indicator.

If we had something like indicator_id as an attribute, it would
allow
us to easily identify indicators from contextual data.  I do= admit
to
being biased as I have spent much of my career working on the
monitoring and detection side of these things, so I am just thinking
of ways to make it very clear what the indicators are in the XML
document and the other data that may be important as I investigate
activity that I have detected off of those indicators.


I did suggest the detection class, but I think we may get more
flexibility with the indicator_uid.  One thing that I haven'= t
considered is the UID portion of this=A9how do we use that UID? &= nbsp;How
is
the UID created?  Are there standards for UIDs?

Regards,

Paul



Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.= stoecker@rsa.com

--- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com>
wrote:

From: C. Henry Adams & BIE <chatlga2000@yahoo.com>
Subject: RE: [mile] IOCs
To: "KathleenMoriarty" <kathleen.moriarty@emc.com>
Date: Saturday, January 26, 2013, 6:17 PM

Greetings Kathleen,

Your logic stimulates my visionary brain because I'm amazed at the
many
avenues you review with this approach at once.  However,&nbs= p; could you
share
a
few advantages and disadvantages to the latter?
--------------------------------------------------------------------
--------
----------------------------------------------
"we could continue to group items in logical places as is done no= w
in
IODEF and then have the extension point for combined indicators via
SCI."
--------------------------------------------------------------------
--------
---------------------------------------------

You pointed out what you consider to be logical places, but if I
wanted to
protect information from parties capable of ascertaining it from your<= /div>
logical places, perhaps we should also consider to a degree what
appears
to
be illogical in brilliant minds in some instances.



C. Henry Adams
chatlga2000@yahoo.com (Di= rect Email)

The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

--- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>
wrote:

From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
Subject: RE: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org"
Date: Saturday, January 26, 2013, 10:13 AM

Hello C. Henry & others,

Thanks for taking a look at this.  We have a few considerati= ons in
this
email thread I would like to hear thoughts on (and there may be more
once
RFC5070-bis is actively edited).

The AdditionalData class and the RecordItem class both allow for
non-XML
extensions.  Where you place the extensions should be specif= ic to the
logical grouping of the parent elements so you can understand more
about
the
included data in most cases.

The Impact class can be used to provide context information on the
included data of the report and also can include a confidence rating
on
the
report as a whole.  Extensions related to impact would be on= e level
higher
(at the moment) in the Assessment class using the AdditionalData
extension
point.

Take asked about including vulnerability information, I would think
that
would fit under the Vulnerability extension point of the SCI draft in<= /div>
the
Method class.  He did ask about non-XML.  RecordIt= em or
AdditionalData
do
allow for non-XML extension points, we could either have the SCI
draft
handle these as well or have the extensions that are non-XML come
directly
off the AdditionalData or RecordItem classes according to what makes
sense
from a logical standpoint.

As for my question, it was two-fold.

Indicator based schemas have a reference number or a GUID for the
various
indicators they share.  If we are extending to embed other s= chemas
that
include such reference or GUID identifiers, do we want to add an
attribute
to the various elements in IODEF that could be indicators?  = Is this
enough
to make the connections or is something else else needed?  W= e could
add
something like an Indicator_ID in RFC5070-bis which would then
correlate
to
the reference or GUID identifiers.

Then the other question was on how to include indicators that are
not
in
the base schema that may be related or have language with "and&qu= ot; "or"
to
specify the relationships.  In some cases, you will want to = group
these
indictors in one extension point, where they may fit logically in
multiple
places if the relationships did not need to be shown in the data
format.  If
we have cases like this where you need more complex representations,
should
we use one extension point via the SCI draft off of the EventData
class
AdditionalData extension point?  Opinions are needed here...= .

A few people have mentioned wanting to include some commonly shared
indictors into the base IODEF document.  We could have a cat= ch-all
class
that does this and has an extension point off of it in EventData or
we
could
continue to group items in logical places as is done now in IODEF and<= /div>
then
have the extension point for combined indicators via SCI.  I= think I
like
the latter approach.

Thank you,
Kathleen
________________________________________
Henry
Sent: Saturday, January 26, 2013 3:05 AM
Cc: C. Henry Adams
Subject: Re: [mile] IOCs

Greetings Everyone,

Take mentioned two types of indicators based on the :
--------------------------------------------------------------------
--------
--------------------------
1) If the indicators are something like an XML-based alert/warning
of
information leakage, it could be an event that are conveyed in the
SCI's EventReport class, IMHO.

2) If the indicators are something like an non-XML ones, I guess it
could
be
conveyed without using SCI draft.
For instance, we could use Impact class of the base IODEF to convey
the indicators.
We could for instance extend the list of indicators of the Impact
class,
if
needed.
--------------------------------------------------------------------
--------
--------------------------

In doing so he pointed out the "Impact Class"

Whereas, Kathleen stated,
--------------------------------------------------------------------
--------
-------------------------
For the discussion below, I was thinking more of combined set with
relationships that may be included in a single extension point, so
that's
why I was thinking about the EventData class, but there may be better<= /div>
locations or a specific area within the EventData.

Paul Stoecker had suggested a "Detection" class as a conside= ration.
--------------------------------------------------------------------
--------
------------------------

Kathleen thoughts related yet still with other indicators and the
EventData Class.

Is there a possible way to create a new XML class which encompass
combining the EventData, Detection and base IODEF classes to simplify<= /div>
this
issue?


C. Henry Adams
chatlga2000@yahoo.com (Di= rect Email)


The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.
_______________________________________________
mile mailing list

_______________________________________________
mile mailing list

_______________________________________________
mile mailing list


_______________________________________________
mile mailing list

_______________________________________________
mile mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF14CC18MIVEXAMER1N1corpn_-- From chatlga2000@yahoo.com Wed Feb 13 07:24:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3721F888E for ; Wed, 13 Feb 2013 07:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.721 X-Spam-Level: * X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8i-aSbVSGpj for ; Wed, 13 Feb 2013 07:24:15 -0800 (PST) Received: from nm23-vm1.bullet.mail.ne1.yahoo.com (nm23-vm1.bullet.mail.ne1.yahoo.com [98.138.91.50]) by ietfa.amsl.com (Postfix) with ESMTP id 107BF21F8873 for ; Wed, 13 Feb 2013 07:24:15 -0800 (PST) Received: from [98.138.90.57] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 15:24:08 -0000 Received: from [98.138.89.248] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 15:24:08 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 13 Feb 2013 15:24:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 521474.19124.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 31355 invoked by uid 60001); 13 Feb 2013 15:24:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360769048; bh=/WumMyejvKt20Pe5bkK6OmUuyFDLy8+qum6MS2WLCBM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=YoQF5Jbn+JA4zP4WNyIJpG8ARLzpW3cjXSGtSCsPG1n+yHnAb/P8Bdfu8KgQnKBsJRG75XQBaGq62nPTxXs3bOZ95B3uO82Mkjwp3dIe6sBheQrP2WF0FBzg6xSq+puhuFnOGAS4kINeHk+EeOkM2XEpxqe5z5EKOb8hmAVWmUQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=O/R6KdY+O6t0FSqH0haBc6mDAX/z/QK3H1NeFq/FGl5TyAN7hJEuQV/z9omHiOS8d0WUswMpicBBk2OieS69Gd1xZmXzmJJaIza1VU2gZ7BrUL5hx5AwHn7g2O1TFKaZRelU0T/p/FxjclYYF7rUEbuacuVSJb7PiczvFY5ZCOg=; X-YMail-OSG: UyQ8PEIVM1nQnJhx5TpfevLKrtdJZJXAsknyxaIhLgvsgVe S.yi.r1VblpgK6yX9F998VQC33VaHf1miufFbeH5tP4FV3coN43mNEArdDrH MURw7amTD3MrVpHEpbSBbKqx5YNv8eoWvT23riWRudy7QVWSG_zRcxr5TPJN nAMW.sKI4A1FmXt4sK6eUraJxUAT07yKTDM1AsZUByZD0qwSLgbpLT.2gyq6 GmYC9CKjPFX_qBekJv_Xdj9_TJ6H8VSGyIKFJUyOl8r1Sx5wCFWtQPqdiY7S kWwuEFEtDGfmgbY3YFZPhn6E0pZ8_wb5wzQ0nhovL2th5LxUGYH89vjp7QSH YvyjrWnbyNQP4UQia76i6dN2KDBMS8b6GE_MmbN9EdU7GJ2icWnH7JD_frfk 6.cP_mfjXCWzWr0e.4s.SydTWUO3.GgIXiMdPzfn03FwCWcarMd_eO_J43IX GLs8LYUSE6eWi8KBOI4AqqVa9iQcE57aGT5UkiCZu7Yo_NDMezNwRth71.fi fo1b6Y7Map8eOrN1KCdGkHEfzOFXp7mZXyvDbZ61schQp_SqaqjEhCioyjA- - Received: from [71.22.243.36] by web121606.mail.ne1.yahoo.com via HTTP; Wed, 13 Feb 2013 07:24:08 PST X-Rocket-MIMEInfo: 001.001, CgogCgoKCgpBZ2FpbiwgSSB3b3VsZCBjb25jdXIgdGhhdCBib3RoIGEgbnVtZXJpYyBhbmQgc3ViamVjdGl2ZSBhbmFseXNpcyBvZiB0aGUgQ29uZmlkZW5jZSBSYXRpbmcgbmVlZHMgdG8gYmUgZXhwcmVzcywgYnV0IGNvbWJpbmVkIGluIGEgc2ltcGxpZmllZCBzY2hlbWEgYXMgc3VjaCBiZWxvdzoNCg0KPENvbmZpZGVuY2UgcmF0aW5nPSIgQWxwaGFudW1lcmljIj4xTEw8Lz4gLi4uLiBldGMuDQoNCjxDb25maWRlbmNlIHJhdGluZz0iIEFscGhhbnVtZXJpYyI.MlA8Lz4NCg0KPENvbmZpZGVuY2UgcmF0aW4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.133.508 Message-ID: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Wed, 13 Feb 2013 07:24:08 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-941635131-1360769048=:12028" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:24:24 -0000 --1458340343-941635131-1360769048=:12028 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A =0A=0A=0A=0A=0AAgain, I would concur that both a numeric and subject= ive analysis of the Confidence Rating needs to be express, but combined in = a simplified schema as such below: 1LL .... etc. 2P 3AC 4U 5I ( i.e.=C2=A0=C2=A01 =3D Less Likely,=C2=A0=C2=A0 2 =3D Probable,=C2=A0=C2= =A03 =3D A Concern,=C2=A0=C2=A04 =3D=C2=A0=C2=A0Urgent, 5 =3D Imminent ) Here's my point, perhaps a set of numeric related or associated definitions= can lower the propagation of error regarding the analysis.=C2=A0=C2=A0=20 Thanks, C. Henry Adams I agree that what we really need is both. =C2=A0In most situations a =0Alow= , medium and high may be acceptable but there are times when we will =0Awan= t to show that confidence in a situation is increasing or decreasing.=0A = =C2=A0If we are only looking at a three levels,=0A we cannot express what i= s needed to show confidence is trending up on =0Athe data being exchanged a= bout the event.=0A =0A=0AKathleen included the following in a previous message.=0A =0A=0A=0A=0A =0A=0AVs:=0A =0A=0A85=0A=0A =0A=0AI really think we need to include both capabilities as John alluded= =0A to since confidence is not a three tiered item but something that is = =0Aindeed subjective and we need a means to show a reasonably accurate =0Ac= onfidence index that the sender is trying to convey.=0A =0A=0AKent Landfield =0A =0AMcAfee | An Intel Company =0ADirect: +1.972.963.7096=C2=A0 =0AMobile: +1.817.637.8026 =0AWeb:=C2=A0www.mcafee.com=0A=0A=0A =0A=0A=0A=0AFrom: , John Banghart =0ADate: Wednesday, February 13, 2013 7:16 AM =0ATo: "Stoecker, Paul" , Kathleen Moriarty , Brian Trammell =0ACc: "C. Henry Adams & BIE" , MILE IETF =0ASubject: Re: [mile] IOCs =0A=0A =0A=0A=0A=0A=0APaul,=0A =0A=0AI agree that confidence is subjective, but subjectivity can be reduce= d=0Awithin communities that interact frequently.=C2=A0=C2=A0Prioritization = of indicators=0Aand response between tightly connected sharing partners mig= ht require a=0Amore specific level of detail, particularly during a crisis = situation.=0A =0A=0AFrom that perspective, I think the guidance should allow for addition= al=0Agranularity, while stressing the "high, medium, low" as preferred for= =0Abroad interoperability.=0A =0A=0A-John=0A =0A=0AOn 2/13/13 8:04 AM, "Stoecker, Paul" wrote:= =0A =0A=0A=0AI may have been too succinct in my response ;-)=0A =0A=0AConfidence is a subjective thing, so I think we should use subjective= =0Aterms:=C2=A0=C2=A0Low, Medium, High.=C2=A0=C2=A0Having a numeric scale w= ith a map that=0Aessentially would say something like:=0A =0A=0A1-33 =3D Low=0A34-67=3D Medium=0A68-100=3DHigh=0A =0A=0AIs just a more complicated way of saying that something is Low, Mediu= m,=0AHigh...do we really thing that how High something is makes that much o= f a=0Adifference?=0A =0A=0AThis is like when you get your Performance review where it is Does No= t=0AMeet, Meets and Exceeds...your boss tells you that you are a High=0AMee= ts...your=0Abonus tells you that you got the same bonus that all the other = Meets got=0A;-)=0A =0A=0AAnyway, I digress but trying to prove a point that I would argue that= =0Aconfidence in this case is going to be basically a gut feeling, so why u= se=0Anumeric values when Low, Medium, High would do just fine.=0A =0A=0A =0A=0APaul W. Stoecker, Ph.D.=0ASMC Lead Content Architect=0ARSA, The Secur= ity Division of EMC=0Acell: 302.379.3375 | e: paul.stoecker@rsa.com=0A =0A=0A =0A=0A =0A=0A =0A=0A =0A=0A =0A=0AOn 2/13/13 7:48 AM, "Moriarty, Kathleen" = =0Awrote:=0A =0A=0A=0AHello,=0A =0A=0ABoth approaches will validate in the current schema.=C2=A0=C2=A0The r= epresentation=0Alooks a little different for each, here is an example:=0A =0A=0A=0A =0A=0AVs:=0A =0A=0A85=0A =0A=0ASearching capability is a great point, agreed.=C2=A0=C2=A0I'd like to= hear from=0Amore people to make sure we don't lose a capability that other= s find=0Aextremely useful (need to gauge that).=C2=A0=C2=A0Other options is= that the=0Aguidance can also discourage the use of the numeric in addition= to=0Aspecifying how to select ranges.=0A =0A=0AAny other opinions?=0A =0A=0AThanks,=0AKathleen=0A =0A=0A-----Original Message-----=0AFrom: Stoecker, Paul=0ASent: Wednesday, = February 13, 2013 7:14 AM=0ATo: Brian Trammell=0ACc: Moriarty, Kathleen; C.= Henry Adams & BIE; MILE IETF=0ASubject: Re: [mile] IOCs=0A =0A=0ACant we make Confidence a List that has only 3 values:=C2=A0=C2=A0Hig= h, Medium, and=0ALow?=C2=A0=C2=A0Any other value means that the Document wi= ll mot validate against=0Athe schema.=0A =0A=0ASent from my iPhone=0A =0A=0AOn Feb 13, 2013, at 2:14 AM, "Brian Trammell" =0Awrote:=0A =0A=0A=0AHi, Kathleen, all,=0A =0A=0AI think 3.10.4 in 5070 takes the right approach here: trying to build= =0Ainteroperable numeric scales for assessment is a very hard problem.=0A(W= ere I charged with defining such a scale, the value "70" would mean=0A"we c= ompared this incident report to N past similar incident reports=0Aaccording= to similarity algorithm S, and 70% of the past reports had=0Aassessed impa= cts within E% of the actual, measured final impact -- I=0Athink for most ap= plications this is vastly more difficult and rigorous=0Athan it needs to be= .)=0A =0A=0AUnless a numeric Confidence value is based on some actual, repeatably= =0Ameasurable aspect of the Assessment report -- which I suspect in=0Amany/= most/all cases it's not -- then it just represents a guess, however=0Aeduca= ted.=C2=A0=C2=A0Each team will probably naturally tune its own scales such= =0Athat each value generally means the same thing in each report. Across=0A= teams, I don't know.=0A =0A=0AOn the other hand, Assessments are by their very nature educated=0Agu= esses, anyway, so I don't know that I'd find much use in automating a=0Ares= ponse based on the assessment confidence. Chris has a good point,=0Athough = -- it makes searching difficult and sorting kind of pointless.=0A =0A=0AIf we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I= =0Aagree, we should put that in the guidance document (along with a note=0A= that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high,=0Aun= less we want to do it non-linearly). If the _vast_majority_ of the=0Ausers = of this field use a 100-point scale with 100 meaning "yes" and 0=0Ameaning = "any resemblance these values may have to actual fact is purely=0Acoinciden= tal", then let's consider renaming it "percent" in 5070-bis.=0A =0A=0ABest regards,=0A =0A=0ABrian (as contributor)=0A =0A=0A =0A=0AOn Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"=0A wrote:=0A =0A=0A=0APlease see section 3.10.4 of RFC5070 as a starting point.=C2=A0=C2= =A0We can=0Achange it if it needs to be changed.=C2=A0=C2=A0The value is fo= r a confidence=0Arating on the indicators shared.=C2=A0=C2=A0The definition= s may be helpful for=0Aanyone who wants to work on this discussion.=C2=A0= =C2=A0IODEF has various markers=0Athat can be used in a complimentary way w= ithout conflating the markers=0Ameaning.=0A =0A=0AI think some people using IODEF find the numerical values more=0Ahelp= ful, and it would be good to understand what people have learned=0Afrom usi= ng the current structure (what works/does not work).=C2=A0=C2=A0The=0Ascale= s I have seen are 0-100.=C2=A0=C2=A0There is of course a subjective element= =0Ato assigning a numerical value to the confidence and it may vary from=0A= entity to entity.=C2=A0=C2=A0With this type of rating you may need to consi= der=0Awho it came from and how they scored the confidence rating to map to= =0Ayour own rating.=C2=A0=C2=A0It would be good to hear more thoughts on th= is.=0A =0A=0AThanks,=0AKathleen=0A =0A=0AFrom: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]=0ASent: Tue= sday, February 12, 2013 2:46 PM=0ATo: MILE IETF=0ACc: Moriarty, Kathleen; '= Takeshi Takahashi'; Stoecker, Paul=0ASubject: Re: [mile] IOCs=0A =0A=0A =0A=0ARegarding the IOCs or Indicators of Compromise, Chris made a vital=0A= point.=C2=A0=C2=A0Different Confidence levels will cause confusion.=C2=A0= =C2=A0It appears=0Athat there maybe a need for some type of simplified stan= dardization to=0Abe established between all Sharing Groups in this regard.= =0A =0A=0APerhaps numerical scoring set at lower values should express levels o= f=0Aurgency.=0A( i.e.=C2=A0=C2=A01 =3D Less Likely,=C2=A0=C2=A0 2 =3D Proba= ble,=C2=A0=C2=A03 =3D A Concern,=C2=A0=C2=A04 =3D=C2=A0=C2=A0Urgent,=0A5 = =3D Imminent )=0A =0A=0AThanks,=0AC. Henry Adams=0A =0A=0A =0A=0A =0A=0AI see some confusion coming down the pike if we start using Confidenc= e=0Athe=0Away it is supported. If I am using low/med/high and someone sends= me=0Aan IoC=0Awith a score of 70, what does that mean to me? What if I am = using a=0Ascale of=0A1 to 4 and someone else is on a scale of 1 to 5? We lo= se the ability=0Ato=0Adescribe something with a consistent language. It rea= lly gets ugly=0Awhen we=0Astore IoC from multiple sources. I have confidenc= e values that are=0Anumeric=0Aas well as text.=C2=A0=C2=A0Makes searching /= sorting very problematic.=0A =0A=0AAt this point we have to roll with what we have. I would strongly=0Ar= ecommend=0Athat we revisit this at some point.=0A =0A=0AThanks,=0A =0A=0A--Chris=0A =0A=0A-----Original Message-----=0AFrom: Moriarty, Kathleen=0ASent: Tuesday= , February 12, 2013 9:59 AM=0ATo: Harrington, Christopher; 'Takeshi Takahas= hi'; Stoecker, Paul;=0A'MILE=0AIETF'=0ASubject: RE: [mile] IOCs=0A =0A=0AHi Chris & Take,=0A =0A=0AI'll just focus on the confidence scoring.=C2=A0=C2=A0Right now, the = schema=0Aallows for=0Ayou to either use a numerical score OR the ratings of= low, medium, and=0Ahigh.=0ADifferent sharing groups can decide how they wa= nt to share the data.=0AIf=0Apeople were to use the numerical values, I agr= ee it would be helpful=0Ato have=0Aguidance.=C2=A0=C2=A0This could go in th= e IODE guidance document.=0A =0A=0AI have seen examples of current users that use each of the approaches= ,=0Aso=0Awe'll need to keep the option for backwards compatibility and it i= s=0Anice to=0Akeep in flexible options where we can.=0A =0A=0AThank you,=0AKathleen=0A =0A=0A-----Original Message-----=0AFrom: Harrington, Christopher=0ASent: Tu= esday, February 12, 2013 9:22 AM=0ATo: 'Takeshi Takahashi'; Moriarty, Kathl= een; Stoecker, Paul; 'MILE=0AIETF'=0ASubject: RE: [mile] IOCs=0A =0A=0AThe number of indicators wouldn't necessarily drive the use of=0Aindi= cator_set_id. The purpose is to show relationship. If I sent 3 IP=0Aaddress= es that were used as C2 for 3 different campaigns I would have=0Aseparate i= ndicator_set_ids, each with one of the 3 C2 IPs=0A =0A=0AMy suggestion would be a simple low, medium, high. I think if we brea= k=0Ait=0Adown to more levels than that we would need to provide guidance on= =0Ascoring,=0Arating, etc. I think most people should be able to understand= =0Alow/med/high=0Awithout having to have a mathematical method for arriving= at the=0Alevel.=0A =0A=0ALow - I am not sure=0AMedium - I am reasonably sure=0AHigh - I am ver= y sure=0A =0A=0A =0A=0AThanks,=0A =0A=0A--Chris=0A =0A=0A-----Original Message-----=0AFrom: Takeshi Takahashi [mailto:takeshi_= takahashi@nict.go.jp]=0ASent: Tuesday, February 12, 2013 4:21 AM=0ATo: Harr= ington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE=0AIETF'=0ASu= bject: RE: [mile] IOCs=0A =0A=0ARegarding the indicator_set_id, I agree, it is useful when we need to= =0Adeal=0Awith large sets of indicators.=0ASince indicator_set_id attribute= is optional (right?), it could be=0Aomitted=0Aif we need to deal with only= small number of indicators.=0A =0A=0ARegarding the use case, I like the idea of using the confidence=0Aatt= ribute=0Afor the reason Chris kindly described.=0AI would like to hear a bi= t more on this: is it going to be numerical?=0AFor=0Ainstance, 1 means "no = confidence" while 5 means "strong confidence",=0Aetc?=0A =0A=0AThank you.=0ATake=0A =0A=0A =0A=0A=0A-----Original Message-----=0AFrom: Harrington, Christopher [mailto= :Christopher.Harrington@emc.com]=0ASent: Friday, February 08, 2013 4:11 AM= =0ATo: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE=0AIETF'= =0ASubject: RE: [mile] IOCs=0A =0A=0AWith respect to tying things back to threat actors, from what I have= =0Aseen and use this is a generally accepted grouping:=0A =0A=0AIndicator --> Indictor Set --> Campaign --> Threat Actor=0A =0A=0ACampaign and Threat Actor are where having a "Confidence" attribute= =0Awould be beneficial as making those associations is not a perfect=0Ascie= nce by any means.=0A =0A=0AThanks,=0A =0A=0A--Chris=0A =0A=0A =0A=0A-----Original Message-----=0AFrom: Moriarty, Kathleen=0ASent: Thursda= y, February 07, 2013 2:00 PM=0ATo: Takeshi Takahashi; Harrington, Christoph= er; Stoecker, Paul; 'MILE=0AIETF'=0ASubject: RE: [mile] IOCs=0A =0A=0AHi Take & others,=0A =0A=0AThanks for chiming in, I've been talking about this with Chris and a= =0Afew others on their use cases and would like more opinions.=C2=A0=C2=A0I= 'll=0Aprovide an option below from what we have discussed from a CIRC view= =0Apoint.=C2=A0=C2=A0We are also wondering how to also provide logic in IOD= EF that=0Acould cross over into SCI attached schemas or IODEF extensions (t= he=0Asolutions may all tie together with this discussion - or there may be= =0Abetter/more elegant solutions others would like to propose).=0A =0A=0A-----Original Message-----=0AFrom: Takeshi Takahashi [mailto:takeshi_= takahashi@nict.go.jp]=0ASent: Tuesday, February 05, 2013 12:04 PM=0ATo: Har= rington, Christopher; Stoecker, Paul; Moriarty, Kathleen;=0A'MILE=0AIETF'= =0ASubject: RE: [mile] IOCs=0A =0A=0A=0AI like this discussion.=0AI agree, it would be good idea to have i= ndicator identifiers inside=0Athe IOC-related classes.=0A=0A =0A=0AKMM: At the class level, we may have several indicators listed that= =0Ashould be viewed as a set and may have another instance of that same=0Ac= lass that is a related issue, but a separate set.=C2=A0=C2=A0We could as yo= u=0Asay, list the indicator IDs connected through the reference class.=0ATh= e set IDs might give us other ways to group the values when we get=0Ainto l= ogic and relationships between sets or indicators.=C2=A0=C2=A0This could=0A= also be a way to connect indicators or sets across XML documents that=0Acou= ld have been shared previously.=C2=A0=C2=A0If there are a large number of= =0Aindicators in the set, then this becomes useful, for smaller sets, I=0Aa= gree it doesn't make as much sense.=0A =0A=0AWhat do others think?=0A =0A=0A=0A=0AThen for indicators not included in the base schema that may no= t=0Afit into a category in the SCI draft, do we create a place for=0Athese = off of SCI or right off of the IODE schema in EventData?=0A(more details=0A= =0A=0Aon=0A=0A=0Athis in my first message).=0A=0A =0A=0AIf we could see any indicator of compromise as computer event=0Arecor= d, we could use SCI:EventReport class as the place for the=0AXML-based IOCs= that couldn't fit anywhere else.=0A=0A =0A=0AKMM: That sounds like a good idea to me.=C2=A0=C2=A0This should go in= to=0Aguidance=0Ain the SCI draft.=C2=A0=C2=A0Does anyone else want to weigh= in?=0A =0A=0A=0A =0A=0AFor the non-XML IOCs, we could use RecordData class, as suggested.=0A= =0AKMM: Sounds good, thanks!=0A =0A=0A=0AI agree to have indicator_uid, but I am not sure about the needs o= f=0Athe indicator_set_id.=0AI understand we could do some grouping of indiv= idual indicator_uids=0Aand its usability, but I am not sure whether we do n= ot have any=0Aother way to express these groupings.=0AFor instance,=C2=A0= =C2=A0a Reference class refers to several indicadtor_uids.=0A=0AIn=0A=0Athi= s case, they could be, in a sense, grouped. Isn't it enough?=0A=0A =0A=0AKMM: It may be, what do you think about large sets of indicators or= =0Asubsequent messages that add indicators to existing sets?=C2=A0=C2=A0Wou= ld this=0Ahappen?=C2=A0=C2=A0Would it be easier to express relationships wi= th sets of=0Aindicators in addition to individual indicators?=C2=A0=C2=A0By= using this, it=0Acould give us a unique way to also provide the logic and= =0Arelationships=0Ain a new class of IODEF so we don't have to worry about = adding it=0Ainto=0Athe current=0A=0Astructure.=0A=0AIf there are better way= s to handle that, and others can provide some=0Aoptions, that would be appr= eciated!=0A =0A=0AThank you,=0AKathleen=0A =0A=0A=0AI would appreciate if anybody could share expertise on this. Thoug= h=0A=0AI=0A=0Athink I have read all the emails in the list, I might have=0A= mis-understood some points.=0A =0A=0ABy the way, I think the indicator_uids should be added to the SCI=0A= =0A=0Aclasses'=0A=0A=0Aattributes so that they can be correlated with anoth= er information=0Aas=0A=0Awell.=0A=0A =0A=0AThanks=0ATake=0A=0A =0A=0A =0A=0A =0A=0AFrom: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf= =0AOf Harrington, Christopher=0ASent: Tuesday, February 05, 2013 4:25 AM=0A= To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF=0ASubject: Re: [mile] IOC= s=0A =0A=0AI think some sort of group ID would do the trick. We also need a=0Alo= gical and / or somewhere to show relationship between indicators.=0AIf=0AI = give you=0A2=0Aregistry keys do they both have to be present to be an indic= ation of=0Acompromise or is either one by themselves an indicator? Both wou= ld=0Ahave the same group ID since they are related.=0A =0A=0AThanks,=0A--Chris=0A =0A=0AFrom: Stoecker, Paul=0ASent: Sunday, February 03, 2013 8:26 PM=0ATo: = Moriarty, Kathleen; Harrington, Christopher; MILE IETF=0ASubject: Re: [mile= ] IOCs=0A =0A=0AWhat if we added indicator group ID along with the indicator_uid?=0AT= his would allow you to group indicators that are related into the=0Asame gr= oup ID.=0AWould this resolve the issue?=0A =0A=0AIt is either that or going back to adding a Detection (or Indicators)= =0Aclass that will should be used to take all of the indicators put them=0A= into one place and have the ability to group the ones that go=0Atogether.= =C2=A0=C2=A0I don't mean a place to put indicators that are missing=0Afrom = IODEF.I mean a place in the IODEF document where you put the=0Aindicators t= hat are used for detection and prevention of the shared=0AIncident.=C2=A0= =C2=A0I don't know the answer here, but there has got to be a=0Agood way fo= r indicators to be identified and being able to group them=0Aas Chris has s= uggested without basically recreating something=0Acomplicated like STIX.=0A =0A=0APaul=0A =0A=0A =0A=0APaul W. Stoecker, Ph.D.=0ASMC Lead Content Architect=0ARSA, The Secur= ity Division of EMC=0Acell: 302.379.3375 | e: paul.stoecker@rsa.com=0A =0A=0A =0A=0AFrom: , Kathleen =0ADate: Sunday= , February 3, 2013 5:11 PM=0ATo: "Harrington, Christopher" , MILE=0AIETF =0ASubject: Re: [mile] IOCs=0A =0A=0AHi Chris,=0A =0A=0AI agree, we have some work to do in the updated IODEF, RFC5070-bis.= =0A =0A=0AThe list has already said they would like to see indicators added to= =0Athe definitions in RFC5070-bis, to be more explicit about including=0Ain= dicators and sets of indicators in IODE documents as opposed to=0A'parts of= an incident or the useful information on an incident for=0Asharing purpose= s.=C2=A0=C2=A0It was written before we used terms like=0Aindicators.=C2=A0= =C2=A0With that in mind, Rosella proposed a number of changes=0Aback in Jul= y, both for guidance and for=0A=0Aformat=0A=0Aupdates.=C2=A0=C2=A0It may he= lp to have the first draft try to address at least=0Asome of these issues s= o people can understand the problems and at=0Aleast a proposed solution.=0A =0A=0AAs you point out, we need to be able to show relationships between=0A= sets of indicators, where we may have a few sets of indicators that=0Acould= have a relationship to each other within a document.=C2=A0=C2=A0In the=0AJ= uly presentation, one of the questions was to see if we should add=0Anew ca= tegory attribute values for the System class that would connect=0Athe list = of included indicators.=C2=A0=C2=A0I think we should still keep the=0Aconce= pt of a Node to a single node, but perhaps within System, list=0Amultiple s= ets of Nodes that may be one type of attack.=C2=A0=C2=A0Rosella had=0Asugge= sted pulling forward the "FraudType" from RFC5901, this would=0Ahelp solve = the issue as NodeRole values would compliment an=0AAttackType=0A(FraudType = values could be included in AttackType or some broader=0Aterm).=C2=A0=C2=A0= It may be better to have the FraudTypes, plus attribute=0Avalues=0Alike "C2= -server", "sinkhole",=C2=A0=C2=A0"MalwareDistribution" for added=0Acontext= =0Aso you know what to do with the received set of indicators.=0A =0A=0AI am proposing that we change IODEF to include multiple sets of=0A=0A= indicators,=0A=0Aadd an AttackType attribute (or some other name), a method= to connect=0Aindicators and indicator sets within an IODEF using an attrib= ute of=0Aindicator_uid (or some other name) with a string value to make the= =0Aconnection points, and add a few indicators that are commonly shared=0Ai= nto the base IODEF.=0A =0A=0ABack in July, we talked about adding Registry Key/Value pairs and=0Ah= ashes to the main IODEF document (trying to see if this will help=0AChris b= elow).=C2=A0=C2=A0What if we added the Registry Key/Value pairs as a=0Aclas= s off of RecordData, using a similar structure to what is in=0ARFC5901, and= also added the ability to include hashes in RecordData?=0AI think if we th= en had the indicator_uid at the RecordData level, we=0Acould connect a set = within that structure and repeat the structure=0Afor=0Aother sets in the sa= me way we would do with Node inside of the System=0Aclass, using the indica= tor_uid to tie the set together.=C2=A0=C2=A0Then at the=0Amore specific lev= el for the hash, registry Key/value, IP, etc. use an=0Aindicator_uid if we = needed them marked at this level as well?=C2=A0=C2=A0Maybe=0Awe want indica= tor_set at the higher level?=C2=A0=C2=A0I'd like some opinions on=0Athis ap= proach.=C2=A0=C2=A0+1 if you agree, suggestions if you have other ideas=0At= hat may work better.=0A =0A=0AWe'll also need to worry about marking the indicators to prevent=0Afo= rward sharing when not permitted.=C2=A0=C2=A0We may want to use these value= s=0Aor something else.=0A =0A=0AThank you!=0AKathleen=0A =0A=0AFrom: Harrington, Christopher=0ASent: Friday, February 01, 2013 12:01= PM=0ATo: Moriarty, Kathleen; MILE IETF=0ASubject: RE: [mile] IOCs=0A =0A=0AI think we have a bigger relationship issue to address. Let use the= =0AWatchlist Use Case. A bunch of indicators are sent in one message. In=0A= that message we could have groupings of indicators that we need to=0Ashow a= re=0Arelated:=0A =0A=0ATwo or more indicators of different type that relate to the same=0Ath= reat:=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The file hash of a malicious f= ile and the URL of the C2 that=0Athe file uses. Either or both may be prese= nt to indicate a=0Acompromise.=0A =0A=0ATwo or more indicators of the same type that relate to the same=0Athr= eat:=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 different registry values for= the same registry key. If=0Aeither value is present it is a compromise ind= icator but both will=0Anot=0Abe=0A=0Apresent.=0A=0A =0A=0AThe problem compounds itself very quickly. Consider the scenario=0Awh= ere=0Aboth groupings above are part of the same threat. I need to show that= =0Alogical groupings of Indicators are related as well. We can't send=0Amul= tiple IODEF messages for this from what I remember reading.=0A =0A=0AThe last one I can think of would be when you have 2 different=0Aindi= cators that represent the same indicator. It's not uncommon to=0Asend both = the=0AMD5=0Aand SHA1 hash of a malicious file. The indicator is the file bu= t the=0AIOCs are the 2 hash values. How do we show they are related? If we= =0Ause=0Aa unique Inidcator ID for each hash value there needs to be a high= er=0Alevel=0A=0Agrouping.=0A=0A =0A=0AThoughts?=0A =0A=0AThanks,=0A =0A=0A--Chris=0A =0A=0AChristopher Harrington=0AConsulting Security Engineer=0AGSO - Critica= l Incident Response Center EMC - Where Information Lives=0A174 Middlesex Tu= rnpike=0ABedford, MA 01730=0A781-515-5862 (work)=0A603-583-1585 (cell)=0A =0A=0AFrom: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf= =0AOf Moriarty, Kathleen=0ASent: Friday, February 01, 2013 11:28 AM=0ATo: M= ILE IETF=0ASubject: Re: [mile] IOCs=0A =0A=0AAll -=0A =0A=0AI'd like your input and will refocus the thread to get opinions from= =0Athe list on options to help solve the problems raised in my message=0Aan= d additionally in Paul's message.=0A =0A=0AInteresting point, C. Henry.=C2=A0=C2=A0Our objective here is to have= machine=0Aautomated exchanges, so we rely on encryption rather than obfusc= ation=0Ato achieve the necessary level of confidentiality.=0A =0A=0APaul mentioned the need to distinguish indicators of compromise from= =0Acontext information that may also include IP address or other data=0Atha= t could be indicators.=C2=A0=C2=A0The question I raised was on how to=0Acon= nect=0Asets of indicators in the same IODEF document, assuming the ability= =0Ato=0Ahave watchlists that could have several sets of indicators included= ,=0Aas well as to connect indicators that may be included in embedded=0Asch= emas.=0A =0A=0AIf we add an attribute on all of the relevant indicators, let's say= =0A'indicator-uid' how do we mark the indicators?=C2=A0=C2=A0Do we use this= to=0Amark=0Awho sent the indicator as well so that we can prevent forward = sharing=0Awhen it is not permitted or handle that separately?=0A =0A=0AThen for indicators not included in the base schema that may not fit= =0Ainto a category in the SCI draft, do we create a place for these off=0Ao= f SCI or right off of the IODE schema in EventData? (more details on=0Athis= in my first message).=0A =0A=0AComments and questions encouraged to figure out the right technical= =0Asolution to have this machine automatable.=0A =0A=0AThank you,=0AKathleen=0A =0A=0AFrom: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf= =0AOf C.=0AHenry Adams & BIE=0ASent: Monday, January 28, 2013 11:25 PM=0ATo= : MILE IETF=0ASubject: Re: [mile] IOCs=0A =0A=0ATemporal Dependency sounds interesting.=C2=A0=C2=A0I remember when I = first ran=0Aacross this particular craft, an experienced colleague asked me= a=0Apeculiar question.=C2=A0=C2=A0He said, " How do you stop someone from = tracking=0Athe IP Address to your computer?"=0A =0A=0AI replied, "I don't know, how?"=0A =0A=0AThen he said, "Cut the dog-gone thing off=C2=A0=C2=A0and the modem th= at it is=0Aconnected- which is constantly on!"=C2=A0=C2=A0 LOL=0A =0A=0AHere's my point (Hypothetical Situation) :=C2=A0=C2=A0There is a 1st = Responder=0Asearching a Neighborhood for Survivors which were hit by a Disa= ster=0Aor=0Alet's just say "Live" Terrorist Situation.=C2=A0=C2=A0He /or Sh= e needs to=0Acommunication back to other Officials that he /or somehow is i= n=0ADanger.=C2=A0=C2=A0The device used to communicate has been captured by = the=0Agreat=0Aminds of the enemy.=C2=A0=C2=A0It's only a matter of time bef= ore they utilize=0Areverse engineering to figure out how it functions.=C2= =A0=C2=A0However, their=0Apride comes before a fall when seeking the locati= on of other similar=0Adevices to attack.=C2=A0=C2=A0Why? Perhaps the less t= hought of concepts that=0Amakes the device function properly, saves the day= by disguise or=0Acutting it off (figuratively speaking).=0A =0A=0AJust a visionary thought.=0A =0A=0AC. Henry Adams=0Achenryadams@biemediagroup.com=0Ahttp://biemediagroup= .com=0A =0A=0A =0A=0AThe information contained herein is for the exclusive use of the=0Aor= iginal recipient. This information is granted for limited=0Adistribution wi= thin the recipient's place of business for planning=0Apurposes only. Furthe= r dissemination, whether private or public is=0Aprohibited.=0A =0A=0A--- On Mon, 1/28/13, Dave Misell wrote:=0A =0A=0AFrom: Dave Misell =0ASubject: Re: [mile] IOCs= =0ATo: "C. Henry Adams & BIE" =0ADate: Monday, Janua= ry 28, 2013, 9:25 PM UID could be mirrored with=0ADNS=0ASEC a pemanent and = temporal key, with a temporal Id?=0A =0A=0AYours Faithfully,=0A =0A=0ADave Misell MSc CISSP=0ASilentCircle=C2=A0=C2=A0dsm=0A07710 380044=0A= david.misell@bcs.org=0A =0A=0A =0A=0AOn 29 Jan 2013, at 00:39, C. Henry Adams & BIE=0A=0Awrote:=0A =0A=0A=0ASerialization of a particular Lists of XML Classes in a unique way= =0Awas=0A=0Aclosely related to what I attempted to express when I stated,= =0A"consider to a degree what appears to be illogical in brilliant minds=0A= in some instances."=0A=0A =0A=0AHowever, I see Dr. Stoecker's point a little clearer.=C2=A0=C2=A0Howe= ver, it=0Awould=0A=0Abe nice if the UID was in some way disguised from thos= e who study=0Athis=0ASecurity Art Form in a negative way.=0A=0A =0A=0AC. Henry Adams=0Achatlga2000@yahoo.com (Direct Email)=0Achenryadams@b= iemediagroup.com=0A =0A=0A =0A=0AThe information contained herein is for the exclusive use of the=0Aor= iginal=0A=0Arecipient. This information is granted for limited distribution= =0Awithin=0Athe=0Arecipient's place of business for planning purposes only.= Further=0Adissemination, whether private or public is prohibited.=0A=0A =0A=0ARe: [mile] IOCs=0A =0A=0ASunday, January 27, 2013 8:52 PM=0AFrom:=0A"Stoecker, Paul" =0ATo:=0A"mile@ietf.org" =0AI would like to lo= ok at this from a slightly different=0Aperspective=C5=A0let's say I get an = XML document that tells me about an=0Aincident.=C2=A0=C2=A0This document ha= s source IP and destination IP that is=0Abeing shared.=C2=A0=C2=A0However, = what I don't know is which IP address is my=0Aindicator and which is just a= contextual piece of information.=C2=A0=C2=A0This=0Ameans that my detection= product isn't going to know which one to use=0Aeither, because there is no= thing to tell me which IP is the one,=0Aeven=0Aif the roles are set it stil= l might not be enough to tell my system=0A=0Awhich=0Aone I should use as th= e indicator.=0A=0A =0A=0AIf we had something like indicator_id as an attribute, it would=0Aall= ow=0Aus to easily identify indicators from contextual data.=C2=A0=C2=A0I do= admit=0Ato=0Abeing biased as I have spent much of my career working on the= =0Amonitoring and detection side of these things, so I am just thinking=0Ao= f ways to make it very clear what the indicators are in the XML=0Adocument = and the other data that may be important as I investigate=0Aactivity that I= have detected off of those indicators.=0A =0A=0A =0A=0AI did suggest the detection class, but I think we may get more=0Aflex= ibility with the indicator_uid.=C2=A0=C2=A0One thing that I haven't=0Aconsi= dered is the UID portion of this=C5=A0how do we use that UID?=C2=A0=C2=A0Ho= w=0Ais=0Athe UID created?=C2=A0=C2=A0Are there standards for UIDs?=0A =0A=0ARegards,=0A =0A=0APaul=0A =0A=0A =0A=0A =0A=0APaul W. Stoecker, Ph.D.=0ASMC Lead Content Architect=0ARSA, The Secur= ity Division of EMC=0Acell: 302.379.3375 | e: paul.stoecker@rsa.com=0A =0A=0A--- On Sat, 1/26/13, C. Henry Adams & BIE =0Aw= rote:=0A =0A=0AFrom: C. Henry Adams & BIE =0ASubject: RE: [mi= le] IOCs=0ATo: "KathleenMoriarty" =0ACc: mile@ie= tf.org=0ADate: Saturday, January 26, 2013, 6:17 PM=0A =0A=0AGreetings Kathleen,=0A =0A=0AYour logic stimulates my visionary brain because I'm amazed at the=0A= many=0A=0Aavenues you review with this approach at once.=C2=A0=C2=A0However= ,=C2=A0=C2=A0could you=0Ashare=0Aa=0Afew advantages and disadvantages to th= e latter?=0A---------------------------------------------------------------= -----=0A--------=0A----------------------------------------------=0A=0A"we = could continue to group items in logical places as is done now=0Ain=0A=0AIO= DEF and then have the extension point for combined indicators via=0ASCI."= =0A--------------------------------------------------------------------=0A-= -------=0A---------------------------------------------=0A=0A =0A=0AYou pointed out what you consider to be logical places, but if I=0Awa= nted to=0A=0Aprotect information from parties capable of ascertaining it fr= om your=0Alogical places, perhaps we should also consider to a degree what= =0Aappears=0Ato=0Abe illogical in brilliant minds in some instances.=0A=0A =0A=0A =0A=0A =0A=0AC. Henry Adams=0Achatlga2000@yahoo.com (Direct Email)=0Achenryadams@b= iemediagroup.com=0A =0A=0AThe information contained herein is for the exclusive use of the=0Aor= iginal=0A=0Arecipient. This information is granted for limited distribution= =0Awithin=0Athe=0Arecipient's place of business for planning purposes only.= Further=0Adissemination, whether private or public is prohibited.=0A=0A =0A=0A--- On Sat, 1/26/13, Moriarty, Kathleen = =0A=0Awrote:=0A=0A =0A=0AFrom: Moriarty, Kathleen =0ASubject: RE: [= mile] IOCs=0ATo: "C. Henry Adams & BIE" , "mile@ietf= .org"=0A=0A=0A=0ADate: Saturday, January 26, 2013, 10:13 AM= =0A =0A=0AHello C. Henry & others,=0A =0A=0AThanks for taking a look at this.=C2=A0=C2=A0We have a few considerat= ions in=0Athis=0A=0Aemail thread I would like to hear thoughts on (and ther= e may be more=0Aonce=0ARFC5070-bis is actively edited).=0A=0A =0A=0AThe AdditionalData class and the RecordItem class both allow for=0Ano= n-XML=0A=0Aextensions.=C2=A0=C2=A0Where you place the extensions should be = specific to the=0Alogical grouping of the parent elements so you can unders= tand more=0Aabout=0Athe=0Aincluded data in most cases.=0A=0A =0A=0AThe Impact class can be used to provide context information on the=0A= =0Aincluded data of the report and also can include a confidence rating=0Ao= n=0Athe=0Areport as a whole.=C2=A0=C2=A0Extensions related to impact would = be one level=0Ahigher=0A(at the moment) in the Assessment class using the A= dditionalData=0Aextension=0Apoint.=0A=0A =0A=0ATake asked about including vulnerability information, I would think= =0Athat=0A=0Awould fit under the Vulnerability extension point of the SCI d= raft in=0Athe=0AMethod class.=C2=A0=C2=A0He did ask about non-XML.=C2=A0=C2= =A0RecordItem or=0AAdditionalData=0Ado=0Aallow for non-XML extension points= , we could either have the SCI=0Adraft=0Ahandle these as well or have the e= xtensions that are non-XML come=0Adirectly=0Aoff the AdditionalData or Reco= rdItem classes according to what makes=0Asense=0Afrom a logical standpoint.= =0A=0A =0A=0AAs for my question, it was two-fold.=0A =0A=0AIndicator based schemas have a reference number or a GUID for the=0Av= arious=0A=0Aindicators they share.=C2=A0=C2=A0If we are extending to embed = other schemas=0Athat=0Ainclude such reference or GUID identifiers, do we wa= nt to add an=0Aattribute=0Ato the various elements in IODEF that could be i= ndicators?=C2=A0=C2=A0Is this=0Aenough=0Ato make the connections or is some= thing else else needed?=C2=A0=C2=A0We could=0Aadd=0Asomething like an Indic= ator_ID in RFC5070-bis which would then=0Acorrelate=0Ato=0Athe reference or= GUID identifiers.=0A=0A =0A=0AThen the other question was on how to include indicators that are=0An= ot=0Ain=0A=0Athe base schema that may be related or have language with "and= " "or"=0Ato=0Aspecify the relationships.=C2=A0=C2=A0In some cases, you will= want to group=0Athese=0Aindictors in one extension point, where they may f= it logically in=0Amultiple=0Aplaces if the relationships did not need to be= shown in the data=0Aformat.=C2=A0=C2=A0If=0Awe have cases like this where = you need more complex representations,=0Ashould=0Awe use one extension poin= t via the SCI draft off of the EventData=0Aclass=0AAdditionalData extension= point?=C2=A0=C2=A0Opinions are needed here....=0A=0A =0A=0AA few people have mentioned wanting to include some commonly shared= =0A=0Aindictors into the base IODEF document.=C2=A0=C2=A0We could have a ca= tch-all=0Aclass=0Athat does this and has an extension point off of it in Ev= entData or=0Awe=0Acould=0Acontinue to group items in logical places as is d= one now in IODEF and=0Athen=0Ahave the extension point for combined indicat= ors via SCI.=C2=A0=C2=A0I think I=0Alike=0Athe latter approach.=0A=0A =0A=0AThank you,=0AKathleen=0A________________________________________=0AFr= om: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C.=0AHenry= =0A=0AAdams & BIE [chatlga2000@yahoo.com]=0A=0ASent: Saturday, January 26, = 2013 3:05 AM=0ATo: mile@ietf.org=0ACc: C. Henry Adams=0ASubject: Re: [mile]= IOCs=0A =0A=0AGreetings Everyone,=0A =0A=0ATake mentioned two types of indicators based on the :=0A=0A----------= ----------------------------------------------------------=0A--------=0A---= -----------------------=0A=0A1) If the indicators are something like an XML= -based alert/warning=0Aof=0Ainformation leakage, it could be an event that = are conveyed in the=0ASCI's EventReport class, IMHO.=0A =0A=0A2) If the indicators are something like an non-XML ones, I guess it= =0Acould=0A=0Abe=0A=0Aconveyed without using SCI draft.=0AFor instance, we = could use Impact class of the base IODEF to convey=0Athe indicators.=0AWe c= ould for instance extend the list of indicators of the Impact=0Aclass,=0A= =0Aif=0A=0Aneeded.=0A=0A---------------------------------------------------= -----------------=0A--------=0A--------------------------=0A=0A =0A=0AIn doing so he pointed out the "Impact Class"=0A =0A=0AWhereas, Kathleen stated,=0A=0A--------------------------------------= ------------------------------=0A--------=0A-------------------------=0A=0A= For the discussion below, I was thinking more of combined set with=0A=0Arel= ationships that may be included in a single extension point, so=0Athat's=0A= why I was thinking about the EventData class, but there may be better=0Aloc= ations or a specific area within the EventData.=0A=0A =0A=0APaul Stoecker had suggested a "Detection" class as a consideration.= =0A=0A--------------------------------------------------------------------= =0A--------=0A------------------------=0A=0A =0A=0AKathleen thoughts related yet still with other indicators and the=0A= =0AEventData Class.=0A=0A =0A=0AIs there a possible way to create a new XML class which encompass=0A= =0Acombining the EventData, Detection and base IODEF classes to simplify=0A= this=0Aissue?=0A=0A =0A=0A =0A=0AC. Henry Adams=0Achatlga2000@yahoo.com (Direct Email)=0Achenryadams@b= iemediagroup.com=0A =0A=0A =0A=0AThe information contained herein is for the exclusive use of the=0Aor= iginal=0A=0Arecipient. This information is granted for limited distribution= =0Awithin=0Athe=0Arecipient's place of business for planning purposes only.= Further=0Adissemination, whether private or public is prohibited.=0A=0A___= ____________________________________________=0Amile mailing list=0Amile@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A=0A=0A =0A=0A_______________________________________________=0Amile mailing list= =0Amile@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A=0A =0A=0A_______________________________________________=0Amile mailing list= =0Amile@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A =0A=0A=0A=0A =0A=0A_______________________________________________=0Amile mailing list= =0Amile@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A=0A =0A=0A_______________________________________________=0Amile mailing list= =0Amile@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A =0A=0A=0A=0A=0A=0A=0A=0A --1458340343-941635131-1360769048=:12028 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A=0A =0A=0A
= =0A
=0A
=0A
Again, I would concur that both a numeric and subje= ctive analysis of the Confidence Rating needs to be express, but combined i= n a simplified schema as such below:

<Confidence rating=3D" Alpha= numeric">1LL</> .... etc.

<Confidence rating=3D" Alphanu= meric">2P</>

<Confidence rating=3D" Alphanumeric">3AC= </>

<Confidence rating=3D" Alphanumeric">4U</>
=
<Confidence rating=3D" Alphanumeric">5I</>

( i.e.  1 =3D Less Li= kely,   2 =3D Probable,  3 =3D A Concern,  4 = =3D  Urgent, 5 =3D Imminent )

Here's my point, perhaps a s= et of numeric related or associated definitions can lower the propagation o= f error regarding the analysis.  

Thanks,C. Henry Adams


I agree that what we really need is both.  = In most situations a =0Alow, medium and high may be acceptable but there ar= e times when we will =0Awant to show that confidence in a situation is incr= easing or decreasing.=0A  If we are only looking at a three levels,=0A= we cannot express what is needed to show confidence is trending up on =0At= he data being exchanged about the event.
=0A

=0A
=0A
= Kathleen included the following in a previous message.
=0A

=0A=
=0A
=0A
<= Confidence rating=3D"low"/>
=0A

=0A
=0A
Vs:
=0A

=0A
=0A
&= lt;Confidence rating=3D"numeric">85</>
=0A
=0A

= =0A
=0A
I really think we need to include both capabilities as Joh= n alluded=0A to since confidence is not a three tiered item but something t= hat is =0Aindeed subjective and we need a means to show a reasonably accura= te =0Aconfidence index that the sender is trying to convey.
=0A
=0A
=0A
Kent Landfield
=0A
=0AMcAfee | An Intel Company
=0ADirect: +1.972.963.7096 =0AMobile: +1.817.637.8026
=0AWeb: www.mcafee.com
=0A
=0A
=0A
<= br>=0A
=0A=0A
=0AFrom: <Ban= ghart>, John Banghart <john= .banghart@nist.gov>
=0ADate: Wednesday, February 13, 2013 7:16 AM
=0ATo: "Stoecker, Paul" <Paul.Stoecker@rsa.com>, Kathleen Moriarty <kathleen.moriarty@emc.com>, Brian Tram= mell <trammell@tik.ee.ethz.ch= >
=0ACc: "C. Henry Adams= & BIE" <chatlga2000@yahoo.= com>, MILE IETF <mile@ietf.org>
=0ASubject: Re: [mile] I= OCs
=0A
=0A

=0A
=0A
=0A
=0A
=0A
Paul,
=0A

= =0A
=0A
I agree that confidence is subjective, but subjectivity ca= n be reduced
=0A
within communities that interact frequently. = ; Prioritization of indicators
=0A
and response between tight= ly connected sharing partners might require a
=0A
more specific le= vel of detail, particularly during a crisis situation.
=0A

=0A=
=0A
From that perspective, I think the guidance should allow for = additional
=0A
granularity, while stressing the "high, medium, low= " as preferred for
=0A
broad interoperability.
=0A

= =0A
=0A
-John
=0A

=0A
=0A=0A

=0A
=0A
=0A
I may have been too succi= nct in my response ;-)
=0A

=0A
=0A
Confidence is a su= bjective thing, so I think we should use subjective
=0A
terms:&nbs= p; Low, Medium, High.  Having a numeric scale with a map tha= t
=0A
essentially would say something like:
=0A

=0A=0A
1-33 =3D Low
=0A
34-67=3D Medium
=0A
68-100= =3DHigh
=0A

=0A
=0A
Is just a more complicated way of= saying that something is Low, Medium,
=0A
High...do we really thi= ng that how High something is makes that much of a
=0A
difference?=
=0A

=0A
=0A
This is like when you get your Performan= ce review where it is Does Not
=0A
Meet, Meets and Exceeds...your = boss tells you that you are a High
=0A
Meets...your
=0A
b= onus tells you that you got the same bonus that all the other Meets got=0A
;-)
=0A

=0A
=0A
Anyway, I digress but tryin= g to prove a point that I would argue that
=0A
confidence in this = case is going to be basically a gut feeling, so why use
=0A
numeri= c values when Low, Medium, High would do just fine.
=0A

=0A=0A

=0A
=0A
Paul W. Stoecker, Ph.D.
=0A
SMC Le= ad Content Architect
=0A
RSA, The Security Division of EMC
= =0A
cell: 302.379.3375 | e: p= aul.stoecker@rsa.com
=0A

=0A
=0A

=0A
=0A=

=0A
=0A

=0A
=0A

=0A
=0A

=0A=
=0A
On 2/13/13 7:48 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
=0Awrote:
=0A

=0A
=0A
=0A
Hello,
=0A

=0A
=0A
B= oth approaches will validate in the current schema.  The represen= tation
=0A
looks a little different for each, here is an example:<= /div>=0A

=0A
=0A
<Confidence rating=3D"low"/>
= =0A

=0A
=0A
Vs:
=0A

=0A
=0A
<Conf= idence rating=3D"numeric">85</>
=0A

=0A
=0A
= Searching capability is a great point, agreed.  I'd like to hear = from
=0A
more people to make sure we don't lose a capability that = others find
=0A
extremely useful (need to gauge that).  = Other options is that the
=0A
guidance can also discourage the use= of the numeric in addition to
=0A
specifying how to select ranges= .
=0A

=0A
=0A
Any other opinions?
=0A

= =0A
=0A
Thanks,
=0A
Kathleen
=0A

=0A
= =0A
-----Original Message-----
=0A
From: Stoecker, Paul
= =0A
Sent: Wednesday, February 13, 2013 7:14 AM
=0A
To: Brian T= rammell
=0A
Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE= IETF
=0A
Subject: Re: [mile] IOCs
=0A

=0A
=0ACant we make Confidence a List that has only 3 values:  High, = Medium, and
=0A
Low?  Any other value means that the Doc= ument will mot validate against
=0A
the schema.
=0A

= =0A
=0A
Sent from my iPhone
=0A

=0A
=0A
On F= eb 13, 2013, at 2:14 AM, "Brian Trammell" <trammell@tik.ee.ethz.ch>
=0A
wrote:
=0A<= div>
=0A
=0A
=0A
Hi, Kathleen, all,
=0A

=0A
=0A
I think= 3.10.4 in 5070 takes the right approach here: trying to build
=0Ainteroperable numeric scales for assessment is a very hard problem.
= =0A
(Were I charged with defining such a scale, the value "70" would me= an
=0A
"we compared this incident report to N past similar inciden= t reports
=0A
according to similarity algorithm S, and 70% of the = past reports had
=0A
assessed impacts within E% of the actual, mea= sured final impact -- I
=0A
think for most applications this is va= stly more difficult and rigorous
=0A
than it needs to be.)
= =0A

=0A
=0A
Unless a numeric Confidence value is based on = some actual, repeatably
=0A
measurable aspect of the Assessment re= port -- which I suspect in
=0A
many/most/all cases it's not -- the= n it just represents a guess, however
=0A
educated.  Eac= h team will probably naturally tune its own scales such
=0A
that e= ach value generally means the same thing in each report. Across
=0Ateams, I don't know.
=0A

=0A
=0A
On the other hand,= Assessments are by their very nature educated
=0A
guesses, anyway= , so I don't know that I'd find much use in automating a
=0A
respo= nse based on the assessment confidence. Chris has a good point,
=0Athough -- it makes searching difficult and sorting kind of pointless.=0A

=0A
=0A
If we've seen a general trend toward "0 =3D = 0%, 100 =3D 100%", then I
=0A
agree, we should put that in the gui= dance document (along with a note
=0A
that 0-33 map to low, 34 - 6= 6 map to medium, and 67 - 100 map to high,
=0A
unless we want to d= o it non-linearly). If the _vast_majority_ of the
=0A
users of thi= s field use a 100-point scale with 100 meaning "yes" and 0
=0A
mea= ning "any resemblance these values may have to actual fact is purely
= =0A
coincidental", then let's consider renaming it "percent" in 5070-bi= s.
=0A

=0A
=0A
Best regards,
=0A

=0A=0A
Brian (as contributor)
=0A

=0A
=0A

=0A<= /div>=0A
On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"
=0A<kathleen.moriarty@emc.com= > wrote:
=0A

=0A
=0A
=0A
Please see section 3.10.4 of RFC507= 0 as a starting point.  We can
=0A
change it if it needs= to be changed.  The value is for a confidence
=0A
ratin= g on the indicators shared.  The definitions may be helpful for=0A
anyone who wants to work on this discussion.  IODEF h= as various markers
=0A
that can be used in a complimentary way wit= hout conflating the markers
=0A
meaning.
=0A

=0A=0A
I think some people using IODEF find the numerical values more=0A
helpful, and it would be good to understand what people have lear= ned
=0A
from using the current structure (what works/does not work= ).  The
=0A
scales I have seen are 0-100.  The= re is of course a subjective element
=0A
to assigning a numerical = value to the confidence and it may vary from
=0A
entity to entity.=   With this type of rating you may need to consider
=0A
= who it came from and how they scored the confidence rating to map to
= =0A
your own rating.  It would be good to hear more thoughts = on this.
=0A

=0A
=0A
Thanks,
=0A
Kathleen=0A

=0A
=0A
From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]
=0ASent: Tuesday, February 12, 2013 2:46 PM
=0A
To: MILE IETF
= =0A
Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
= =0A
Subject: Re: [mile] IOCs
=0A

=0A
=0A

=0A<= /div>=0A
Regarding the IOCs or Indicators of Compromise, Chris made a v= ital
=0A
point.  Different Confidence levels will cause = confusion.  It appears
=0A
that there maybe a need for s= ome type of simplified standardization to
=0A
be established betwe= en all Sharing Groups in this regard.
=0A

=0A
=0A
Per= haps numerical scoring set at lower values should express levels of
= =0A
urgency.
=0A
( i.e.  1 =3D Less Likely, &nb= sp; 2 =3D Probable,  3 =3D A Concern,  4 =3D  = ;Urgent,
=0A
5 =3D Imminent )
=0A

=0A
=0A
Th= anks,
=0A
C. Henry Adams
=0A

=0A
=0A

=0A=
=0A

=0A
=0A
I see some confusion coming down the pik= e if we start using Confidence
=0A
the
=0A
way it is supp= orted. If I am using low/med/high and someone sends me
=0A
an IoC<= /div>=0A
with a score of 70, what does that mean to me? What if I am us= ing a
=0A
scale of
=0A
1 to 4 and someone else is on a sc= ale of 1 to 5? We lose the ability
=0A
to
=0A
describe so= mething with a consistent language. It really gets ugly
=0A
when w= e
=0A
store IoC from multiple sources. I have confidence values th= at are
=0A
numeric
=0A
as well as text.  Makes = searching / sorting very problematic.
=0A

=0A
=0A
At = this point we have to roll with what we have. I would strongly
=0Arecommend
=0A
that we revisit this at some point.
=0A
=0A
=0A
Thanks,
=0A

=0A
=0A
--Chris
= =0A

=0A
=0A
-----Original Message-----
=0A
From: = Moriarty, Kathleen
=0A
Sent: Tuesday, February 12, 2013 9:59 AM=0A
To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul= ;
=0A
'MILE
=0A
IETF'
=0A
Subject: RE: [mile] IO= Cs
=0A

=0A
=0A
Hi Chris & Take,
=0A

= =0A
=0A
I'll just focus on the confidence scoring.  Righ= t now, the schema
=0A
allows for
=0A
you to either use a = numerical score OR the ratings of low, medium, and
=0A
high.
= =0A
Different sharing groups can decide how they want to share the data= .
=0A
If
=0A
people were to use the numerical values, I a= gree it would be helpful
=0A
to have
=0A
guidance. &= nbsp;This could go in the IODE guidance document.
=0A

=0A=0A
I have seen examples of current users that use each of the approac= hes,
=0A
so
=0A
we'll need to keep the option for backwar= ds compatibility and it is
=0A
nice to
=0A
keep in flexib= le options where we can.
=0A

=0A
=0A
Thank you,
= =0A
Kathleen
=0A

=0A
=0A
-----Original Message---= --
=0A
From: Harrington, Christopher
=0A
Sent: Tuesday, F= ebruary 12, 2013 9:22 AM
=0A
To: 'Takeshi Takahashi'; Moriarty, Ka= thleen; Stoecker, Paul; 'MILE
=0A
IETF'
=0A
Subject: RE: = [mile] IOCs
=0A

=0A
=0A
The number of indicators woul= dn't necessarily drive the use of
=0A
indicator_set_id. The purpos= e is to show relationship. If I sent 3 IP
=0A
addresses that were = used as C2 for 3 different campaigns I would have
=0A
separate ind= icator_set_ids, each with one of the 3 C2 IPs
=0A

=0A
=0A=
My suggestion would be a simple low, medium, high. I think if we break=
=0A
it
=0A
down to more levels than that we would need t= o provide guidance on
=0A
scoring,
=0A
rating, etc. I thi= nk most people should be able to understand
=0A
low/med/high
= =0A
without having to have a mathematical method for arriving at the=0A
level.
=0A

=0A
=0A
Low - I am not sure=0A
Medium - I am reasonably sure
=0A
High - I am very sure<= /div>=0A

=0A
=0A

=0A
=0A
Thanks,
=0A
=0A
=0A
--Chris
=0A

=0A
=0A
-----Origin= al Message-----
=0A
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
= =0A
Sent: Tuesday, February 12, 2013 4:21 AM
=0A
To: Harringto= n, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE
=0A
IETF= '
=0A
Subject: RE: [mile] IOCs
=0A

=0A
=0A
R= egarding the indicator_set_id, I agree, it is useful when we need to
= =0A
deal
=0A
with large sets of indicators.
=0A
Since= indicator_set_id attribute is optional (right?), it could be
=0A
= omitted
=0A
if we need to deal with only small number of indicator= s.
=0A

=0A
=0A
Regarding the use case, I like the ide= a of using the confidence
=0A
attribute
=0A
for the reaso= n Chris kindly described.
=0A
I would like to hear a bit more on t= his: is it going to be numerical?
=0A
For
=0A
instance, 1= means "no confidence" while 5 means "strong confidence",
=0A
etc?=
=0A

=0A
=0A
Thank you.
=0A
Take
=0A
=0A
=0A

=0A
=0A
=0A
-----Original Message-----
=0A
F= rom: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]
=0A
Sent: Friday, = February 08, 2013 4:11 AM
=0A
To: Moriarty, Kathleen; Takeshi Taka= hashi; Stoecker, Paul; 'MILE
=0A
IETF'
=0A
Subject: RE: [= mile] IOCs
=0A

=0A
=0A
With respect to tying things b= ack to threat actors, from what I have
=0A
seen and use this is a = generally accepted grouping:
=0A

=0A
=0A
Indicator --= > Indictor Set --> Campaign --> Threat Actor
=0A

=0A<= /div>=0A
Campaign and Threat Actor are where having a "Confidence" attr= ibute
=0A
would be beneficial as making those associations is not = a perfect
=0A
science by any means.
=0A

=0A
=0A<= div>Thanks,
=0A

=0A
=0A
--Chris
=0A

=0A<= /div>=0A

=0A
=0A
-----Original Message-----
=0A
F= rom: Moriarty, Kathleen
=0A
Sent: Thursday, February 07, 2013 2:00= PM
=0A
To: Takeshi Takahashi; Harrington, Christopher; Stoecker, = Paul; 'MILE
=0A
IETF'
=0A
Subject: RE: [mile] IOCs
= =0A

=0A
=0A
Hi Take & others,
=0A

=0A=0A
Thanks for chiming in, I've been talking about this with Chris an= d a
=0A
few others on their use cases and would like more opinions= .  I'll
=0A
provide an option below from what we have di= scussed from a CIRC view
=0A
point.  We are also wonderi= ng how to also provide logic in IODEF that
=0A
could cross over in= to SCI attached schemas or IODEF extensions (the
=0A
solutions may= all tie together with this discussion - or there may be
=0A
bette= r/more elegant solutions others would like to propose).
=0A

= =0A
=0A
-----Original Message-----
=0A
From: Takeshi Taka= hashi [mailto:takeshi_takah= ashi@nict.go.jp]
=0A
Sent: Tuesday, February 05, 2013 12:04 PM=
=0A
To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathle= en;
=0A
'MILE
=0A
IETF'
=0A
Subject: RE: [mile] = IOCs
=0A

=0A
=0A
=0A
I like this discussion.
=0A
I agree, = it would be good idea to have indicator identifiers inside
=0A
the= IOC-related classes.
=0A
=0A

=0A
=0A
KMM= : At the class level, we may have several indicators listed that
=0Ashould be viewed as a set and may have another instance of that same=0A
class that is a related issue, but a separate set.  We = could as you
=0A
say, list the indicator IDs connected through the= reference class.
=0A
The set IDs might give us other ways to grou= p the values when we get
=0A
into logic and relationships between = sets or indicators.  This could
=0A
also be a way to con= nect indicators or sets across XML documents that
=0A
could have b= een shared previously.  If there are a large number of
=0Aindicators in the set, then this becomes useful, for smaller sets, I=0A
agree it doesn't make as much sense.
=0A

=0A
= =0A
What do others think?
=0A

=0A
=0A
=0A
=0A
Then for indicators not inclu= ded in the base schema that may not
=0A
fit into a category in the= SCI draft, do we create a place for
=0A
these off of SCI or right= off of the IODE schema in EventData?
=0A
(more details
=0A=0A
=0A
on
=0A
=0A
=0A
this in my first message).
=0A=0A

=0A
=0A
If we could see any indicator of compromis= e as computer event
=0A
record, we could use SCI:EventReport class= as the place for the
=0A
XML-based IOCs that couldn't fit anywher= e else.
=0A
=0A

=0A
=0A
KMM: That sounds = like a good idea to me.  This should go into
=0A
guidanc= e
=0A
in the SCI draft.  Does anyone else want to weigh = in?
=0A

=0A
=0A
=0A

=0A
=0A
For the non-XML IOCs, we c= ould use RecordData class, as suggested.
=0A
=0A
KMM: = Sounds good, thanks!
=0A

=0A
=0A
=0A
I agree to have indicator_uid,= but I am not sure about the needs of
=0A
the indicator_set_id.=0A
I understand we could do some grouping of individual indicator_u= ids
=0A
and its usability, but I am not sure whether we do not hav= e any
=0A
other way to express these groupings.
=0A
For i= nstance,  a Reference class refers to several indicadtor_uids.=0A
=0A
In
=0A
=0A
this case, they could be, in a sense, grou= ped. Isn't it enough?
=0A
=0A

=0A
=0A
KMM= : It may be, what do you think about large sets of indicators or
=0Asubsequent messages that add indicators to existing sets?  Wou= ld this
=0A
happen?  Would it be easier to express relat= ionships with sets of
=0A
indicators in addition to individual ind= icators?  By using this, it
=0A
could give us a unique w= ay to also provide the logic and
=0A
relationships
=0A
in= a new class of IODEF so we don't have to worry about adding it
=0Ainto
=0A
the current
=0A
=0A
structure.=0A
=0A
= If there are better ways to handle that, and others can provide some
= =0A
options, that would be appreciated!
=0A

=0A
=0AThank you,
=0A
Kathleen
=0A

=0A
=0A=0A
I would appreci= ate if anybody could share expertise on this. Though
=0A
= =0A
I
=0A
=0A
think I have read all the emails in the list, I might have=0A
mis-understood some points.
=0A

=0A
=0A
By = the way, I think the indicator_uids should be added to the SCI
=0A=0A
=0A
classes'
=0A
=0A
=0A
attributes so that they can be correlate= d with another information
=0A
as
=0A
=0A
wel= l.
=0A
= =0A

=0A
=0A
Thanks
=0A
Take
=0A
= =0A

=0A
=0A

=0A
=0A

=0A
=0A=0A
Of Harrington, Christopher
=0A
Sent: Tuesday, Fe= bruary 05, 2013 4:25 AM
=0A
To: Stoecker, Paul; Moriarty, Kathleen= ; MILE IETF
=0A
Subject: Re: [mile] IOCs
=0A

=0A=0A
I think some sort of group ID would do the trick. We also need a=0A
logical and / or somewhere to show relationship between indicat= ors.
=0A
If
=0A
I give you
=0A
2
=0A
re= gistry keys do they both have to be present to be an indication of
=0A=
compromise or is either one by themselves an indicator? Both would=0A
have the same group ID since they are related.
=0A

= =0A
=0A
Thanks,
=0A
--Chris
=0A

=0A
=0A=
From: Stoecker, Paul
=0A
Sent: Sunday, February 03, 2013 8:26= PM
=0A
To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF=
=0A
Subject: Re: [mile] IOCs
=0A

=0A
=0A
Wh= at if we added indicator group ID along with the indicator_uid?
=0AThis would allow you to group indicators that are related into the
= =0A
same group ID.
=0A
Would this resolve the issue?
=0A<= div>
=0A
=0A
It is either that or going back to adding a Detect= ion (or Indicators)
=0A
class that will should be used to take all= of the indicators put them
=0A
into one place and have the abilit= y to group the ones that go
=0A
together.  I don't mean = a place to put indicators that are missing
=0A
from IODEF.I mean a= place in the IODEF document where you put the
=0A
indicators that= are used for detection and prevention of the shared
=0A
Incident.=   I don't know the answer here, but there has got to be a
= =0A
good way for indicators to be identified and being able to group th= em
=0A
as Chris has suggested without basically recreating somethi= ng
=0A
complicated like STIX.
=0A

=0A
=0A
Pa= ul
=0A

=0A
=0A

=0A
=0A
Paul W. Stoecker,= Ph.D.
=0A
SMC Lead Content Architect
=0A
RSA, The Securi= ty Division of EMC
=0A
cell: 302.379.3375 | e: paul.stoecker@rsa.com
=0A

=0A
= =0A

=0A
=0A
From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>
= =0A
Date: Sunday, February 3, 2013 5:11 PM
=0A
To: "Harrington= , Christopher" <Christ= opher.Harrington@emc.com>, MILE
=0A=0A
Subject: Re: [mile] I= OCs
=0A

=0A
=0A
Hi Chris,
=0A

=0A
= =0A
I agree, we have some work to do in the updated IODEF, RFC5070-bis.=
=0A

=0A
=0A
The list has already said they would lik= e to see indicators added to
=0A
the definitions in RFC5070-bis, t= o be more explicit about including
=0A
indicators and sets of indi= cators in IODE documents as opposed to
=0A
'parts of an incident o= r the useful information on an incident for
=0A
sharing purposes.&= nbsp; It was written before we used terms like
=0A
indicators= .  With that in mind, Rosella proposed a number of changes
= =0A
back in July, both for guidance and for
=0A
=0Aformat
=0A
=0A
updates.  It may help to have the first draft try to = address at least
=0A
some of these issues so people can understand= the problems and at
=0A
least a proposed solution.
=0A
<= br>=0A
=0A
As you point out, we need to be able to show relationsh= ips between
=0A
sets of indicators, where we may have a few sets o= f indicators that
=0A
could have a relationship to each other with= in a document.  In the
=0A
July presentation, one of the= questions was to see if we should add
=0A
new category attribute = values for the System class that would connect
=0A
the list of inc= luded indicators.  I think we should still keep the
=0A
= concept of a Node to a single node, but perhaps within System, list
= =0A
multiple sets of Nodes that may be one type of attack.  R= osella had
=0A
suggested pulling forward the "FraudType" from RFC5= 901, this would
=0A
help solve the issue as NodeRole values would = compliment an
=0A
AttackType
=0A
(FraudType values could = be included in AttackType or some broader
=0A
term).  It= may be better to have the FraudTypes, plus attribute
=0A
values=0A
like "C2-server", "sinkhole",  "MalwareDistribution" = for added
=0A
context
=0A
so you know what to do with the= received set of indicators.
=0A

=0A
=0A
I am proposi= ng that we change IODEF to include multiple sets of
=0A
= =0A
indicators,
=0A
=0A
add an AttackType attribute (or some other name), a = method to connect
=0A
indicators and indicator sets within an IODE= F using an attribute of
=0A
indicator_uid (or some other name) wit= h a string value to make the
=0A
connection points, and add a few = indicators that are commonly shared
=0A
into the base IODEF.
= =0A

=0A
=0A
Back in July, we talked about adding Registry = Key/Value pairs and
=0A
hashes to the main IODEF document (trying = to see if this will help
=0A
Chris below).  What if we a= dded the Registry Key/Value pairs as a
=0A
class off of RecordData= , using a similar structure to what is in
=0A
RFC5901, and also ad= ded the ability to include hashes in RecordData?
=0A
I think if we= then had the indicator_uid at the RecordData level, we
=0A
could = connect a set within that structure and repeat the structure
=0A
f= or
=0A
other sets in the same way we would do with Node inside of = the System
=0A
class, using the indicator_uid to tie the set toget= her.  Then at the
=0A
more specific level for the hash, = registry Key/value, IP, etc. use an
=0A
indicator_uid if we needed= them marked at this level as well?  Maybe
=0A
we want i= ndicator_set at the higher level?  I'd like some opinions on=0A
this approach.  +1 if you agree, suggestions if you have= other ideas
=0A
that may work better.
=0A

=0A
= =0A
We'll also need to worry about marking the indicators to prevent=0A
forward sharing when not permitted.  We may want to us= e these values
=0A
or something else.
=0A

=0A
= =0A
Thank you!
=0A
Kathleen
=0A

=0A
=0A
= From: Harrington, Christopher
=0A
Sent: Friday, February 01, 2013 = 12:01 PM
=0A
To: Moriarty, Kathleen; MILE IETF
=0A
Subjec= t: RE: [mile] IOCs
=0A

=0A
=0A
I think we have a bigg= er relationship issue to address. Let use the
=0A
Watchlist Use Ca= se. A bunch of indicators are sent in one message. In
=0A
that mes= sage we could have groupings of indicators that we need to
=0A
sho= w are
=0A
related:
=0A

=0A
=0A
Two or more i= ndicators of different type that relate to the same
=0A
threat:=0A
       The file hash of a maliciou= s file and the URL of the C2 that
=0A
the file uses. Either or bot= h may be present to indicate a
=0A
compromise.
=0A

= =0A
=0A
Two or more indicators of the same type that relate to the= same
=0A
threat:
=0A
      = ; 2 different registry values for the same registry key. If
=0A
ei= ther value is present it is a compromise indicator but both will
=0Anot
=0A
be
=0A
=0A
present.
=0A=0A

=0A=0A
The problem compounds itself very quickly. Consider the scenario<= /div>=0A
where
=0A
both groupings above are part of the same t= hreat. I need to show that
=0A
logical groupings of Indicators are= related as well. We can't send
=0A
multiple IODEF messages for th= is from what I remember reading.
=0A

=0A
=0A
The last= one I can think of would be when you have 2 different
=0A
indicat= ors that represent the same indicator. It's not uncommon to
=0A
se= nd both the
=0A
MD5
=0A
and SHA1 hash of a malicious file= . The indicator is the file but the
=0A
IOCs are the 2 hash values= . How do we show they are related? If we
=0A
use
=0A
a un= ique Inidcator ID for each hash value there needs to be a higher
=0Alevel
=0A
=0A
grouping.
=0A
=0A

=0A
=0A
Tho= ughts?
=0A

=0A
=0A
Thanks,
=0A

=0A
= =0A
--Chris
=0A

=0A
=0A
Christopher Harrington=0A
Consulting Security Engineer
=0A
GSO - Critical Inciden= t Response Center EMC - Where Information Lives
=0A
174 Middlesex = Turnpike
=0A
Bedford, MA 01730
=0A
781-515-5862 (work)=0A
603-583-1585 (cell)
=0A

=0A
=0A
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=0A
Of Moriarty, Kathleen
=0A
Sent: Friday, February 01, 2= 013 11:28 AM
=0A
To: MILE IETF
=0A
Subject: Re: [mile] IO= Cs
=0A

=0A
=0A
All -
=0A

=0A
=0AI'd like your input and will refocus the thread to get opinions from=0A
the list on options to help solve the problems raised in my messag= e
=0A
and additionally in Paul's message.
=0A

=0A=0A
Interesting point, C. Henry.  Our objective here is to = have machine
=0A
automated exchanges, so we rely on encryption rat= her than obfuscation
=0A
to achieve the necessary level of confide= ntiality.
=0A

=0A
=0A
Paul mentioned the need to dist= inguish indicators of compromise from
=0A
context information that= may also include IP address or other data
=0A
that could be indic= ators.  The question I raised was on how to
=0A
connect<= /div>=0A
sets of indicators in the same IODEF document, assuming the ab= ility
=0A
to
=0A
have watchlists that could have several = sets of indicators included,
=0A
as well as to connect indicators = that may be included in embedded
=0A
schemas.
=0A

=0A=
=0A
If we add an attribute on all of the relevant indicators, let= 's say
=0A
'indicator-uid' how do we mark the indicators? &nb= sp;Do we use this to
=0A
mark
=0A
who sent the indicator = as well so that we can prevent forward sharing
=0A
when it is not = permitted or handle that separately?
=0A

=0A
=0A
Then= for indicators not included in the base schema that may not fit
=0Ainto a category in the SCI draft, do we create a place for these off=0A
of SCI or right off of the IODE schema in EventData? (more detail= s on
=0A
this in my first message).
=0A

=0A
=0A<= div>Comments and questions encouraged to figure out the right technical=0A
solution to have this machine automatable.
=0A

=0A=0A
Thank you,
=0A
Kathleen
=0A

=0A
=0A<= div>From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf
=0A
Of C.
=0A
Henry Adams & BIE
=0A=
Sent: Monday, January 28, 2013 11:25 PM
=0A
To: MILE IETF=0A
Subject: Re: [mile] IOCs
=0A

=0A
=0A
Tempor= al Dependency sounds interesting.  I remember when I first ran=0A
across this particular craft, an experienced colleague asked me = a
=0A
peculiar question.  He said, " How do you stop som= eone from tracking
=0A
the IP Address to your computer?"
=0A<= div>
=0A
=0A
I replied, "I don't know, how?"
=0A

= =0A
=0A
Then he said, "Cut the dog-gone thing off  and t= he modem that it is
=0A
connected- which is constantly on!" &= nbsp; LOL
=0A

=0A
=0A
Here's my point (Hypothetical S= ituation) :  There is a 1st Responder
=0A
searching a Ne= ighborhood for Survivors which were hit by a Disaster
=0A
or
= =0A
let's just say "Live" Terrorist Situation.  He /or She ne= eds to
=0A
communication back to other Officials that he /or someh= ow is in
=0A
Danger.  The device used to communicate has= been captured by the
=0A
great
=0A
minds of the enemy.&n= bsp; It's only a matter of time before they utilize
=0A=0A<= div>original recipient. This information is granted for limited
=0Adistribution within the recipient's place of business for planning
= =0A
purposes only. Further dissemination, whether private or public is<= /div>=0A
prohibited.
=0A

=0A
=0A
--- On Mon, 1/28= /13, Dave Misell <david.misell@b= cs.org> wrote:
=0A

=0A
=0A
From: Dave Misell &= lt;david.misell@bcs.org>=0A
Subject: Re: [mile] IOCs
=0A
To: "C. Henry Adams & B= IE" <chatlga2000@yahoo.com&= gt;
=0A
Date: Monday, January 28, 2013, 9:25 PM UID could be mirro= red with
=0A
DNS
=0A
SEC a pemanent and temporal key, wit= h a temporal Id?
=0A

=0A
=0A
Yours Faithfully,
= =0A

=0A
=0A
Dave Misell MSc CISSP
=0A
SilentCircl= e  dsm
=0A
07710 380044
=0A=0A

=0A
=0A=

=0A
=0A
On 29 Jan 2013, at 00:39, C. Henry Adams & BI= E
=0A=0A
wrote:
=0A

=0A
=0A=0A
Serialization of= a particular Lists of XML Classes in a unique way
=0A
was
= =0A
=0A
closely related to what I attempted to express when= I stated,
=0A
"consider to a degree what appears to be illogical = in brilliant minds
=0A
in some instances."
=0A
=0A

=0A
=0AHowever, I see Dr. Stoecker's point a little clearer.  However,= it
=0A
would
=0A=0A
be nice if the UID was = in some way disguised from those who study
=0A
this
=0A
S= ecurity Art Form in a negative way.
=0A
=0A

=0A
=0A
C. Henry Adams<= /div>=0A=0A

=0A
=0A

=0A=0A
The information contained herein is for the exclusive use of the<= /div>=0A
original
=0A
=0A
recipient. This informat= ion is granted for limited distribution
=0A
within
=0A
th= e
=0A
recipient's place of business for planning purposes only. Fu= rther
=0A
dissemination, whether private or public is prohibited.<= /div>=0A
=0A
=0A
=0A
Re: [mile] IOCs
=0A

=0A
=0A
S= unday, January 27, 2013 8:52 PM
=0A
From:
=0A
"Stoecker, = Paul" <Paul.Stoecker@rsa.com>
=0A
To:
=0A
"mile@= ietf.org" <mile@ietf.org>=0A
I would like to look at this from a slightly different
=0A<= div>perspective=C5=A0let's say I get an XML document that tells me about an=
=0A
incident.  This document has source IP and destinat= ion IP that is
=0A
being shared.  However, what I don't = know is which IP address is my
=0A
indicator and which is just a c= ontextual piece of information.  This
=0A
means that my = detection product isn't going to know which one to use
=0A
either,= because there is nothing to tell me which IP is the one,
=0A
even=
=0A
if the roles are set it still might not be enough to tell my = system
=0A=0A
which
=0A
one I should use as = the indicator.
=0A
=0A

=0A
=0A
If we had something like indicator_i= d as an attribute, it would
=0A
allow
=0A
us to easily id= entify indicators from contextual data.  I do admit
=0A
= to
=0A
being biased as I have spent much of my career working on t= he
=0A
monitoring and detection side of these things, so I am just= thinking
=0A
of ways to make it very clear what the indicators ar= e in the XML
=0A
document and the other data that may be important= as I investigate
=0A
activity that I have detected off of those i= ndicators.
=0A

=0A
=0A

=0A
=0A
I did sug= gest the detection class, but I think we may get more
=0A
flexibil= ity with the indicator_uid.  One thing that I haven't
=0Aconsidered is the UID portion of this=C5=A0how do we use that UID? &= nbsp;How
=0A
is
=0A
the UID created?  Are there= standards for UIDs?
=0A

=0A
=0A
Regards,
=0A
=0A=0A
Paul
=0A

=0A
=0A

=0A
= =0A

=0A
=0A
Paul W. Stoecker, Ph.D.
=0A
SMC Lead = Content Architect
=0A
RSA, The Security Division of EMC
=0Acell: 302.379.3375 | e: paul.st= oecker@rsa.com=0A

=0A
=0A
--- On Sat, 1/26/13, C= . Henry Adams & BIE <chatlg= a2000@yahoo.com>
=0A
wrote:
=0A

=0A
=0AFrom: C. Henry Adams & BIE <chatlga2000@yahoo.com>=0A
Subject: RE: [mile] IOCs=0A
To: "KathleenMoriarty" <kathleen.moriarty@emc.com>
=0A=0A
Date: Saturday, January 26= , 2013, 6:17 PM
=0A

=0A
=0A
Greetings Kathleen,
= =0A

=0A
=0A
Your logic stimulates my visionary brain becau= se I'm amazed at the
=0A
many
=0A=0A
avenues= you review with this approach at once.  However,  coul= d you
=0A
share
=0A
a
=0A
few advantages and dis= advantages to the latter?
=0A
------------------------------------= --------------------------------
=0A
--------
=0A
-------= ---------------------------------------
=0A
=0A
"we could continue to group item= s in logical places as is done now
=0A
in
=0A
=0A=
IODEF and then have the extension point for combined indicators via=0A
SCI."
=0A
---------------------------------------------= -----------------------
=0A
--------
=0A
----------------= -----------------------------
=0A
=0A

=0A
=0A
You pointed out what = you consider to be logical places, but if I
=0A
wanted to
=0A=
=0A
protect information from parties capable of ascertaini= ng it from your
=0A
logical places, perhaps we should also conside= r to a degree what
=0A
appears
=0A
to
=0A
be ill= ogical in brilliant minds in some instances.
=0A
=0A

=0A
=0A

= =0A
=0A

=0A
=0A
C. Henry Adams
=0A
chatlga2000@yahoo.com (Direct Email)=0A=0A

=0A
=0A
The information contai= ned herein is for the exclusive use of the
=0A
original
=0A=0A
recipient. This information is granted for limited distr= ibution
=0A
within
=0A
the
=0A
recipient's place= of business for planning purposes only. Further
=0A
dissemination= , whether private or public is prohibited.
=0A
=0A

=0A
=0A
--- On S= at, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>
=0A
=0A
wrote:=
=0A
=0A<= div>
=0A
=0A
From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
=0A
Subj= ect: RE: [mile] IOCs
=0A
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org"
=0A
=0A=0A=0A
Date: Saturda= y, January 26, 2013, 10:13 AM
=0A

=0A
=0A
Hello C. He= nry & others,
=0A

=0A
=0A
Thanks for taking a loo= k at this.  We have a few considerations in
=0A
this=0A=0A
email thread I would like to hear thoughts on (an= d there may be more
=0A
once
=0A
RFC5070-bis is actively = edited).
=0A
=0A

=0A
=0A
The AdditionalData class and the RecordIte= m class both allow for
=0A
non-XML
=0A
=0A
ex= tensions.  Where you place the extensions should be specific to t= he
=0A
logical grouping of the parent elements so you can understa= nd more
=0A
about
=0A
the
=0A
included data in m= ost cases.
=0A
=0A

=0A
=0A
The Impact class can be used to provide = context information on the
=0A
=0A
included data of th= e report and also can include a confidence rating
=0A
on
=0A<= div>the
=0A
report as a whole.  Extensions related to im= pact would be one level
=0A
higher
=0A
(at the moment) in= the Assessment class using the AdditionalData
=0A
extension
= =0A
point.
=0A
=0A

=0A
=0A
Take asked about including vulnerabi= lity information, I would think
=0A
that
=0A
=0A<= div>would fit under the Vulnerability extension point of the SCI draft in=0A
the
=0A
Method class.  He did ask about non-= XML.  RecordItem or
=0A
AdditionalData
=0A
do=0A
allow for non-XML extension points, we could either have the SC= I
=0A
draft
=0A
handle these as well or have the extensio= ns that are non-XML come
=0A
directly
=0A
off the Additio= nalData or RecordItem classes according to what makes
=0A
sense=0A
from a logical standpoint.
=0A
=0A

=0A
=0A
As for my que= stion, it was two-fold.
=0A

=0A
=0A
Indicator based s= chemas have a reference number or a GUID for the
=0A
various
= =0A
=0A
indicators they share.  If we are extendi= ng to embed other schemas
=0A
that
=0A
include such refer= ence or GUID identifiers, do we want to add an
=0A
attribute
= =0A
to the various elements in IODEF that could be indicators? &nb= sp;Is this
=0A
enough
=0A
to make the connections or is s= omething else else needed?  We could
=0A
add
=0Asomething like an Indicator_ID in RFC5070-bis which would then
=0Acorrelate
=0A
to
=0A
the reference or GUID identifiers= .
=0A
=0A=

=0A
=0A
Then the other question was on how to include ind= icators that are
=0A
not
=0A
in
=0A
=0A<= div>the base schema that may be related or have language with "and" "or"=0A
to
=0A
specify the relationships.  In some ca= ses, you will want to group
=0A
these
=0A
indictors in on= e extension point, where they may fit logically in
=0A
multiple=0A
places if the relationships did not need to be shown in the data=
=0A
format.  If
=0A
we have cases like this wh= ere you need more complex representations,
=0A
should
=0Awe use one extension point via the SCI draft off of the EventData
=0A=
class
=0A
AdditionalData extension point?  Opinions= are needed here....
=0A
=0A

=0A
=0A
A few people have mentioned wa= nting to include some commonly shared
=0A
=0A
indictor= s into the base IODEF document.  We could have a catch-all
= =0A
class
=0A
that does this and has an extension point off of= it in EventData or
=0A
we
=0A
could
=0A
continu= e to group items in logical places as is done now in IODEF and
=0Athen
=0A
have the extension point for combined indicators via SCI= .  I think I
=0A
like
=0A
the latter approach.<= /div>=0A
=0A
=0A
=0A
Thank you,
=0A
Kathleen
=0A
_____= ___________________________________
=0A=0A
Henr= y
=0A=0A
Adams & BIE [chatlga2000@yahoo.com]
=0A
=0A
Sent: Saturday, January 26, 20= 13 3:05 AM
=0A=0A
Cc: C. Henry Adams
=0A
Subject: Re: [mile] IOCs=0A

=0A
=0A
Greetings Everyone,
=0A

=0A=0A
Take mentioned two types of indicators based on the :
=0A<= /blockquote>=0A
-------------------------------------------------------= -------------
=0A
--------
=0A
--------------------------=
=0A
=0A<= div>1) If the indicators are something like an XML-based alert/warning=0A
of
=0A
information leakage, it could be an event that are= conveyed in the
=0A
SCI's EventReport class, IMHO.
=0A
<= br>=0A
=0A
2) If the indicators are something like an non-XML ones= , I guess it
=0A
could
=0A
=0A
be
=0A=0A
conveyed= without using SCI draft.
=0A
For instance, we could use Impact cl= ass of the base IODEF to convey
=0A
the indicators.
=0A
W= e could for instance extend the list of indicators of the Impact
=0Aclass,
=0A
=0A
if
=0A
=0A
needed.
=0A
= =0A
-------------------------------------------------------------------= -
=0A
--------
=0A
--------------------------
=0A=0A

=0A<= /div>=0A
In doing so he pointed out the "Impact Class"
=0A
=0A
=0A
Whereas, Kathleen stated,
=0A=0A
--= ------------------------------------------------------------------
=0A=
--------
=0A
-------------------------
=0A
=0A
For the discussion = below, I was thinking more of combined set with
=0A
=0Arelationships that may be included in a single extension point, so
= =0A
that's
=0A
why I was thinking about the EventData class, b= ut there may be better
=0A
locations or a specific area within the= EventData.
=0A
=0A

=0A
=0A
Paul Stoecker had suggested a "Detectio= n" class as a consideration.
=0A
=0A
-----------------= ---------------------------------------------------
=0A
--------=0A
------------------------
=0A
=0A

=0A
=0A
Kathleen thoug= hts related yet still with other indicators and the
=0A
= =0A
EventData Class.
=0A
=0A

=0A
=0A
Is there a possible way to= create a new XML class which encompass
=0A
=0A
combin= ing the EventData, Detection and base IODEF classes to simplify
=0Athis
=0A
issue?
=0A
=0A

=0A
=0A

=0A
=0A
C. = Henry Adams
=0A=0A=0A

=0A=0A

=0A
=0A
The information contained herein is for th= e exclusive use of the
=0A
original
=0A
=0A
r= ecipient. This information is granted for limited distribution
=0Awithin
=0A
the
=0A
recipient's place of business for pla= nning purposes only. Further
=0A
dissemination, whether private or= public is prohibited.
=0A
=0A
_______________________________________________=0A
mile mailing list
=0A=0A=0A
=0A=0A

=0A=0A
_______________________________________________
=0A
mil= e mailing list
=0A=0A=0A=0A

=0A
=0A
_____________________= __________________________
=0A
mile mailing list
=0A=0A=0A

=0A
= =0A=0A=0A

=0A
=0A
______________= _________________________________
=0A
mile mailing list
=0Amile@ietf.org
=0A=0A=0A

=0A
=0A
____________________________________________= ___
=0A
mile mailing list
=0A=0A=0A

=0A
=0A=0A=0A=0A=0A=0A=0A
--1458340343-941635131-1360769048=:12028-- From ktneely@juniper.net Wed Feb 13 08:31:15 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D952B21F895B for ; Wed, 13 Feb 2013 08:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzB9dPKx4rSg for ; Wed, 13 Feb 2013 08:31:11 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9260C21F8994 for ; Wed, 13 Feb 2013 08:31:07 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKURu/ywBParaDExLczeaUNk8smWx1LZhW@postini.com; Wed, 13 Feb 2013 08:31:10 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Feb 2013 08:29:34 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 13 Feb 2013 08:29:33 -0800 Received: from CO9EHSOBE011.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 13 Feb 2013 08:38:17 -0800 Received: from mail132-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE011.bigfish.com (10.236.130.74) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Feb 2013 16:29:33 +0000 Received: from mail132-co9 (localhost [127.0.0.1]) by mail132-co9-R.bigfish.com (Postfix) with ESMTP id 83840600150 for ; Wed, 13 Feb 2013 16:29:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -65 X-BigFish: PS-65(zzbb2dI98dI9371I9f17R1804I146fI103dK1e83Mc3f2I148cI542Iec5I1dbaI1453Ibf3W4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673h1954cbh18602ehz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail132-co9 (localhost.localdomain [127.0.0.1]) by mail132-co9 (MessageSwitch) id 136077296976447_25535; Wed, 13 Feb 2013 16:29:29 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.250]) by mail132-co9.bigfish.com (Postfix) with ESMTP id 0F390240062; Wed, 13 Feb 2013 16:29:29 +0000 (UTC) Received: from BY2PRD0511HT002.namprd05.prod.outlook.com (157.56.237.149) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Feb 2013 16:29:28 +0000 Received: from BY2PRD0511MB416.namprd05.prod.outlook.com ([169.254.4.82]) by BY2PRD0511HT002.namprd05.prod.outlook.com ([10.255.129.37]) with mapi id 14.16.0263.000; Wed, 13 Feb 2013 16:29:27 +0000 From: Kevin Neely To: "C. Henry Adams & BIE" , MILE IETF Thread-Topic: [mile] IOCs Thread-Index: AQHOCf4qNv5jaYOQQ6aUKAx2ebt575h3dGAA Date: Wed, 13 Feb 2013 16:29:27 +0000 Message-ID: In-Reply-To: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.129.4] Content-Type: multipart/alternative; boundary="_000_CD40FB56BAB5ktneelyjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YAHOO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:31:16 -0000 --_000_CD40FB56BAB5ktneelyjunipernet_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Merely as a data point, here is a reference to the Collective Intelligence = Framework's description of confidence levels. They also use 5 categories w= ith numeric ranges. More detail available at the link: https://code.google.com/p/collective-intelligence-framework/wiki/TaxonomyCo= nfidence_v1 Certain (95 - 100) Very Confident (85 - 94) Somewhat Confident (75 - 84) Not Confident (50 - 74) Unknown (0 - 49) cheers, K From: "C. Henry Adams & BIE" > Date: Wednesday, February 13, 2013 7:24 AM To: MILE IETF > Subject: Re: [mile] IOCs Again, I would concur that both a numeric and subjective analysis of the Co= nfidence Rating needs to be express, but combined in a simplified schema as= such below: 1LL .... etc. 2P 3AC 4U 5I ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D Urge= nt, 5 =3D Imminent ) Here's my point, perhaps a set of numeric related or associated definitions= can lower the propagation of error regarding the analysis. Thanks, C. Henry Adams I agree that what we really need is both. In most situations a low, medium= and high may be acceptable but there are times when we will want to show t= hat confidence in a situation is increasing or decreasing. If we are only = looking at a three levels, we cannot express what is needed to show confide= nce is trending up on the data being exchanged about the event. Kathleen included the following in a previous message. Vs: 85 I really think we need to include both capabilities as John alluded to sinc= e confidence is not a three tiered item but something that is indeed subjec= tive and we need a means to show a reasonably accurate confidence index tha= t the sender is trying to convey. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , John Banghart > Date: Wednesday, February 13, 2013 7:16 AM To: "Stoecker, Paul" >, Kathleen Moriarty >, Brian Trammell > Cc: "C. Henry Adams & BIE" >, MILE IETF > Subject: Re: [mile] IOCs Paul, I agree that confidence is subjective, but subjectivity can be reduced within communities that interact frequently. Prioritization of indicators and response between tightly connected sharing partners might require a more specific level of detail, particularly during a crisis situation. >From that perspective, I think the guidance should allow for additional granularity, while stressing the "high, medium, low" as preferred for broad interoperability. -John On 2/13/13 8:04 AM, "Stoecker, Paul" > wrote: I may have been too succinct in my response ;-) Confidence is a subjective thing, so I think we should use subjective terms: Low, Medium, High. Having a numeric scale with a map that essentially would say something like: 1-33 =3D Low 34-67=3D Medium 68-100=3DHigh Is just a more complicated way of saying that something is Low, Medium, High...do we really thing that how High something is makes that much of a difference? This is like when you get your Performance review where it is Does Not Meet, Meets and Exceeds...your boss tells you that you are a High Meets...your bonus tells you that you got the same bonus that all the other Meets got ;-) Anyway, I digress but trying to prove a point that I would argue that confidence in this case is going to be basically a gut feeling, so why use numeric values when Low, Medium, High would do just fine. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/13/13 7:48 AM, "Moriarty, Kathleen" > wrote: Hello, Both approaches will validate in the current schema. The representation looks a little different for each, here is an example: Vs: 85 Searching capability is a great point, agreed. I'd like to hear from more people to make sure we don't lose a capability that others find extremely useful (need to gauge that). Other options is that the guidance can also discourage the use of the numeric in addition to specifying how to select ranges. Any other opinions? Thanks, Kathleen -----Original Message----- From: Stoecker, Paul Sent: Wednesday, February 13, 2013 7:14 AM To: Brian Trammell Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF Subject: Re: [mile] IOCs Cant we make Confidence a List that has only 3 values: High, Medium, and Low? Any other value means that the Document will mot validate against the schema. Sent from my iPhone On Feb 13, 2013, at 2:14 AM, "Brian Trammell" > wrote: Hi, Kathleen, all, I think 3.10.4 in 5070 takes the right approach here: trying to build interoperable numeric scales for assessment is a very hard problem. (Were I charged with defining such a scale, the value "70" would mean "we compared this incident report to N past similar incident reports according to similarity algorithm S, and 70% of the past reports had assessed impacts within E% of the actual, measured final impact -- I think for most applications this is vastly more difficult and rigorous than it needs to be.) Unless a numeric Confidence value is based on some actual, repeatably measurable aspect of the Assessment report -- which I suspect in many/most/all cases it's not -- then it just represents a guess, however educated. Each team will probably naturally tune its own scales such that each value generally means the same thing in each report. Across teams, I don't know. On the other hand, Assessments are by their very nature educated guesses, anyway, so I don't know that I'd find much use in automating a response based on the assessment confidence. Chris has a good point, though -- it makes searching difficult and sorting kind of pointless. If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I agree, we should put that in the guidance document (along with a note that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, unless we want to do it non-linearly). If the _vast_majority_ of the users of this field use a 100-point scale with 100 meaning "yes" and 0 meaning "any resemblance these values may have to actual fact is purely coincidental", then let's consider renaming it "percent" in 5070-bis. Best regards, Brian (as contributor) On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" > wrote: Please see section 3.10.4 of RFC5070 as a starting point. We can change it if it needs to be changed. The value is for a confidence rating on the indicators shared. The definitions may be helpful for anyone who wants to work on this discussion. IODEF has various markers that can be used in a complimentary way without conflating the markers meaning. I think some people using IODEF find the numerical values more helpful, and it would be good to understand what people have learned from using the current structure (what works/does not work). The scales I have seen are 0-100. There is of course a subjective element to assigning a numerical value to the confidence and it may vary from entity to entity. With this type of rating you may need to consider who it came from and how they scored the confidence rating to map to your own rating. It would be good to hear more thoughts on this. Thanks, Kathleen From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] Sent: Tuesday, February 12, 2013 2:46 PM To: MILE IETF Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul Subject: Re: [mile] IOCs Regarding the IOCs or Indicators of Compromise, Chris made a vital point. Different Confidence levels will cause confusion. It appears that there maybe a need for some type of simplified standardization to be established between all Sharing Groups in this regard. Perhaps numerical scoring set at lower values should express levels of urgency. ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D Urge= nt, 5 =3D Imminent ) Thanks, C. Henry Adams I see some confusion coming down the pike if we start using Confidence the way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale of 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text. Makes searching / sorting very problematic. At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point. Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Chris & Take, I'll just focus on the confidence scoring. Right now, the schema allows for you to either use a numerical score OR the ratings of low, medium, and high. Different sharing groups can decide how they want to share the data. If people were to use the numerical values, I agree it would be helpful to have guidance. This could go in the IODE guidance document. I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. Thank you, Kathleen -----Original Message----- From: Harrington, Christopher Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level. Low - I am not sure Medium - I am reasonably sure High - I am very sure Thanks, --Chris -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? Thank you. Take -----Original Message----- From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Friday, February 08, 2013 4:11 AM To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs With respect to tying things back to threat actors, from what I have seen and use this is a generally accepted grouping: Indicator --> Indictor Set --> Campaign --> Threat Actor Campaign and Threat Actor are where having a "Confidence" attribute would be beneficial as making those associations is not a perfect science by any means. Thanks, --Chris -----Original Message----- From: Moriarty, Kathleen Sent: Thursday, February 07, 2013 2:00 PM To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs Hi Take & others, Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions. I'll provide an option below from what we have discussed from a CIRC view point. We are also wondering how to also provide logic in IODEF that could cross over into SCI attached schemas or IODEF extensions (the solutions may all tie together with this discussion - or there may be better/more elegant solutions others would like to propose). -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF' Subject: RE: [mile] IOCs I like this discussion. I agree, it would be good idea to have indicator identifiers inside the IOC-related classes. KMM: At the class level, we may have several indicators listed that should be viewed as a set and may have another instance of that same class that is a related issue, but a separate set. We could as you say, list the indicator IDs connected through the reference class. The set IDs might give us other ways to group the values when we get into logic and relationships between sets or indicators. This could also be a way to connect indicators or sets across XML documents that could have been shared previously. If there are a large number of indicators in the set, then this becomes useful, for smaller sets, I agree it doesn't make as much sense. What do others think? Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). If we could see any indicator of compromise as computer event record, we could use SCI:EventReport class as the place for the XML-based IOCs that couldn't fit anywhere else. KMM: That sounds like a good idea to me. This should go into guidance in the SCI draft. Does anyone else want to weigh in? For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! I agree to have indicator_uid, but I am not sure about the needs of the indicator_set_id. I understand we could do some grouping of individual indicator_uids and its usability, but I am not sure whether we do not have any other way to express these groupings. For instance, a Reference class refers to several indicadtor_uids. In this case, they could be, in a sense, grouped. Isn't it enough? KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets? Would this happen? Would it be easier to express relationships with sets of indicators in addition to individual indicators? By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current structure. If there are better ways to handle that, and others can provide some options, that would be appreciated! Thank you, Kathleen I would appreciate if anybody could share expertise on this. Though I think I have read all the emails in the list, I might have mis-understood some points. By the way, I think the indicator_uids should be added to the SCI classes' attributes so that they can be correlated with another information as well. Thanks Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs I think some sort of group ID would do the trick. We also need a logical and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have the same group ID since they are related. Thanks, --Chris From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group ID. Would this resolve the issue? It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't mean a place to put indicators that are missing from IODEF.I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident. I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX. Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs Hi Chris, I agree, we have some work to do in the updated IODEF, RFC5070-bis. The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an incident or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates. It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution. As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators. I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack. Rosella had suggested pulling forward the "FraudType" from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term). It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF. Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below). What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together. Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well? Maybe we want indicator_set at the higher level? I'd like some opinions on this approach. +1 if you agree, suggestions if you have other ideas that may work better. We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or something else. Thank you! Kathleen From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related: Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses. Either or both may be present to indicate a compromise. Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading. The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. Thoughts? Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs All - I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. Paul mentioned the need to distinguish indicators of compromise from context information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately? Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). Comments and questions encouraged to figure out the right technical solution to have this machine automatable. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs Temporal Dependency sounds interesting. I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP Address to your computer?" I replied, "I don't know, how?" Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let's just say "Live" Terrorist Situation. He /or She needs to communication back to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's only a matter of time before they utilize reverse engineering to figure out how it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams chenryadams@biemediagroup.com http://biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell > wrote: From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to a degree what appears to be illogical in brilliant minds in some instances." However, I see Dr. Stoecker's point a little clearer. However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. Re: [mile] IOCs Sunday, January 27, 2013 8:52 PM From: "Stoecker, Paul" > To: "mile@ietf.org" > I would like to look at this from a slightly different perspective=A9let's say I get an XML document that tells me about an incident. This document has source IP and destination IP that is being shared. However, what I don't know is which IP address is my indicator and which is just a contextual piece of information. This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data. I do admit to being biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. I did suggest the detection class, but I think we may get more flexibility with the indicator_uid. One thing that I haven't considered is the UID portion of this=A9how do we use that UID? How is the UID created? Are there standards for UIDs? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs To: "KathleenMoriarty" > Cc: mile@ietf.org Date: Saturday, January 26, 2013, 6:17 PM Greetings Kathleen, Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once. However, could you share a few advantages and disadvantages to the latter? -------------------------------------------------------------------- -------- ---------------------------------------------- "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI." -------------------------------------------------------------------- -------- --------------------------------------------- You pointed out what you consider to be logical places, but if I wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: From: Moriarty, Kathleen > Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" >, "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM Hello C. Henry & others, Thanks for taking a look at this. We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited). The AdditionalData class and the RecordItem class both allow for non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about the included data in most cases. The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole. Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point. Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class. He did ask about non-XML. RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint. As for my question, it was two-fold. Indicator based schemas have a reference number or a GUID for the various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators? Is this enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers. Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format. If we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here.... A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI. I think I like the latter approach. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org Cc: C. Henry Adams Subject: Re: [mile] IOCs Greetings Everyone, Take mentioned two types of indicators based on the : -------------------------------------------------------------------- -------- -------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. -------------------------------------------------------------------- -------- -------------------------- In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, -------------------------------------------------------------------- -------- ------------------------- For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. -------------------------------------------------------------------- -------- ------------------------ Kathleen thoughts related yet still with other indicators and the EventData Class. Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_CD40FB56BAB5ktneelyjunipernet_ Content-Type: text/html; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable
Merely as a data point, here is a referenc= e to the Collective Intelligence Framework's description of confidence leve= ls.  They also use 5 categories with numeric ranges.  More detail= available at the link:
https://code.googl= e.com/p/collective-intelligence-framework/wiki/TaxonomyConfidence_v1

Certain (95 - 100= )

Very Confident (85 - 94)

Somewhat Confident (75 - 84)

Not Confident (50 - 74)

Unknown (0 - 49)

cheers,
K


Again, I would concur that both a numeric and subjective analysis of t= he Confidence Rating needs to be express, but combined in a simplified sche= ma as such below:

<Confidence rating=3D" Alphanumeric">1LL</> .... etc.=

<Confidence rating=3D" Alphanumeric">2P</>

<Confidence rating=3D" Alphanumeric">3AC</>

<Confidence rating=3D" Alphanumeric">4U</>

<Confidence rating=3D" Alphanumeric">5I</>

( i.e.  1 =3D Less Likely,   2 =3D Probable, =  3 =3D A Concern,  4 =3D  Urgent, 5 =3D Imminent )=

Here's my point, perhaps a set of numeric related or associated definitions= can lower the propagation of error regarding the analysis.  

Thanks,
C. Henry Adams


I agree that what we really need is both.  In most situations a low, m= edium and high may be acceptable but there are times when we will want to s= how that confidence in a situation is increasing or decreasing.  If we= are only looking at a three levels, we cannot express what is needed to show confidence is trending up on the data being= exchanged about the event.

Kathleen included the following in a previous message.

<Confidence rating= =3D"low"/>

Vs:

<Confidence rating= =3D"numeric">85</>

I really think we need to include both capabilities as John alluded to= since confidence is not a three tiered item but something that is indeed s= ubjective and we need a means to show a reasonably accurate confidence inde= x that the sender is trying to convey.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com=


Paul,

I agree that confidence is subjective, but subjectivity can be reduced=
within communities that interact frequently.  Prioritization= of indicators
and response between tightly connected sharing partners might require = a
more specific level of detail, particularly during a crisis situation.=

From that perspective, I think the guidance should allow for additiona= l
granularity, while stressing the "high, medium, low" as pref= erred for
broad interoperability.

-John

On 2/13/13 8:04 AM, "Stoecker, Paul" <Paul.Stoecker@rsa.com> wrote:

I may have been too succinct in my response ;-)

Confidence is a subjective thing, so I think we should use subjective<= /div>
terms:  Low, Medium, High.  Having a numeric scale= with a map that
essentially would say something like:

1-33 =3D Low
34-67=3D Medium
68-100=3DHigh

Is just a more complicated way of saying that something is Low, Medium= ,
High...do we really thing that how High something is makes that much o= f a
difference?

This is like when you get your Performance review where it is Does Not=
Meet, Meets and Exceeds...your boss tells you that you are a High
Meets...your
bonus tells you that you got the same bonus that all the other Meets g= ot
;-)

Anyway, I digress but trying to prove a point that I would argue that<= /div>
confidence in this case is going to be basically a gut feeling, so why= use
numeric values when Low, Medium, High would do just fine.


Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.stoecker@rsa.com






On 2/13/13 7:48 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
wrote:

Hello,

Both approaches will validate in the current schema.  The re= presentation
looks a little different for each, here is an example:

<Confidence rating=3D"low"/>

Vs:

<Confidence rating=3D"numeric">85</>

Searching capability is a great point, agreed.  I'd like to = hear from
more people to make sure we don't lose a capability that others find
extremely useful (need to gauge that).  Other options is tha= t the
guidance can also discourage the use of the numeric in addition to
specifying how to select ranges.

Any other opinions?

Thanks,
Kathleen

-----Original Message-----
From: Stoecker, Paul
Sent: Wednesday, February 13, 2013 7:14 AM
To: Brian Trammell
Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF
Subject: Re: [mile] IOCs

Cant we make Confidence a List that has only 3 values:  High= , Medium, and
Low?  Any other value means that the Document will mot valid= ate against
the schema.

Sent from my iPhone

On Feb 13, 2013, at 2:14 AM, "Brian Trammell" <trammell@tik.ee.ethz.ch>
wrote:

Hi, Kathleen, all,

I think 3.10.4 in 5070 takes the right approach here: trying to build<= /div>
interoperable numeric scales for assessment is a very hard problem.
(Were I charged with defining such a scale, the value "70" w= ould mean
"we compared this incident report to N past similar incident repo= rts
according to similarity algorithm S, and 70% of the past reports had
assessed impacts within E% of the actual, measured final impact -- I
think for most applications this is vastly more difficult and rigorous=
than it needs to be.)

Unless a numeric Confidence value is based on some actual, repeatably<= /div>
measurable aspect of the Assessment report -- which I suspect in
many/most/all cases it's not -- then it just represents a guess, howev= er
educated.  Each team will probably naturally tune its own sc= ales such
that each value generally means the same thing in each report. Across<= /div>
teams, I don't know.

On the other hand, Assessments are by their very nature educated
guesses, anyway, so I don't know that I'd find much use in automating = a
response based on the assessment confidence. Chris has a good point,
though -- it makes searching difficult and sorting kind of pointless.<= /div>

If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%"= ;, then I
agree, we should put that in the guidance document (along with a note<= /div>
that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high,=
unless we want to do it non-linearly). If the _vast_majority_ of the
users of this field use a 100-point scale with 100 meaning "yes&q= uot; and 0
meaning "any resemblance these values may have to actual fact is = purely
coincidental", then let's consider renaming it "percent"= ; in 5070-bis.

Best regards,

Brian (as contributor)


On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"

Please see section 3.10.4 of RFC5070 as a starting point.  W= e can
change it if it needs to be changed.  The value is for a con= fidence
rating on the indicators shared.  The definitions may be hel= pful for
anyone who wants to work on this discussion.  IODEF has vari= ous markers
that can be used in a complimentary way without conflating the markers=
meaning.

I think some people using IODEF find the numerical values more
helpful, and it would be good to understand what people have learned
from using the current structure (what works/does not work). &nbs= p;The
scales I have seen are 0-100.  There is of course a subjecti= ve element
to assigning a numerical value to the confidence and it may vary from<= /div>
entity to entity.  With this type of rating you may need to = consider
who it came from and how they scored the confidence rating to map to
your own rating.  It would be good to hear more thoughts on = this.

Thanks,
Kathleen

From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]
Sent: Tuesday, February 12, 2013 2:46 PM
To: MILE IETF
Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
Subject: Re: [mile] IOCs


Regarding the IOCs or Indicators of Compromise, Chris made a vital
point.  Different Confidence levels will cause confusion.&nb= sp; It appears
that there maybe a need for some type of simplified standardization to=
be established between all Sharing Groups in this regard.

Perhaps numerical scoring set at lower values should express levels of=
urgency.
( i.e.  1 =3D Less Likely,   2 =3D Probable, =  3 =3D A Concern,  4 =3D  Urgent,
5 =3D Imminent )

Thanks,
C. Henry Adams



I see some confusion coming down the pike if we start using Confidence=
the
way it is supported. If I am using low/med/high and someone sends me
an IoC
with a score of 70, what does that mean to me? What if I am using a
scale of
1 to 4 and someone else is on a scale of 1 to 5? We lose the ability
to
describe something with a consistent language. It really gets ugly
when we
store IoC from multiple sources. I have confidence values that are
numeric
as well as text.  Makes searching / sorting very problematic= .

At this point we have to roll with what we have. I would strongly
recommend
that we revisit this at some point.

Thanks,

--Chris

-----Original Message-----
From: Moriarty, Kathleen
Sent: Tuesday, February 12, 2013 9:59 AM
To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;
'MILE
IETF'
Subject: RE: [mile] IOCs

Hi Chris & Take,

I'll just focus on the confidence scoring.  Right now, the s= chema
allows for
you to either use a numerical score OR the ratings of low, medium, and=
high.
Different sharing groups can decide how they want to share the data.
If
people were to use the numerical values, I agree it would be helpful
to have
guidance.  This could go in the IODE guidance document.

I have seen examples of current users that use each of the approaches,=
so
we'll need to keep the option for backwards compatibility and it is
nice to
keep in flexible options where we can.

Thank you,
Kathleen

-----Original Message-----
From: Harrington, Christopher
Sent: Tuesday, February 12, 2013 9:22 AM
To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

The number of indicators wouldn't necessarily drive the use of
indicator_set_id. The purpose is to show relationship. If I sent 3 IP<= /div>
addresses that were used as C2 for 3 different campaigns I would have<= /div>
separate indicator_set_ids, each with one of the 3 C2 IPs

My suggestion would be a simple low, medium, high. I think if we break=
it
down to more levels than that we would need to provide guidance on
scoring,
rating, etc. I think most people should be able to understand
low/med/high
without having to have a mathematical method for arriving at the
level.

Low - I am not sure
Medium - I am reasonably sure
High - I am very sure


Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE=
IETF'
Subject: RE: [mile] IOCs

Regarding the indicator_set_id, I agree, it is useful when we need to<= /div>
deal
with large sets of indicators.
Since indicator_set_id attribute is optional (right?), it could be
omitted
if we need to deal with only small number of indicators.

Regarding the use case, I like the idea of using the confidence
attribute
for the reason Chris kindly described.
I would like to hear a bit more on this: is it going to be numerical?<= /div>
For
instance, 1 means "no confidence" while 5 means "strong= confidence",
etc?

Thank you.
Take


-----Original Message-----
From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]
Sent: Friday, February 08, 2013 4:11 AM
To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

With respect to tying things back to threat actors, from what I have
seen and use this is a generally accepted grouping:

Indicator --> Indictor Set --> Campaign --> Threat Actor

Campaign and Threat Actor are where having a "Confidence" at= tribute
would be beneficial as making those associations is not a perfect
science by any means.

Thanks,

--Chris


-----Original Message-----
From: Moriarty, Kathleen
Sent: Thursday, February 07, 2013 2:00 PM
To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE<= /div>
IETF'
Subject: RE: [mile] IOCs

Hi Take & others,

Thanks for chiming in, I've been talking about this with Chris and a
few others on their use cases and would like more opinions.  = ;I'll
provide an option below from what we have discussed from a CIRC view
point.  We are also wondering how to also provide logic in I= ODEF that
could cross over into SCI attached schemas or IODEF extensions (the
solutions may all tie together with this discussion - or there may be<= /div>
better/more elegant solutions others would like to propose).

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Tuesday, February 05, 2013 12:04 PM
To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;
'MILE
IETF'
Subject: RE: [mile] IOCs

I like this discussion.
I agree, it would be good idea to have indicator identifiers inside
the IOC-related classes.

KMM: At the class level, we may have several indicators listed that
should be viewed as a set and may have another instance of that same
class that is a related issue, but a separate set.  We could= as you
say, list the indicator IDs connected through the reference class.
The set IDs might give us other ways to group the values when we get
into logic and relationships between sets or indicators.  Th= is could
also be a way to connect indicators or sets across XML documents that<= /div>
could have been shared previously.  If there are a large num= ber of
indicators in the set, then this becomes useful, for smaller sets, I
agree it doesn't make as much sense.

What do others think?

Then for indicators not included in the base schema that may not
fit into a category in the SCI draft, do we create a place for
these off of SCI or right off of the IODE schema in EventData?
(more details
on
this in my first message).

If we could see any indicator of compromise as computer event
record, we could use SCI:EventReport class as the place for the
XML-based IOCs that couldn't fit anywhere else.

KMM: That sounds like a good idea to me.  This should go int= o
guidance
in the SCI draft.  Does anyone else want to weigh in?


For the non-XML IOCs, we could use RecordData class, as suggested.
KMM: Sounds good, thanks!

I agree to have indicator_uid, but I am not sure about the needs of
the indicator_set_id.
I understand we could do some grouping of individual indicator_uids
and its usability, but I am not sure whether we do not have any
other way to express these groupings.
For instance,  a Reference class refers to several indicadto= r_uids.
In
this case, they could be, in a sense, grouped. Isn't it enough?

KMM: It may be, what do you think about large sets of indicators or
subsequent messages that add indicators to existing sets?  W= ould this
happen?  Would it be easier to express relationships with se= ts of
indicators in addition to individual indicators?  By using t= his, it
could give us a unique way to also provide the logic and
relationships
in a new class of IODEF so we don't have to worry about adding it
into
the current
structure.
If there are better ways to handle that, and others can provide some
options, that would be appreciated!

Thank you,
Kathleen

I would appreciate if anybody could share expertise on this. Though
I
think I have read all the emails in the list, I might have
mis-understood some points.

By the way, I think the indicator_uids should be added to the SCI
classes'
attributes so that they can be correlated with another information
as
well.

Thanks
Take



Of Harrington, Christopher
Sent: Tuesday, February 05, 2013 4:25 AM
To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF
Subject: Re: [mile] IOCs

I think some sort of group ID would do the trick. We also need a
logical and / or somewhere to show relationship between indicators.
If
I give you
2
registry keys do they both have to be present to be an indication of
compromise or is either one by themselves an indicator? Both would
have the same group ID since they are related.

Thanks,
--Chris

From: Stoecker, Paul
Sent: Sunday, February 03, 2013 8:26 PM
To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF
Subject: Re: [mile] IOCs

What if we added indicator group ID along with the indicator_uid?
This would allow you to group indicators that are related into the
same group ID.
Would this resolve the issue?

It is either that or going back to adding a Detection (or Indicators)<= /div>
class that will should be used to take all of the indicators put them<= /div>
into one place and have the ability to group the ones that go
together.  I don't mean a place to put indicators that are m= issing
from IODEF.I mean a place in the IODEF document where you put the
indicators that are used for detection and prevention of the shared
Incident.  I don't know the answer here, but there has got t= o be a
good way for indicators to be identified and being able to group them<= /div>
as Chris has suggested without basically recreating something
complicated like STIX.

Paul


Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.stoecker@rsa.com


From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>
Date: Sunday, February 3, 2013 5:11 PM
To: "Harrington, Christopher" <Christopher.Harrington@emc.com>, MILE
Subject: Re: [mile] IOCs

Hi Chris,

I agree, we have some work to do in the updated IODEF, RFC5070-bis.

The list has already said they would like to see indicators added to
the definitions in RFC5070-bis, to be more explicit about including
indicators and sets of indicators in IODE documents as opposed to
'parts of an incident or the useful information on an incident for
sharing purposes.  It was written before we used terms like<= /div>
indicators.  With that in mind, Rosella proposed a number of= changes
back in July, both for guidance and for
format
updates.  It may help to have the first draft try to address= at least
some of these issues so people can understand the problems and at
least a proposed solution.

As you point out, we need to be able to show relationships between
sets of indicators, where we may have a few sets of indicators that
could have a relationship to each other within a document.  = In the
July presentation, one of the questions was to see if we should add
new category attribute values for the System class that would connect<= /div>
the list of included indicators.  I think we should still ke= ep the
concept of a Node to a single node, but perhaps within System, list
multiple sets of Nodes that may be one type of attack.  Rose= lla had
suggested pulling forward the "FraudType" from RFC5901, this= would
help solve the issue as NodeRole values would compliment an
AttackType
(FraudType values could be included in AttackType or some broader
term).  It may be better to have the FraudTypes, plus attrib= ute
values
like "C2-server", "sinkhole",  "Mal= wareDistribution" for added
context
so you know what to do with the received set of indicators.

I am proposing that we change IODEF to include multiple sets of
indicators,
add an AttackType attribute (or some other name), a method to connect<= /div>
indicators and indicator sets within an IODEF using an attribute of
indicator_uid (or some other name) with a string value to make the
connection points, and add a few indicators that are commonly shared
into the base IODEF.

Back in July, we talked about adding Registry Key/Value pairs and
hashes to the main IODEF document (trying to see if this will help
Chris below).  What if we added the Registry Key/Value pairs= as a
class off of RecordData, using a similar structure to what is in
RFC5901, and also added the ability to include hashes in RecordData?
I think if we then had the indicator_uid at the RecordData level, we
could connect a set within that structure and repeat the structure
for
other sets in the same way we would do with Node inside of the System<= /div>
class, using the indicator_uid to tie the set together.  The= n at the
more specific level for the hash, registry Key/value, IP, etc. use an<= /div>
indicator_uid if we needed them marked at this level as well? &nb= sp;Maybe
we want indicator_set at the higher level?  I'd like some op= inions on
this approach.  +1 if you agree, suggestions if you have= other ideas
that may work better.

We'll also need to worry about marking the indicators to prevent
forward sharing when not permitted.  We may want to use thes= e values
or something else.

Thank you!
Kathleen

From: Harrington, Christopher
Sent: Friday, February 01, 2013 12:01 PM
To: Moriarty, Kathleen; MILE IETF
Subject: RE: [mile] IOCs

I think we have a bigger relationship issue to address. Let use the
Watchlist Use Case. A bunch of indicators are sent in one message. In<= /div>
that message we could have groupings of indicators that we need to
show are
related:

Two or more indicators of different type that relate to the same
threat:
       The file hash of a malicious file= and the URL of the C2 that
the file uses. Either or both may be present to indicate a
compromise.

Two or more indicators of the same type that relate to the same
threat:
       2 different registry values for t= he same registry key. If
either value is present it is a compromise indicator but both will
not
be
present.

The problem compounds itself very quickly. Consider the scenario
where
both groupings above are part of the same threat. I need to show that<= /div>
logical groupings of Indicators are related as well. We can't send
multiple IODEF messages for this from what I remember reading.

The last one I can think of would be when you have 2 different
indicators that represent the same indicator. It's not uncommon to
send both the
MD5
and SHA1 hash of a malicious file. The indicator is the file but the
IOCs are the 2 hash values. How do we show they are related? If we
use
a unique Inidcator ID for each hash value there needs to be a higher
level
grouping.

Thoughts?

Thanks,

--Chris

Christopher Harrington
Consulting Security Engineer
GSO - Critical Incident Response Center EMC - Where Information Lives<= /div>
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

Of Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All -

I'd like your input and will refocus the thread to get opinions from
the list on options to help solve the problems raised in my message
and additionally in Paul's message.

Interesting point, C. Henry.  Our objective here is to have = machine
automated exchanges, so we rely on encryption rather than obfuscation<= /div>
to achieve the necessary level of confidentiality.

Paul mentioned the need to distinguish indicators of compromise from
context information that may also include IP address or other data
that could be indicators.  The question I raised was on how = to
connect
sets of indicators in the same IODEF document, assuming the ability
to
have watchlists that could have several sets of indicators included,
as well as to connect indicators that may be included in embedded
schemas.

If we add an attribute on all of the relevant indicators, let's say
'indicator-uid' how do we mark the indicators?  Do we use th= is to
mark
who sent the indicator as well so that we can prevent forward sharing<= /div>
when it is not permitted or handle that separately?

Then for indicators not included in the base schema that may not fit
into a category in the SCI draft, do we create a place for these off
of SCI or right off of the IODE schema in EventData? (more details on<= /div>
this in my first message).

Comments and questions encouraged to figure out the right technical
solution to have this machine automatable.

Thank you,
Kathleen

Of C.
Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

Temporal Dependency sounds interesting.  I remember when I f= irst ran
across this particular craft, an experienced colleague asked me a
peculiar question.  He said, " How do you stop someone = from tracking
the IP Address to your computer?"

I replied, "I don't know, how?"

Then he said, "Cut the dog-gone thing off  and the mode= m that it is
connected- which is constantly on!"   LOL

Here's my point (Hypothetical Situation) :  There is a 1st R= esponder
searching a Neighborhood for Survivors which were hit by a Disaster
or
let's just say "Live" Terrorist Situation.  He /or= She needs to
communication back to other Officials that he /or somehow is in
Danger.  The device used to communicate has been captured by= the
great
minds of the enemy.  It's only a matter of time before they = utilize
reverse engineering to figure out how it functions.  However= , their
pride comes before a fall when seeking the location of other similar
devices to attack.  Why? Perhaps the less thought of concept= s that
makes the device function properly, saves the day by disguise or
cutting it off (figuratively speaking).

Just a visionary thought.

C. Henry Adams


The information contained herein is for the exclusive use of the
original recipient. This information is granted for limited
distribution within the recipient's place of business for planning
purposes only. Further dissemination, whether private or public is
prohibited.

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> wrote:

From: Dave Misell <david.mi= sell@bcs.org>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with
DNS
SEC a pemanent and temporal key, with a temporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044


On 29 Jan 2013, at 00:39, C. Henry Adams & BIE
wrote:

Serialization of a particular Lists of XML Classes in a unique way
was
closely related to what I attempted to express when I stated,
"consider to a degree what appears to be illogical in brilliant m= inds
in some instances."

However, I see Dr. Stoecker's point a little clearer.  Howev= er, it
would
be nice if the UID was in some way disguised from those who study
this
Security Art Form in a negative way.

C. Henry Adams


The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

Re: [mile] IOCs

Sunday, January 27, 2013 8:52 PM
From:
"Stoecker, Paul" <Paul.Stoecker@rsa.com>
To:
I would like to look at this from a slightly different
perspective=A9let's say I get an XML document that tells me about an
incident.  This document has source IP and destination IP th= at is
being shared.  However, what I don't know is which IP addres= s is my
indicator and which is just a contextual piece of information. &n= bsp;This
means that my detection product isn't going to know which one to use
either, because there is nothing to tell me which IP is the one,
even
if the roles are set it still might not be enough to tell my system
which
one I should use as the indicator.

If we had something like indicator_id as an attribute, it would
allow
us to easily identify indicators from contextual data.  I do= admit
to
being biased as I have spent much of my career working on the
monitoring and detection side of these things, so I am just thinking
of ways to make it very clear what the indicators are in the XML
document and the other data that may be important as I investigate
activity that I have detected off of those indicators.


I did suggest the detection class, but I think we may get more
flexibility with the indicator_uid.  One thing that I haven'= t
considered is the UID portion of this=A9how do we use that UID? &= nbsp;How
is
the UID created?  Are there standards for UIDs?

Regards,

Paul



Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.stoecker@rsa.com

--- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com>
wrote:

From: C. Henry Adams & BIE <chatlga2000@yahoo.com>
Subject: RE: [mile] IOCs
To: "KathleenMoriarty" <kathleen.moriarty@emc.com>
Date: Saturday, January 26, 2013, 6:17 PM

Greetings Kathleen,

Your logic stimulates my visionary brain because I'm amazed at the
many
avenues you review with this approach at once.  However,&nbs= p; could you
share
a
few advantages and disadvantages to the latter?
--------------------------------------------------------------------
--------
----------------------------------------------
"we could continue to group items in logical places as is done no= w
in
IODEF and then have the extension point for combined indicators via
SCI."
--------------------------------------------------------------------
--------
---------------------------------------------

You pointed out what you consider to be logical places, but if I
wanted to
protect information from parties capable of ascertaining it from your<= /div>
logical places, perhaps we should also consider to a degree what
appears
to
be illogical in brilliant minds in some instances.



C. Henry Adams
chatlga2000@yahoo.com (Di= rect Email)

The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

--- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>
wrote:

From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
Subject: RE: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org"
Date: Saturday, January 26, 2013, 10:13 AM

Hello C. Henry & others,

Thanks for taking a look at this.  We have a few considerati= ons in
this
email thread I would like to hear thoughts on (and there may be more
once
RFC5070-bis is actively edited).

The AdditionalData class and the RecordItem class both allow for
non-XML
extensions.  Where you place the extensions should be specif= ic to the
logical grouping of the parent elements so you can understand more
about
the
included data in most cases.

The Impact class can be used to provide context information on the
included data of the report and also can include a confidence rating
on
the
report as a whole.  Extensions related to impact would be on= e level
higher
(at the moment) in the Assessment class using the AdditionalData
extension
point.

Take asked about including vulnerability information, I would think
that
would fit under the Vulnerability extension point of the SCI draft in<= /div>
the
Method class.  He did ask about non-XML.  RecordIt= em or
AdditionalData
do
allow for non-XML extension points, we could either have the SCI
draft
handle these as well or have the extensions that are non-XML come
directly
off the AdditionalData or RecordItem classes according to what makes
sense
from a logical standpoint.

As for my question, it was two-fold.

Indicator based schemas have a reference number or a GUID for the
various
indicators they share.  If we are extending to embed other s= chemas
that
include such reference or GUID identifiers, do we want to add an
attribute
to the various elements in IODEF that could be indicators?  = Is this
enough
to make the connections or is something else else needed?  W= e could
add
something like an Indicator_ID in RFC5070-bis which would then
correlate
to
the reference or GUID identifiers.

Then the other question was on how to include indicators that are
not
in
the base schema that may be related or have language with "and&qu= ot; "or"
to
specify the relationships.  In some cases, you will want to = group
these
indictors in one extension point, where they may fit logically in
multiple
places if the relationships did not need to be shown in the data
format.  If
we have cases like this where you need more complex representations,
should
we use one extension point via the SCI draft off of the EventData
class
AdditionalData extension point?  Opinions are needed here...= .

A few people have mentioned wanting to include some commonly shared
indictors into the base IODEF document.  We could have a cat= ch-all
class
that does this and has an extension point off of it in EventData or
we
could
continue to group items in logical places as is done now in IODEF and<= /div>
then
have the extension point for combined indicators via SCI.  I= think I
like
the latter approach.

Thank you,
Kathleen
________________________________________
Henry
Sent: Saturday, January 26, 2013 3:05 AM
Cc: C. Henry Adams
Subject: Re: [mile] IOCs

Greetings Everyone,

Take mentioned two types of indicators based on the :
--------------------------------------------------------------------
--------
--------------------------
1) If the indicators are something like an XML-based alert/warning
of
information leakage, it could be an event that are conveyed in the
SCI's EventReport class, IMHO.

2) If the indicators are something like an non-XML ones, I guess it
could
be
conveyed without using SCI draft.
For instance, we could use Impact class of the base IODEF to convey
the indicators.
We could for instance extend the list of indicators of the Impact
class,
if
needed.
--------------------------------------------------------------------
--------
--------------------------

In doing so he pointed out the "Impact Class"

Whereas, Kathleen stated,
--------------------------------------------------------------------
--------
-------------------------
For the discussion below, I was thinking more of combined set with
relationships that may be included in a single extension point, so
that's
why I was thinking about the EventData class, but there may be better<= /div>
locations or a specific area within the EventData.

Paul Stoecker had suggested a "Detection" class as a conside= ration.
--------------------------------------------------------------------
--------
------------------------

Kathleen thoughts related yet still with other indicators and the
EventData Class.

Is there a possible way to create a new XML class which encompass
combining the EventData, Detection and base IODEF classes to simplify<= /div>
this
issue?


C. Henry Adams
chatlga2000@yahoo.com (Di= rect Email)


The information contained herein is for the exclusive use of the
original
recipient. This information is granted for limited distribution
within
the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.
_______________________________________________
mile mailing list

_______________________________________________
mile mailing list

_______________________________________________
mile mailing list


_______________________________________________
mile mailing list

_______________________________________________
mile mailing list
--_000_CD40FB56BAB5ktneelyjunipernet_-- From Christopher.Harrington@emc.com Wed Feb 13 08:49:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5921F8AA3 for ; Wed, 13 Feb 2013 08:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.638 X-Spam-Level: * X-Spam-Status: No, score=1.638 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3xBzEXrQoKj for ; Wed, 13 Feb 2013 08:49:21 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF821F8A77 for ; Wed, 13 Feb 2013 08:49:20 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DGnJbC029920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 11:49:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 13 Feb 2013 11:49:03 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DGn2fs027430; Wed, 13 Feb 2013 11:49:02 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 13 Feb 2013 11:49:01 -0500 From: "Harrington, Christopher" To: "'C. Henry Adams & BIE'" , MILE IETF Date: Wed, 13 Feb 2013 11:49:01 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J/nM0FwsOXwAHQbisW5VEKlAi4AACYgwg Message-ID: References: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012B_01CE09E0.1CCF6040" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:49:27 -0000 ------=_NextPart_000_012B_01CE09E0.1CCF6040 Content-Type: multipart/alternative; boundary="----=_NextPart_001_012C_01CE09E0.1CCF6040" ------=_NextPart_001_012C_01CE09E0.1CCF6040 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >From a data processing standpoint it is going to create extra work for = the people who are going to receive this data if we support both numeric = and alpha characters in the same field. I can envision people wanting to = search, sort, store, etc the data in this field. If we allow both data = types then everyone will need to have a mapping of some sort. I have a = field for confidence in my threat tracking database. Having both a = numeric score and alpha characters / words creates issues when trying to = interact with the data. I agree that we need to support both however I = don=E2=80=99t think both should be in the same field. I would much = rather see 2 different fields for Confidence if we are going to support = 2 different data types.=20 =20 This will be a larger issue should Confidence be used elsewhere. Ideally = in future revisions I would like to see attribution expressed as some = form of attribution is almost always shared with an IoC. Currently = there are 5 areas where we (EMC) uses confidence.=20 =20 Indicator (how confident are you that this is a valid IoC) Indicator_Set (how confident are you that all of the indcators in the = set should be in the set) Campaign (how confident are you that all Indicator_Sets are part of this = campaign) Threat Actor (how confident are you that the Campaign is attributed to = this Threat Actor) Threat Actor type (how confident are you that this Theat Actor is APT, = Crimeware, other) =20 The threat actor name and the threat actor type are usually the first 2 = things that anyone processing IoCs wants to know as they drive priority. = Knowing how sure the sender is that this IoC is APTis a vital piece of = information for us. Sorry to take us a little off the path but I wanted = to show where Confidence could be used.=20 =20 Thanks, --Chris =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Wednesday, February 13, 2013 10:24 AM To: MILE IETF Subject: Re: [mile] IOCs =20 Again, I would concur that both a numeric and subjective analysis of the = Confidence Rating needs to be express, but combined in a simplified = schema as such below: 1LL .... etc. 2P 3AC 4U 5I ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) Here's my point, perhaps a set of numeric related or associated = definitions can lower the propagation of error regarding the analysis. = Thanks, C. Henry Adams I agree that what we really need is both. In most situations a low, = medium and high may be acceptable but there are times when we will want = to show that confidence in a situation is increasing or decreasing. If = we are only looking at a three levels, we cannot express what is needed = to show confidence is trending up on the data being exchanged about the = event. =20 Kathleen included the following in a previous message. =20 =20 Vs: =20 85 =20 I really think we need to include both capabilities as John alluded to = since confidence is not a three tiered item but something that is indeed = subjective and we need a means to show a reasonably accurate confidence = index that the sender is trying to convey. =20 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 From: , John Banghart = > Date: Wednesday, February 13, 2013 7:16 AM To: "Stoecker, Paul" = >, Kathleen Moriarty >, Brian Trammell = > Cc: "C. Henry Adams & BIE" = >, MILE IETF > Subject: Re: [mile] IOCs =20 Paul, =20 I agree that confidence is subjective, but subjectivity can be reduced within communities that interact frequently. Prioritization of = indicators and response between tightly connected sharing partners might require a more specific level of detail, particularly during a crisis situation. =20 >From that perspective, I think the guidance should allow for additional granularity, while stressing the "high, medium, low" as preferred for broad interoperability. =20 -John =20 On 2/13/13 8:04 AM, "Stoecker, Paul" > = wrote: =20 I may have been too succinct in my response ;-) =20 Confidence is a subjective thing, so I think we should use subjective terms: Low, Medium, High. Having a numeric scale with a map that essentially would say something like: =20 1-33 =3D Low 34-67=3D Medium 68-100=3DHigh =20 Is just a more complicated way of saying that something is Low, Medium, High...do we really thing that how High something is makes that much of = a difference? =20 This is like when you get your Performance review where it is Does Not Meet, Meets and Exceeds...your boss tells you that you are a High Meets...your bonus tells you that you got the same bonus that all the other Meets got ;-) =20 Anyway, I digress but trying to prove a point that I would argue that confidence in this case is going to be basically a gut feeling, so why = use numeric values when Low, Medium, High would do just fine. =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 =20 =20 =20 =20 =20 On 2/13/13 7:48 AM, "Moriarty, Kathleen" > wrote: =20 Hello, =20 Both approaches will validate in the current schema. The representation looks a little different for each, here is an example: =20 =20 Vs: =20 85 =20 Searching capability is a great point, agreed. I'd like to hear from more people to make sure we don't lose a capability that others find extremely useful (need to gauge that). Other options is that the guidance can also discourage the use of the numeric in addition to specifying how to select ranges. =20 Any other opinions? =20 Thanks, Kathleen =20 -----Original Message----- From: Stoecker, Paul Sent: Wednesday, February 13, 2013 7:14 AM To: Brian Trammell Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF Subject: Re: [mile] IOCs =20 Cant we make Confidence a List that has only 3 values: High, Medium, = and Low? Any other value means that the Document will mot validate against the schema. =20 Sent from my iPhone =20 On Feb 13, 2013, at 2:14 AM, "Brian Trammell" = > wrote: =20 Hi, Kathleen, all, =20 I think 3.10.4 in 5070 takes the right approach here: trying to build interoperable numeric scales for assessment is a very hard problem. (Were I charged with defining such a scale, the value "70" would mean "we compared this incident report to N past similar incident reports according to similarity algorithm S, and 70% of the past reports had assessed impacts within E% of the actual, measured final impact -- I think for most applications this is vastly more difficult and rigorous than it needs to be.) =20 Unless a numeric Confidence value is based on some actual, repeatably measurable aspect of the Assessment report -- which I suspect in many/most/all cases it's not -- then it just represents a guess, however educated. Each team will probably naturally tune its own scales such that each value generally means the same thing in each report. Across teams, I don't know. =20 On the other hand, Assessments are by their very nature educated guesses, anyway, so I don't know that I'd find much use in automating a response based on the assessment confidence. Chris has a good point, though -- it makes searching difficult and sorting kind of pointless. =20 If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I agree, we should put that in the guidance document (along with a note that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, unless we want to do it non-linearly). If the _vast_majority_ of the users of this field use a 100-point scale with 100 meaning "yes" and 0 meaning "any resemblance these values may have to actual fact is purely coincidental", then let's consider renaming it "percent" in 5070-bis. =20 Best regards, =20 Brian (as contributor) =20 =20 On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" > wrote: =20 Please see section 3.10.4 of RFC5070 as a starting point. We can change it if it needs to be changed. The value is for a confidence rating on the indicators shared. The definitions may be helpful for anyone who wants to work on this discussion. IODEF has various markers that can be used in a complimentary way without conflating the markers meaning. =20 I think some people using IODEF find the numerical values more helpful, and it would be good to understand what people have learned from using the current structure (what works/does not work). The scales I have seen are 0-100. There is of course a subjective element to assigning a numerical value to the confidence and it may vary from entity to entity. With this type of rating you may need to consider who it came from and how they scored the confidence rating to map to your own rating. It would be good to hear more thoughts on this. =20 Thanks, Kathleen =20 From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com = ] Sent: Tuesday, February 12, 2013 2:46 PM To: MILE IETF Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul Subject: Re: [mile] IOCs =20 =20 Regarding the IOCs or Indicators of Compromise, Chris made a vital point. Different Confidence levels will cause confusion. It appears that there maybe a need for some type of simplified standardization to be established between all Sharing Groups in this regard. =20 Perhaps numerical scoring set at lower values should express levels of urgency. ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) =20 Thanks, C. Henry Adams =20 =20 =20 I see some confusion coming down the pike if we start using Confidence the way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale of 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text. Makes searching / sorting very problematic. =20 At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point. =20 Thanks, =20 --Chris =20 -----Original Message----- From: Moriarty, Kathleen Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Hi Chris & Take, =20 I'll just focus on the confidence scoring. Right now, the schema allows for you to either use a numerical score OR the ratings of low, medium, and high. Different sharing groups can decide how they want to share the data. If people were to use the numerical values, I agree it would be helpful to have guidance. This could go in the IODE guidance document. =20 I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. =20 Thank you, Kathleen =20 -----Original Message----- From: Harrington, Christopher Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs =20 My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level. =20 Low - I am not sure Medium - I am reasonably sure High - I am very sure =20 =20 Thanks, =20 --Chris =20 -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp = ] Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. =20 Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? =20 Thank you. Take =20 =20 -----Original Message----- From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com = ] Sent: Friday, February 08, 2013 4:11 AM To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 With respect to tying things back to threat actors, from what I have seen and use this is a generally accepted grouping: =20 Indicator --> Indictor Set --> Campaign --> Threat Actor =20 Campaign and Threat Actor are where having a "Confidence" attribute would be beneficial as making those associations is not a perfect science by any means. =20 Thanks, =20 --Chris =20 =20 -----Original Message----- From: Moriarty, Kathleen Sent: Thursday, February 07, 2013 2:00 PM To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Hi Take & others, =20 Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions. I'll provide an option below from what we have discussed from a CIRC view point. We are also wondering how to also provide logic in IODEF that could cross over into SCI attached schemas or IODEF extensions (the solutions may all tie together with this discussion - or there may be better/more elegant solutions others would like to propose). =20 -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp = ] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF' Subject: RE: [mile] IOCs =20 I like this discussion. I agree, it would be good idea to have indicator identifiers inside the IOC-related classes. =20 KMM: At the class level, we may have several indicators listed that should be viewed as a set and may have another instance of that same class that is a related issue, but a separate set. We could as you say, list the indicator IDs connected through the reference class. The set IDs might give us other ways to group the values when we get into logic and relationships between sets or indicators. This could also be a way to connect indicators or sets across XML documents that could have been shared previously. If there are a large number of indicators in the set, then this becomes useful, for smaller sets, I agree it doesn't make as much sense. =20 What do others think? =20 Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). =20 If we could see any indicator of compromise as computer event record, we could use SCI:EventReport class as the place for the XML-based IOCs that couldn't fit anywhere else. =20 KMM: That sounds like a good idea to me. This should go into guidance in the SCI draft. Does anyone else want to weigh in? =20 =20 For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! =20 I agree to have indicator_uid, but I am not sure about the needs of the indicator_set_id. I understand we could do some grouping of individual indicator_uids and its usability, but I am not sure whether we do not have any other way to express these groupings. For instance, a Reference class refers to several indicadtor_uids. In this case, they could be, in a sense, grouped. Isn't it enough? =20 KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets? Would this happen? Would it be easier to express relationships with sets of indicators in addition to individual indicators? By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current structure. If there are better ways to handle that, and others can provide some options, that would be appreciated! =20 Thank you, Kathleen =20 I would appreciate if anybody could share expertise on this. Though I think I have read all the emails in the list, I might have mis-understood some points. =20 By the way, I think the indicator_uids should be added to the SCI classes' attributes so that they can be correlated with another information as well. =20 Thanks Take =20 =20 =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs =20 I think some sort of group ID would do the trick. We also need a logical and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have the same group ID since they are related. =20 Thanks, --Chris =20 From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs =20 What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group ID. Would this resolve the issue? =20 It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't mean a place to put indicators that are missing from IODEF.I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident. I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX. =20 Paul =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 =20 From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs =20 Hi Chris, =20 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =20 The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an incident or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates. It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution. =20 As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators. I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack. Rosella had suggested pulling forward the "FraudType" from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term). It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. =20 I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF. =20 Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below). What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together. Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well? Maybe we want indicator_set at the higher level? I'd like some opinions on this approach. +1 if you agree, suggestions if you have other ideas that may work better. =20 We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or something else. =20 Thank you! Kathleen =20 From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =20 I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related: =20 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses. Either or both may be present to indicate a compromise. =20 Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. =20 The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading. =20 The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. =20 Thoughts? =20 Thanks, =20 --Chris =20 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =20 All - =20 I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. =20 Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. =20 Paul mentioned the need to distinguish indicators of compromise from context information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. =20 If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately? =20 Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). =20 Comments and questions encouraged to figure out the right technical solution to have this machine automatable. =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =20 Temporal Dependency sounds interesting. I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP Address to your computer?" =20 I replied, "I don't know, how?" =20 Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL =20 Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let's just say "Live" Terrorist Situation. He /or She needs to communication back to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's only a matter of time before they utilize reverse engineering to figure out how it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). =20 Just a visionary thought. =20 C. Henry Adams chenryadams@biemediagroup.com = =20 http://biemediagroup.com =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 --- On Mon, 1/28/13, Dave Misell > = wrote: =20 From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? =20 Yours Faithfully, =20 Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org = =20 =20 =20 On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: =20 Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to a degree what appears to be illogical in brilliant minds in some instances." =20 However, I see Dr. Stoecker's point a little clearer. However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 Re: [mile] IOCs =20 Sunday, January 27, 2013 8:52 PM From: "Stoecker, Paul" > To: "mile@ietf.org = " = > I would like to look at this from a slightly different perspective=C5=A0let's say I get an XML document that tells me about an incident. This document has source IP and destination IP that is being shared. However, what I don't know is which IP address is my indicator and which is just a contextual piece of information. This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. =20 If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data. I do admit to being biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. =20 =20 I did suggest the detection class, but I think we may get more flexibility with the indicator_uid. One thing that I haven't considered is the UID portion of this=C5=A0how do we use that UID? How is the UID created? Are there standards for UIDs? =20 Regards, =20 Paul =20 =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: =20 From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs To: "KathleenMoriarty" > Cc: mile@ietf.org = =20 Date: Saturday, January 26, 2013, 6:17 PM =20 Greetings Kathleen, =20 Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once. However, could you share a few advantages and disadvantages to the latter? -------------------------------------------------------------------- -------- ---------------------------------------------- "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI." -------------------------------------------------------------------- -------- --------------------------------------------- =20 You pointed out what you consider to be logical places, but if I wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances. =20 =20 =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: =20 From: Moriarty, Kathleen > Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" = >, "mile@ietf.org = " > Date: Saturday, January 26, 2013, 10:13 AM =20 Hello C. Henry & others, =20 Thanks for taking a look at this. We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited). =20 The AdditionalData class and the RecordItem class both allow for non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about the included data in most cases. =20 The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole. Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point. =20 Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class. He did ask about non-XML. RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint. =20 As for my question, it was two-fold. =20 Indicator based schemas have a reference number or a GUID for the various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators? Is this enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers. =20 Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format. If we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here.... =20 A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI. I think I like the latter approach. =20 Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org = = [mile-bounces@ietf.org = ] = On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com = ] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org = =20 Cc: C. Henry Adams Subject: Re: [mile] IOCs =20 Greetings Everyone, =20 Take mentioned two types of indicators based on the : -------------------------------------------------------------------- -------- -------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. =20 2) If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. -------------------------------------------------------------------- -------- -------------------------- =20 In doing so he pointed out the "Impact Class" =20 Whereas, Kathleen stated, -------------------------------------------------------------------- -------- ------------------------- For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. =20 Paul Stoecker had suggested a "Detection" class as a consideration. -------------------------------------------------------------------- -------- ------------------------ =20 Kathleen thoughts related yet still with other indicators and the EventData Class. =20 Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? =20 =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_012C_01CE09E0.1CCF6040 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

From a data processing standpoint it is going to create extra work = for the people who are going to receive this data if we support both = numeric and alpha characters in the same field. I can envision people = wanting to search, sort, store, etc the data in this field. If we allow = both data types then everyone will need to have a mapping of some sort. = I have a field for confidence in my threat tracking database. Having = both a numeric score and alpha characters / words creates issues when = trying to interact with the data. I agree that we need to support both = however I don=E2=80=99t think both should be in the same field. I would = much rather see 2 different fields for Confidence if we are going to = support 2 different data types.

 

This will be a larger issue should Confidence be used elsewhere. = Ideally in future revisions I would like to see attribution expressed = as=C2=A0 some form of attribution is almost always shared with an = IoC.=C2=A0 Currently there are 5 areas where we=C2=A0 (EMC) uses = confidence.

 

Indicator (how confident are you that this is a valid = IoC)

Indicator_Set (how confident are you that all of the indcators in the = set should be in the set)

Campaign (how confident are you that all Indicator_Sets are part of = this campaign)

Threat Actor (how confident are you that the Campaign is attributed = to this Threat Actor)

Threat Actor type (how confident are you that this Theat Actor is = APT, Crimeware, other)

 

The threat actor name and the threat actor type are usually the first = 2 things that anyone processing IoCs wants to know as they drive = priority. =C2=A0Knowing how sure the sender is that this IoC is APTis a = vital piece of information for us. =C2=A0Sorry to take us a little off = the path but I wanted to show where Confidence could be used. =

 

Thanks,

--Chris

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE
Sent: Wednesday, February 13, = 2013 10:24 AM
To: MILE IETF
Subject: Re: [mile] = IOCs

 

Again, I would concur that both a numeric = and subjective analysis of the Confidence Rating needs to be express, = but combined in a simplified schema as such below:

<Confidence = rating=3D" Alphanumeric">1LL</> .... = etc.

<Confidence rating=3D" = Alphanumeric">2P</>

<Confidence rating=3D" = Alphanumeric">3AC</>

<Confidence rating=3D" = Alphanumeric">4U</>

<Confidence rating=3D" = Alphanumeric">5I</>

( i.e.  1 =3D Less Likely,   2 =3D = Probable,  3 =3D A Concern,  4 = =3D  Urgent, 5 =3D Imminent )

Here's my point, perhaps = a set of numeric related or associated definitions can lower the = propagation of error regarding the analysis.   =


Thanks,
C. Henry = Adams


I agree that what we really need is both.  In most = situations a low, medium and high may be acceptable but there are times = when we will want to show that confidence in a situation is increasing = or decreasing.  If we are only looking at a three levels, we cannot = express what is needed to show confidence is trending up on the data = being exchanged about the event.

 

Kathleen included the following in a previous = message.

 

<Confidence = rating=3D"low"/>

 <= /p>

Vs:

=

 <= /p>

<Confidence = rating=3D"numeric">85</>

 

I really think we need to include both capabilities as = John alluded to since confidence is not a three tiered item but = something that is indeed subjective and we need a means to show a = reasonably accurate confidence index that the sender is trying to = convey.

 

= Kent Landfield=

McAfee = | An Intel Company
Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: <Banghart>, John Banghart <john.banghart@nist.gov>
Date: = Wednesday, February 13, 2013 7:16 AM
To: "Stoecker, = Paul" <Paul.Stoecker@rsa.com>, Kathleen Moriarty = <kathleen.moriarty@emc.com>, Brian = Trammell <trammell@tik.ee.ethz.ch>
Cc: = "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, MILE IETF <mile@ietf.org>
Subject: Re: [mile] = IOCs

 

Paul,

 

I = agree that confidence is subjective, but subjectivity can be = reduced

within communities = that interact frequently.  Prioritization of = indicators

and response = between tightly connected sharing partners might require = a

more specific level of = detail, particularly during a crisis = situation.

 

From that perspective, I think the guidance should = allow for additional

granularity, while stressing the "high, medium, = low" as preferred for

broad interoperability.

 

-John

 

On 2/13/13 8:04 AM, "Stoecker, Paul" <Paul.Stoecker@rsa.com> = wrote:

 

I may have been too succinct in my response = ;-)

 

Confidence is a subjective thing, so I think we should = use subjective

terms:  Low, Medium, High.  Having = a numeric scale with a map that

essentially would say something = like:

 

1-33 =3D Low

34-67=3D Medium

68-100=3DHigh

 

Is just a more complicated way of saying that = something is Low, Medium,

High...do we really thing that how High something is = makes that much of a

difference?

 

This is like when you get your Performance review = where it is Does Not

Meet, = Meets and Exceeds...your boss tells you that you are a = High

Meets...your

bonus tells you that you got the same bonus that all = the other Meets got

;-)

 

Anyway, I digress but trying to prove a point that I = would argue that

confidence in this case is going to be basically a gut = feeling, so why use

numeric values when Low, Medium, High would do just = fine.

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

 

 

 

 

 

On 2/13/13 7:48 AM, "Moriarty, Kathleen" = <kathleen.moriarty@emc.com>

<= div>

wrote:

 

Hello,

 

Both approaches will validate in the current = schema.  The representation

looks a little different for each, here is an = example:

 

<Confidence = rating=3D"low"/>

 

Vs:

 

<Confidence = rating=3D"numeric">85</>

 

Searching capability is a great point, = agreed.  I'd like to hear from

more people to make sure we don't lose a capability = that others find

extremely = useful (need to gauge that).  Other options is that = the

guidance can also = discourage the use of the numeric in addition = to

specifying how to = select ranges.

 

Any other opinions?

 

Thanks,

Kathleen

 

-----Original Message-----

From: Stoecker, Paul

Sent: Wednesday, February 13, 2013 7:14 = AM

To: Brian = Trammell

Cc: Moriarty, = Kathleen; C. Henry Adams & BIE; MILE = IETF

Subject: Re: [mile] = IOCs

 

Cant we make Confidence a List that has only 3 = values:  High, Medium, and

Low?  Any other value means that the = Document will mot validate against

the schema.

 

Sent from my iPhone

 

On Feb 13, 2013, at 2:14 AM, "Brian = Trammell" <trammell@tik.ee.ethz.ch>

wrote:

 

Hi, Kathleen, all,

 

I = think 3.10.4 in 5070 takes the right approach here: trying to = build

interoperable = numeric scales for assessment is a very hard = problem.

(Were I charged = with defining such a scale, the value "70" would = mean

"we compared = this incident report to N past similar incident = reports

according to = similarity algorithm S, and 70% of the past reports = had

assessed impacts = within E% of the actual, measured final impact -- = I

think for most = applications this is vastly more difficult and = rigorous

than it needs to = be.)

 

Unless a numeric Confidence value is based on some = actual, repeatably

measurable aspect of the Assessment report -- which I = suspect in

many/most/all = cases it's not -- then it just represents a guess, = however

educated.  Each team will probably naturally = tune its own scales such

that each value generally means the same thing in each = report. Across

teams, I = don't know.

 

On the other hand, Assessments are by their very = nature educated

guesses, = anyway, so I don't know that I'd find much use in automating = a

response based on the = assessment confidence. Chris has a good = point,

though -- it makes = searching difficult and sorting kind of = pointless.

 

If we've seen a general trend toward "0 =3D 0%, = 100 =3D 100%", then I

agree, we should put that in the guidance document = (along with a note

that = 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to = high,

unless we want to do = it non-linearly). If the _vast_majority_ of = the

users of this field = use a 100-point scale with 100 meaning "yes" and = 0

meaning "any = resemblance these values may have to actual fact is = purely

coincidental", = then let's consider renaming it "percent" in = 5070-bis.

 

Best regards,

 

Brian (as contributor)

 

 

On Feb 12, 2013, at 9:56 PM, "Moriarty, = Kathleen"

 

Please see section 3.10.4 of RFC5070 as a starting = point.  We can

change it if it needs to be changed.  The = value is for a confidence

rating on the indicators shared.  The = definitions may be helpful for

anyone who wants to work on this = discussion.  IODEF has various = markers

that can be used = in a complimentary way without conflating the = markers

meaning.

 

I = think some people using IODEF find the numerical values = more

helpful, and it would = be good to understand what people have = learned

from using the = current structure (what works/does not = work).  The

scales I have seen are 0-100.  There is of = course a subjective element

to assigning a numerical value to the confidence and = it may vary from

entity to = entity.  With this type of rating you may need to = consider

who it came from = and how they scored the confidence rating to map = to

your own = rating.  It would be good to hear more thoughts on = this.

 

Thanks,

Kathleen

 

From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]

<= div>

Sent: Tuesday, February 12, 2013 2:46 = PM

To: MILE = IETF

Cc: Moriarty, = Kathleen; 'Takeshi Takahashi'; Stoecker, = Paul

Subject: Re: [mile] = IOCs

 

 

Regarding the IOCs or Indicators of Compromise, Chris = made a vital

point.  Different Confidence levels will = cause confusion.  It appears

that there maybe a need for some type of simplified = standardization to

be = established between all Sharing Groups in this = regard.

 

Perhaps numerical scoring set at lower values should = express levels of

urgency.

( i.e.  1 =3D Less Likely,   2 =3D = Probable,  3 =3D A Concern,  4 = =3D  Urgent,

5 = =3D Imminent )

 

Thanks,

C. Henry Adams

 

 

 

I = see some confusion coming down the pike if we start using = Confidence

the

way = it is supported. If I am using low/med/high and someone sends = me

an = IoC

with a score of 70, = what does that mean to me? What if I am using = a

scale = of

1 to 4 and someone else = is on a scale of 1 to 5? We lose the ability

to

describe something with a consistent language. It = really gets ugly

when = we

store IoC from multiple = sources. I have confidence values that are

numeric

as well as text.  Makes searching / sorting = very problematic.

 

At this point we have to roll with what we have. I = would strongly

recommend

that we revisit this at some = point.

 

Thanks,

 

--Chris

 

-----Original Message-----

From: Moriarty, Kathleen

Sent: Tuesday, February 12, 2013 9:59 = AM

To: Harrington, = Christopher; 'Takeshi Takahashi'; Stoecker, = Paul;

'MILE

IETF'

Subject: RE: [mile] IOCs

 

Hi Chris & Take,

 

I'll just focus on the confidence = scoring.  Right now, the schema

allows for

you to either use a numerical score OR the ratings of = low, medium, and

high.

Different sharing groups can decide how they want to = share the data.

If

people were to use the numerical values, I agree it = would be helpful

to = have

guidance.  This could go in the IODE = guidance document.

 

I = have seen examples of current users that use each of the = approaches,

so

we'll = need to keep the option for backwards compatibility and it = is

nice = to

keep in flexible = options where we can.

 

Thank you,

Kathleen

 

-----Original Message-----

From: Harrington, = Christopher

Sent: Tuesday, = February 12, 2013 9:22 AM

To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, = Paul; 'MILE

IETF'

Subject: RE: [mile] IOCs

 

The number of indicators wouldn't necessarily drive = the use of

indicator_set_id. The purpose is to show relationship. = If I sent 3 IP

addresses = that were used as C2 for 3 different campaigns I would = have

separate = indicator_set_ids, each with one of the 3 C2 = IPs

 

My suggestion would be a simple low, medium, high. I = think if we break

it

down = to more levels than that we would need to provide guidance = on

scoring,

rating, etc. I think most people should be able to = understand

low/med/high

without having to have a mathematical method for = arriving at the

level.

 

Low - I am not sure

Medium - I am reasonably = sure

High - I am very = sure

 

 

Thanks,

 

--Chris

 

-----Original Message-----

From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]

=

Sent: Tuesday, February 12, 2013 4:21 = AM

To: Harrington, = Christopher; Moriarty, Kathleen; Stoecker, Paul; = 'MILE

IETF'

Subject: RE: [mile] IOCs

 

Regarding the indicator_set_id, I agree, it is useful = when we need to

deal

with large sets of = indicators.

Since = indicator_set_id attribute is optional (right?), it could = be

omitted

if we need to deal with only small number of = indicators.

 

Regarding the use case, I like the idea of using the = confidence

attribute

for the reason Chris kindly = described.

I would like to = hear a bit more on this: is it going to be = numerical?

For

instance, 1 means "no confidence" while 5 = means "strong confidence",

etc?

 

Thank you.

Take

 

 

-----Original Message-----

From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]

Sent: Friday, February 08, 2013 4:11 = AM

To: Moriarty, Kathleen; = Takeshi Takahashi; Stoecker, Paul; 'MILE

IETF'

Subject: RE: [mile] IOCs

 

With respect to tying things back to threat actors, = from what I have

seen and = use this is a generally accepted grouping:

 

Indicator --> Indictor Set --> Campaign --> = Threat Actor

 

Campaign and Threat Actor are where having a = "Confidence" attribute

would be beneficial as making those associations is = not a perfect

science by = any means.

 

Thanks,

 

--Chris

 

 

-----Original Message-----

From: Moriarty, Kathleen

Sent: Thursday, February 07, 2013 2:00 = PM

To: Takeshi Takahashi; = Harrington, Christopher; Stoecker, Paul; = 'MILE

IETF'

Subject: RE: [mile] IOCs

 

Hi Take & others,

 

Thanks for chiming in, I've been talking about this = with Chris and a

few = others on their use cases and would like more = opinions.  I'll

provide an option below from what we have discussed = from a CIRC view

point.  We are also wondering how to also = provide logic in IODEF that

could cross over into SCI attached schemas or IODEF = extensions (the

solutions = may all tie together with this discussion - or there may = be

better/more elegant = solutions others would like to propose).

 

-----Original Message-----

From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]

=

Sent: Tuesday, February 05, 2013 12:04 = PM

To: Harrington, = Christopher; Stoecker, Paul; Moriarty, = Kathleen;

'MILE

IETF'

Subject: RE: [mile] IOCs

 

I like this discussion.

I agree, it would be good idea to have indicator = identifiers inside

the = IOC-related classes.

 

KMM: At the class level, we may have several = indicators listed that

should be viewed as a set and may have another = instance of that same

class that is a related issue, but a separate = set.  We could as you

say, list the indicator IDs connected through the = reference class.

The set = IDs might give us other ways to group the values when we = get

into logic and = relationships between sets or indicators.  This = could

also be a way to = connect indicators or sets across XML documents = that

could have been = shared previously.  If there are a large number = of

indicators in the set, = then this becomes useful, for smaller sets, = I

agree it doesn't make as = much sense.

 

What do others think?

 

Then for indicators not included in the base schema = that may not

fit into a = category in the SCI draft, do we create a place = for

these off of SCI or = right off of the IODE schema in EventData?

(more = details

on

this in my first = message).

 

If we could see any indicator of compromise as = computer event

record, we = could use SCI:EventReport class as the place for = the

XML-based IOCs that = couldn't fit anywhere else.

 

KMM: That sounds like a good idea to = me.  This should go into

guidance

in the SCI draft.  Does anyone else want to = weigh in?

 

 

For the non-XML IOCs, we could use RecordData class, = as suggested.

KMM: Sounds good, thanks!

 

I agree to have indicator_uid, but I am not sure about = the needs of

the = indicator_set_id.

I = understand we could do some grouping of individual = indicator_uids

and its = usability, but I am not sure whether we do not have = any

other way to express = these groupings.

For = instance,  a Reference class refers to several = indicadtor_uids.

In

this case, they could be, in a sense, grouped. Isn't = it enough?

 

KMM: It may be, what do you think about large sets of = indicators or

subsequent = messages that add indicators to existing sets?  Would = this

happen?  Would it be easier to express = relationships with sets of

indicators in addition to individual = indicators?  By using this, it

could give us a unique way to also provide the logic = and

relationships

in a new class of IODEF so we don't have to worry = about adding it

into

the = current

structure.

If there are better ways to handle that, and others = can provide some

options, = that would be appreciated!

 

Thank you,

Kathleen

 

I would appreciate if anybody could share expertise on = this. Though

I

think I have read all the emails in the list, I might = have

mis-understood some = points.

 

By the way, I think the indicator_uids should be added = to the SCI

classes'

attributes so that they can be correlated with another = information

as

well.

 

Thanks

Take

 

 

 

Of Harrington, = Christopher

Sent: Tuesday, = February 05, 2013 4:25 AM

To: Stoecker, Paul; Moriarty, Kathleen; MILE = IETF

Subject: Re: [mile] = IOCs

 

I = think some sort of group ID would do the trick. We also need = a

logical and / or = somewhere to show relationship between = indicators.

If

I = give you

2

registry keys do they both have to be present to be an = indication of

compromise = or is either one by themselves an indicator? Both = would

have the same group = ID since they are related.

 

Thanks,

--Chris

 

From: Stoecker, Paul

Sent: Sunday, February 03, 2013 8:26 = PM

To: Moriarty, Kathleen; = Harrington, Christopher; MILE IETF

Subject: Re: [mile] IOCs

 

What if we added indicator group ID along with the = indicator_uid?

This would = allow you to group indicators that are related into = the

same group = ID.

Would this resolve the = issue?

 

It is either that or going back to adding a Detection = (or Indicators)

class that = will should be used to take all of the indicators put = them

into one place and = have the ability to group the ones that go

together.  I don't mean a place to put = indicators that are missing

from IODEF.I mean a place in the IODEF document where = you put the

indicators = that are used for detection and prevention of the = shared

Incident.  I don't know the answer here, but = there has got to be a

good = way for indicators to be identified and being able to group = them

as Chris has = suggested without basically recreating = something

complicated like = STIX.

 

Paul

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

 

From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>

<= div>

Date: Sunday, February 3, 2013 5:11 = PM

To: "Harrington, = Christopher" <Christopher.Harrington@emc.com>, = MILE

Subject: Re: [mile] IOCs

 

Hi Chris,

 

I = agree, we have some work to do in the updated IODEF, = RFC5070-bis.

 

The list has already said they would like to see = indicators added to

the = definitions in RFC5070-bis, to be more explicit about = including

indicators and = sets of indicators in IODE documents as opposed = to

'parts of an incident = or the useful information on an incident for

sharing purposes.  It was written before we = used terms like

indicators.  With that in mind, Rosella = proposed a number of changes

back in July, both for guidance and = for

format

updates.  It may help to have the first = draft try to address at least

some of these issues so people can understand the = problems and at

least a = proposed solution.

 

As you point out, we need to be able to show = relationships between

sets = of indicators, where we may have a few sets of indicators = that

could have a = relationship to each other within a document.  In = the

July presentation, one = of the questions was to see if we should add

new category attribute values for the System class = that would connect

the = list of included indicators.  I think we should still keep = the

concept of a Node to a = single node, but perhaps within System, list

multiple sets of Nodes that may be one type of = attack.  Rosella had

suggested pulling forward the "FraudType" = from RFC5901, this would

help solve the issue as NodeRole values would = compliment an

AttackType

(FraudType values could be included in AttackType or = some broader

term).  It may be better to have the = FraudTypes, plus attribute

values

like "C2-server", = "sinkhole",  "MalwareDistribution" for = added

context

so you know what to do with the received set of = indicators.

 

I = am proposing that we change IODEF to include multiple sets = of

indicators,

add an AttackType attribute (or some other name), a = method to connect

indicators and indicator sets within an IODEF using an = attribute of

indicator_uid = (or some other name) with a string value to make = the

connection points, and = add a few indicators that are commonly = shared

into the base = IODEF.

 

Back in July, we talked about adding Registry = Key/Value pairs and

hashes = to the main IODEF document (trying to see if this will = help

Chris = below).  What if we added the Registry Key/Value pairs as = a

class off of RecordData, = using a similar structure to what is in

RFC5901, and also added the ability to include hashes = in RecordData?

I think if = we then had the indicator_uid at the RecordData level, = we

could connect a set = within that structure and repeat the = structure

for

other sets in the same way we would do with Node = inside of the System

class, using the indicator_uid to tie the set = together.  Then at the

more specific level for the hash, registry Key/value, = IP, etc. use an

indicator_uid if we needed them marked at this level = as well?  Maybe

we want indicator_set at the higher = level?  I'd like some opinions on

this approach.  +1 if you agree, suggestions = if you have other ideas

that may work better.

 

We'll also need to worry about marking the indicators = to prevent

forward sharing = when not permitted.  We may want to use these = values

or something = else.

 

Thank you!

Kathleen

 

From: Harrington, = Christopher

Sent: Friday, = February 01, 2013 12:01 PM

To: Moriarty, Kathleen; MILE = IETF

Subject: RE: [mile] = IOCs

 

I = think we have a bigger relationship issue to address. Let use = the

Watchlist Use Case. A = bunch of indicators are sent in one message. = In

that message we could = have groupings of indicators that we need to

show are

related:

 

Two or more indicators of different type that relate = to the same

threat:

       The file hash of = a malicious file and the URL of the C2 that

the file uses. Either or both may be present to = indicate a

compromise.

 

Two or more indicators of the same type that relate to = the same

threat:

       2 different = registry values for the same registry key. = If

either value is present = it is a compromise indicator but both will

not

be

present.

 

The problem compounds itself very quickly. Consider = the scenario

where

both groupings above are part of the same threat. I = need to show that

logical = groupings of Indicators are related as well. We can't = send

multiple IODEF = messages for this from what I remember = reading.

 

The last one I can think of would be when you have 2 = different

indicators that = represent the same indicator. It's not uncommon = to

send both = the

MD5

and = SHA1 hash of a malicious file. The indicator is the file but = the

IOCs are the 2 hash = values. How do we show they are related? If = we

use

a = unique Inidcator ID for each hash value there needs to be a = higher

level

grouping.

 

Thoughts?

 

Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security = Engineer

GSO - Critical = Incident Response Center EMC - Where Information = Lives

174 Middlesex = Turnpike

Bedford, MA = 01730

781-515-5862 = (work)

603-583-1585 = (cell)

 

Of Moriarty, = Kathleen

Sent: Friday, = February 01, 2013 11:28 AM

To: MILE IETF

Subject: Re: [mile] IOCs

 

All -

 

I'd like your input and will refocus the thread to get = opinions from

the list on = options to help solve the problems raised in my = message

and additionally = in Paul's message.

 

Interesting point, C. Henry.  Our objective = here is to have machine

automated exchanges, so we rely on encryption rather = than obfuscation

to = achieve the necessary level of = confidentiality.

 

Paul mentioned the need to distinguish indicators of = compromise from

context = information that may also include IP address or other = data

that could be = indicators.  The question I raised was on how = to

connect

sets of indicators in the same IODEF document, = assuming the ability

to

have = watchlists that could have several sets of indicators = included,

as well as to = connect indicators that may be included in = embedded

schemas.

 

If we add an attribute on all of the relevant = indicators, let's say

'indicator-uid' how do we mark the = indicators?  Do we use this to

mark

who = sent the indicator as well so that we can prevent forward = sharing

when it is not = permitted or handle that separately?

 

Then for indicators not included in the base schema = that may not fit

into a = category in the SCI draft, do we create a place for these = off

of SCI or right off of = the IODE schema in EventData? (more details = on

this in my first = message).

 

Comments and questions encouraged to figure out the = right technical

solution = to have this machine automatable.

 

Thank you,

Kathleen

 

Of = C.

Henry Adams & = BIE

Sent: Monday, January = 28, 2013 11:25 PM

To: MILE = IETF

Subject: Re: [mile] = IOCs

 

Temporal Dependency sounds interesting.  I = remember when I first ran

across this particular craft, an experienced colleague = asked me a

peculiar = question.  He said, " How do you stop someone from = tracking

the IP Address to = your computer?"

 

I = replied, "I don't know, how?"

 

Then he said, "Cut the dog-gone thing = off  and the modem that it is

connected- which is constantly on!"   = LOL

 

Here's my point (Hypothetical Situation) = :  There is a 1st Responder

searching a Neighborhood for Survivors which were hit = by a Disaster

or

let's = just say "Live" Terrorist Situation.  He /or She = needs to

communication = back to other Officials that he /or somehow is = in

Danger.  The = device used to communicate has been captured by = the

great

minds of the enemy.  It's only a matter of = time before they utilize

reverse engineering to figure out how it = functions.  However, their

pride comes before a fall when seeking the location of = other similar

devices to = attack.  Why? Perhaps the less thought of concepts = that

makes the device = function properly, saves the day by disguise = or

cutting it off = (figuratively speaking).

 

Just a visionary thought.

 

C. Henry Adams

<= div>

http://biemediagroup.com

<= p class=3DMsoNormal> 

 

The information contained herein is for the exclusive = use of the

original = recipient. This information is granted for = limited

distribution = within the recipient's place of business for = planning

purposes only. = Further dissemination, whether private or public = is

prohibited.

 

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> = wrote:

 

From: Dave Misell <david.misell@bcs.org>

<= p class=3DMsoNormal>Subject: Re: [mile] IOCs

To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>

=

Date: Monday, January 28, 2013, 9:25 PM UID could = be mirrored with

DNS

SEC = a pemanent and temporal key, with a temporal = Id?

 

Yours Faithfully,

 

Dave Misell MSc CISSP

SilentCircle  dsm

07710 380044

 

 

On 29 Jan 2013, at 00:39, C. Henry Adams & = BIE

=

wrote:

 

Serialization of a particular Lists of XML Classes in = a unique way

was

closely related to what I attempted to express when I = stated,

"consider to = a degree what appears to be illogical in brilliant = minds

in some = instances."

 

However, I see Dr. Stoecker's point a little = clearer.  However, it

would

be nice if the UID was in some way disguised from = those who study

this

Security Art Form in a negative = way.

 

C. Henry Adams

<= div>

 

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

 

Re: [mile] IOCs

 

Sunday, January 27, 2013 8:52 = PM

From:

"Stoecker, Paul" <Paul.Stoecker@rsa.com>

=

To:

I would like to look at this from a slightly = different

perspective=C5=A0let's say I get an XML document that = tells me about an

incident.  This document has source IP and = destination IP that is

being shared.  However, what I don't know is = which IP address is my

indicator and which is just a contextual piece of = information.  This

means that my detection product isn't going to know = which one to use

either, = because there is nothing to tell me which IP is the = one,

even

if = the roles are set it still might not be enough to tell my = system

which

one I should use as the = indicator.

 

If we had something like indicator_id as an attribute, = it would

allow

us = to easily identify indicators from contextual data.  I do = admit

to

being = biased as I have spent much of my career working on = the

monitoring and = detection side of these things, so I am just = thinking

of ways to make = it very clear what the indicators are in the = XML

document and the other = data that may be important as I investigate

activity that I have detected off of those = indicators.

 

 

I = did suggest the detection class, but I think we may get = more

flexibility with the = indicator_uid.  One thing that I = haven't

considered is the = UID portion of this=C5=A0how do we use that = UID?  How

is

the = UID created?  Are there standards for = UIDs?

 

Regards,

 

Paul

 

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

--- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com>

=

wrote:

 

From: C. Henry Adams & BIE <chatlga2000@yahoo.com>

=

Subject: RE: [mile] = IOCs

To: = "KathleenMoriarty" <kathleen.moriarty@emc.com>

<= div>

Cc: mile@ietf.org

Date: Saturday, January 26, 2013, 6:17 = PM

 

Greetings Kathleen,

 

Your logic stimulates my visionary brain because I'm = amazed at the

many

avenues you review with this approach at = once.  However,  could = you

share

a

few = advantages and disadvantages to the latter?

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

--------

----------------------------------------------

"we could continue to group items in logical = places as is done now

in

IODEF and then have the extension point for combined = indicators via

SCI."

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

--------

---------------------------------------------

 

You pointed out what you consider to be logical = places, but if I

wanted = to

protect = information from parties capable of ascertaining it from = your

logical places, = perhaps we should also consider to a degree = what

appears

to

be = illogical in brilliant minds in some = instances.

 

 

 

C. Henry Adams

chatlga2000@yahoo.com (Direct = Email)

<= div>

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

 

--- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>

<= /blockquote>

wrote:

 

From: Moriarty, Kathleen <kathleen.moriarty@emc.com>

<= div>

Subject: RE: [mile] = IOCs

To: "C. Henry = Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org"

Date: Saturday, January 26, 2013, 10:13 = AM

 

Hello C. Henry & = others,

 

Thanks for taking a look at this.  We have a = few considerations in

this

email thread I would like to hear thoughts on (and = there may be more

once

RFC5070-bis is actively = edited).

 

The AdditionalData class and the RecordItem class both = allow for

non-XML

extensions.  Where you place the extensions = should be specific to the

logical grouping of the parent elements so you can = understand more

about

the

included data in most = cases.

 

The Impact class can be used to provide context = information on the

included data of the report and also can include a = confidence rating

on

the

report as a whole.  Extensions related to = impact would be one level

higher

(at the moment) in the Assessment class using the = AdditionalData

extension

point.

 

Take asked about including vulnerability information, = I would think

that

would fit under the Vulnerability extension point of = the SCI draft in

the

Method class.  He did ask about = non-XML.  RecordItem or

AdditionalData

do

allow = for non-XML extension points, we could either have the = SCI

draft

handle these as well or have the extensions that are = non-XML come

directly

off the AdditionalData or RecordItem classes according = to what makes

sense

from a logical = standpoint.

 

As for my question, it was = two-fold.

 

Indicator based schemas have a reference number or a = GUID for the

various

indicators they share.  If we are extending = to embed other schemas

that

include such reference or GUID identifiers, do we want = to add an

attribute

to the various elements in IODEF that could be = indicators?  Is this

enough

to make the connections or is something else else = needed?  We could

add

something like an Indicator_ID in RFC5070-bis which = would then

correlate

to

the = reference or GUID identifiers.

 

Then the other question was on how to include = indicators that are

not

in

the base schema that may be related or have language = with "and" "or"

to

specify the relationships.  In some cases, = you will want to group

these

indictors in one extension point, where they may fit = logically in

multiple

places if the relationships did not need to be shown = in the data

format.  If

we have cases like this where you need more complex = representations,

should

we use one extension point via the SCI draft off of = the EventData

class

AdditionalData extension point?  Opinions = are needed here....

 

A = few people have mentioned wanting to include some commonly = shared

indictors into the base IODEF document.  We = could have a catch-all

class

that does this and has an extension point off of it in = EventData or

we

could

continue to group items in logical places as is done = now in IODEF and

then

have the extension point for combined indicators via = SCI.  I think I

like

the = latter approach.

 

Thank you,

Kathleen

________________________________________

=

Henry

Adams & BIE [chatlga2000@yahoo.com]

Sent: Saturday, January 26, 2013 3:05 = AM

Cc: C. Henry Adams

Subject: Re: [mile] IOCs

 

Greetings Everyone,

 

Take mentioned two types of indicators based on the = :

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

--------

--------------------------

1) If the indicators are something like an XML-based = alert/warning

of

information leakage, it could be an event that are = conveyed in the

SCI's = EventReport class, IMHO.

 

2) If the indicators are something like an non-XML = ones, I guess it

could

be

conveyed without using SCI = draft.

For instance, we = could use Impact class of the base IODEF to = convey

the = indicators.

We could for = instance extend the list of indicators of the = Impact

class,

if

needed.

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

--------

--------------------------

 

In doing so he pointed out the "Impact = Class"

 

Whereas, Kathleen = stated,

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

--------

-------------------------

For the discussion below, I was thinking more of = combined set with

relationships that may be included in a single = extension point, so

that's

why I was thinking about the EventData class, but = there may be better

locations or a specific area within the = EventData.

 

Paul Stoecker had suggested a "Detection" = class as a consideration.

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

--------

------------------------

 

Kathleen thoughts related yet still with other = indicators and the

EventData Class.

 

Is there a possible way to create a new XML class = which encompass

combining the EventData, Detection and base IODEF = classes to simplify

this

issue?

 

 

C. Henry Adams

chatlga2000@yahoo.com (Direct = Email)

<= div>

 

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 

 

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 =

------=_NextPart_001_012C_01CE09E0.1CCF6040-- ------=_NextPart_000_012B_01CE09E0.1CCF6040 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTMx NjQ5MDBaMCMGCSqGSIb3DQEJBDEWBBTLXuiyqMQLQaPl9jRGfSSdifQPTzCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAiUyIjaAgHu/CYor8l0M6IC7mvMw2JtexQ3NGIrCj1DF0zwC/9GEw0/DJyphqzWPV IxMixt9yUl1I4sSagnegoOO1qiOm5DSBeIe07LHknsp/PFlLsihOfrEp5ob7KEAVu+j6RcJt/Npt YfcXD+KvqOBHrsiiOHW/9X6K8hvwEH5JlgK9pJnHkHMt6SfCpiBLyGtErDFlkswBfxuPPqJj1d9X 13wC+jofBfuE3HOWgqACoucCvm4fSHLzvw2Qo38+0CFtpNzIBmVsrWPOB1fvbQE6IbX/8rcGthUS mgqcQ76jmKnOrhTlnIk/dmoeVKTpoKIrMJJK1zp//kqSl4Os5AAAAAAAAA== ------=_NextPart_000_012B_01CE09E0.1CCF6040-- From kathleen.moriarty@emc.com Wed Feb 13 11:05:29 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8821F0D0A for ; Wed, 13 Feb 2013 11:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y39hgK6OsIgg for ; Wed, 13 Feb 2013 11:05:23 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 458561F0D08 for ; Wed, 13 Feb 2013 11:05:21 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DJ5KZ9031243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Feb 2013 14:05:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 13 Feb 2013 14:05:05 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DJ511I013531 for ; Wed, 13 Feb 2013 14:05:02 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Wed, 13 Feb 2013 14:05:01 -0500 From: "Moriarty, Kathleen" To: "Harrington, Christopher" , MILE IETF Date: Wed, 13 Feb 2013 14:04:59 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J/nM0FwsOXwAHQbisW5VEKlAi4AACYgwgAAU1dVA= Message-ID: References: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CEBDF2E4MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:05:29 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CEBDF2E4MX15Acorpemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJZiB5b3UgdGhpbmsgb2YgSU9ERUYganVzdCBmb3IgdHJhbnNwb3J0LCBjb3VsZCB5b3UgbWVl dCB5b3VyIG5lZWRzIHdpdGggc3RvcmluZyB0aGUgdmFsdWVzIGRpZmZlcmVudGx5IGluIGEgZGF0 YWJhc2UgKElPREVGIGlzIGp1c3QgbWVhbnQgZm9yIHRoZSBleGNoYW5nZSk/ICBUaGUgbnVtYmVy cyBtYXAgdG8gbG93L21lZC9oaWdoIOKAkyBmb3IgZGIgc3RvcmFnZSDigJMgaWYgbnVtYmVycyBh cmUgdXNlZCwgeW91IGNvdWxkIHN0b3JlIHRoZSBlcXVpdmFsZW50IHZhbHVlLCBhZGRpbmcgdGhl IDIgYWRkaXRpb25hbCBvbmVzIHByb3ZpZGVkLg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gZXhw YW5kIHRoZSBzZXQgb2YgdmFsdWVzIHRvIG1hdGNoIHdoYXQgQ0lGIGlzIGRvaW5nIGlmIHdlIHdl bnQgZm9yd2FyZCB3aXRoIHRoZSBhcHByb2FjaCBvZiBzdXBwb3J0aW5nIGJvdGggb3B0aW9ucz8N Cg0KVGhhbmsgeW91LA0KS2F0aGxlZW4NCg0KRnJvbTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFycmluZ3RvbiwgQ2hy aXN0b3BoZXINClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTMgMTE6NDkgQU0NClRv OiAnQy4gSGVucnkgQWRhbXMgJiBCSUUnOyBNSUxFIElFVEYNClN1YmplY3Q6IFJlOiBbbWlsZV0g SU9Dcw0KDQpGcm9tIGEgZGF0YSBwcm9jZXNzaW5nIHN0YW5kcG9pbnQgaXQgaXMgZ29pbmcgdG8g Y3JlYXRlIGV4dHJhIHdvcmsgZm9yIHRoZSBwZW9wbGUgd2hvIGFyZSBnb2luZyB0byByZWNlaXZl IHRoaXMgZGF0YSBpZiB3ZSBzdXBwb3J0IGJvdGggbnVtZXJpYyBhbmQgYWxwaGEgY2hhcmFjdGVy cyBpbiB0aGUgc2FtZSBmaWVsZC4gSSBjYW4gZW52aXNpb24gcGVvcGxlIHdhbnRpbmcgdG8gc2Vh cmNoLCBzb3J0LCBzdG9yZSwgZXRjIHRoZSBkYXRhIGluIHRoaXMgZmllbGQuIElmIHdlIGFsbG93 IGJvdGggZGF0YSB0eXBlcyB0aGVuIGV2ZXJ5b25lIHdpbGwgbmVlZCB0byBoYXZlIGEgbWFwcGlu ZyBvZiBzb21lIHNvcnQuIEkgaGF2ZSBhIGZpZWxkIGZvciBjb25maWRlbmNlIGluIG15IHRocmVh dCB0cmFja2luZyBkYXRhYmFzZS4gSGF2aW5nIGJvdGggYSBudW1lcmljIHNjb3JlIGFuZCBhbHBo YSBjaGFyYWN0ZXJzIC8gd29yZHMgY3JlYXRlcyBpc3N1ZXMgd2hlbiB0cnlpbmcgdG8gaW50ZXJh Y3Qgd2l0aCB0aGUgZGF0YS4gSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gc3VwcG9ydCBib3RoIGhv d2V2ZXIgSSBkb27igJl0IHRoaW5rIGJvdGggc2hvdWxkIGJlIGluIHRoZSBzYW1lIGZpZWxkLiBJ IHdvdWxkIG11Y2ggcmF0aGVyIHNlZSAyIGRpZmZlcmVudCBmaWVsZHMgZm9yIENvbmZpZGVuY2Ug aWYgd2UgYXJlIGdvaW5nIHRvIHN1cHBvcnQgMiBkaWZmZXJlbnQgZGF0YSB0eXBlcy4NCg0KVGhp cyB3aWxsIGJlIGEgbGFyZ2VyIGlzc3VlIHNob3VsZCBDb25maWRlbmNlIGJlIHVzZWQgZWxzZXdo ZXJlLiBJZGVhbGx5IGluIGZ1dHVyZSByZXZpc2lvbnMgSSB3b3VsZCBsaWtlIHRvIHNlZSBhdHRy aWJ1dGlvbiBleHByZXNzZWQgYXMgIHNvbWUgZm9ybSBvZiBhdHRyaWJ1dGlvbiBpcyBhbG1vc3Qg YWx3YXlzIHNoYXJlZCB3aXRoIGFuIElvQy4gIEN1cnJlbnRseSB0aGVyZSBhcmUgNSBhcmVhcyB3 aGVyZSB3ZSAgKEVNQykgdXNlcyBjb25maWRlbmNlLg0KDQpJbmRpY2F0b3IgKGhvdyBjb25maWRl bnQgYXJlIHlvdSB0aGF0IHRoaXMgaXMgYSB2YWxpZCBJb0MpDQpJbmRpY2F0b3JfU2V0IChob3cg Y29uZmlkZW50IGFyZSB5b3UgdGhhdCBhbGwgb2YgdGhlIGluZGNhdG9ycyBpbiB0aGUgc2V0IHNo b3VsZCBiZSBpbiB0aGUgc2V0KQ0KQ2FtcGFpZ24gKGhvdyBjb25maWRlbnQgYXJlIHlvdSB0aGF0 IGFsbCBJbmRpY2F0b3JfU2V0cyBhcmUgcGFydCBvZiB0aGlzIGNhbXBhaWduKQ0KVGhyZWF0IEFj dG9yIChob3cgY29uZmlkZW50IGFyZSB5b3UgdGhhdCB0aGUgQ2FtcGFpZ24gaXMgYXR0cmlidXRl ZCB0byB0aGlzIFRocmVhdCBBY3RvcikNClRocmVhdCBBY3RvciB0eXBlIChob3cgY29uZmlkZW50 IGFyZSB5b3UgdGhhdCB0aGlzIFRoZWF0IEFjdG9yIGlzIEFQVCwgQ3JpbWV3YXJlLCBvdGhlcikN Cg0KVGhlIHRocmVhdCBhY3RvciBuYW1lIGFuZCB0aGUgdGhyZWF0IGFjdG9yIHR5cGUgYXJlIHVz dWFsbHkgdGhlIGZpcnN0IDIgdGhpbmdzIHRoYXQgYW55b25lIHByb2Nlc3NpbmcgSW9DcyB3YW50 cyB0byBrbm93IGFzIHRoZXkgZHJpdmUgcHJpb3JpdHkuICBLbm93aW5nIGhvdyBzdXJlIHRoZSBz ZW5kZXIgaXMgdGhhdCB0aGlzIElvQyBpcyBBUFRpcyBhIHZpdGFsIHBpZWNlIG9mIGluZm9ybWF0 aW9uIGZvciB1cy4gIFNvcnJ5IHRvIHRha2UgdXMgYSBsaXR0bGUgb2ZmIHRoZSBwYXRoIGJ1dCBJ IHdhbnRlZCB0byBzaG93IHdoZXJlIENvbmZpZGVuY2UgY291bGQgYmUgdXNlZC4NCg0KVGhhbmtz LA0KLS1DaHJpcw0KDQpGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1pbGUtYm91 bmNlc0BpZXRmLm9yZz4gW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDLiBIZW5yeSBBZGFtcyAmIEJJRQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMywgMjAx MyAxMDoyNCBBTQ0KVG86IE1JTEUgSUVURg0KU3ViamVjdDogUmU6IFttaWxlXSBJT0NzDQoNCkFn YWluLCBJIHdvdWxkIGNvbmN1ciB0aGF0IGJvdGggYSBudW1lcmljIGFuZCBzdWJqZWN0aXZlIGFu YWx5c2lzIG9mIHRoZSBDb25maWRlbmNlIFJhdGluZyBuZWVkcyB0byBiZSBleHByZXNzLCBidXQg Y29tYmluZWQgaW4gYSBzaW1wbGlmaWVkIHNjaGVtYSBhcyBzdWNoIGJlbG93Og0KDQo8Q29uZmlk ZW5jZSByYXRpbmc9IiBBbHBoYW51bWVyaWMiPjFMTDwvPiAuLi4uIGV0Yy4NCg0KPENvbmZpZGVu Y2UgcmF0aW5nPSIgQWxwaGFudW1lcmljIj4yUDwvPg0KDQo8Q29uZmlkZW5jZSByYXRpbmc9IiBB bHBoYW51bWVyaWMiPjNBQzwvPg0KDQo8Q29uZmlkZW5jZSByYXRpbmc9IiBBbHBoYW51bWVyaWMi PjRVPC8+DQoNCjxDb25maWRlbmNlIHJhdGluZz0iIEFscGhhbnVtZXJpYyI+NUk8Lz4NCiggaS5l LiAgMSA9IExlc3MgTGlrZWx5LCAgIDIgPSBQcm9iYWJsZSwgIDMgPSBBIENvbmNlcm4sICA0ID0g IFVyZ2VudCwgNSA9IEltbWluZW50ICkNCg0KSGVyZSdzIG15IHBvaW50LCBwZXJoYXBzIGEgc2V0 IG9mIG51bWVyaWMgcmVsYXRlZCBvciBhc3NvY2lhdGVkIGRlZmluaXRpb25zIGNhbiBsb3dlciB0 aGUgcHJvcGFnYXRpb24gb2YgZXJyb3IgcmVnYXJkaW5nIHRoZSBhbmFseXNpcy4NCg0KVGhhbmtz LA0KQy4gSGVucnkgQWRhbXMNCg0KDQpJIGFncmVlIHRoYXQgd2hhdCB3ZSByZWFsbHkgbmVlZCBp cyBib3RoLiAgSW4gbW9zdCBzaXR1YXRpb25zIGEgbG93LCBtZWRpdW0gYW5kIGhpZ2ggbWF5IGJl IGFjY2VwdGFibGUgYnV0IHRoZXJlIGFyZSB0aW1lcyB3aGVuIHdlIHdpbGwgd2FudCB0byBzaG93 IHRoYXQgY29uZmlkZW5jZSBpbiBhIHNpdHVhdGlvbiBpcyBpbmNyZWFzaW5nIG9yIGRlY3JlYXNp bmcuICBJZiB3ZSBhcmUgb25seSBsb29raW5nIGF0IGEgdGhyZWUgbGV2ZWxzLCB3ZSBjYW5ub3Qg ZXhwcmVzcyB3aGF0IGlzIG5lZWRlZCB0byBzaG93IGNvbmZpZGVuY2UgaXMgdHJlbmRpbmcgdXAg b24gdGhlIGRhdGEgYmVpbmcgZXhjaGFuZ2VkIGFib3V0IHRoZSBldmVudC4NCg0KS2F0aGxlZW4g aW5jbHVkZWQgdGhlIGZvbGxvd2luZyBpbiBhIHByZXZpb3VzIG1lc3NhZ2UuDQoNCjxDb25maWRl bmNlIHJhdGluZz0ibG93Ii8+DQoNClZzOg0KDQo8Q29uZmlkZW5jZSByYXRpbmc9Im51bWVyaWMi Pjg1PC8+DQoNCkkgcmVhbGx5IHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVkZSBib3RoIGNhcGFiaWxp dGllcyBhcyBKb2huIGFsbHVkZWQgdG8gc2luY2UgY29uZmlkZW5jZSBpcyBub3QgYSB0aHJlZSB0 aWVyZWQgaXRlbSBidXQgc29tZXRoaW5nIHRoYXQgaXMgaW5kZWVkIHN1YmplY3RpdmUgYW5kIHdl IG5lZWQgYSBtZWFucyB0byBzaG93IGEgcmVhc29uYWJseSBhY2N1cmF0ZSBjb25maWRlbmNlIGlu ZGV4IHRoYXQgdGhlIHNlbmRlciBpcyB0cnlpbmcgdG8gY29udmV5Lg0KDQpLZW50IExhbmRmaWVs ZA0KDQpNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55DQpEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5Ng0K TW9iaWxlOiArMS44MTcuNjM3LjgwMjYNCldlYjogd3d3Lm1jYWZlZS5jb208aHR0cDovL3d3dy5t Y2FmZWUuY29tLz4NCg0KRnJvbTogPEJhbmdoYXJ0PiwgSm9obiBCYW5naGFydCA8am9obi5iYW5n aGFydEBuaXN0LmdvdjxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90 bz1qb2huLmJhbmdoYXJ0QG5pc3QuZ292Pj4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMs IDIwMTMgNzoxNiBBTQ0KVG86ICJTdG9lY2tlciwgUGF1bCIgPFBhdWwuU3RvZWNrZXJAcnNhLmNv bTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1QYXVsLlN0b2Vj a2VyQHJzYS5jb20+PiwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5QGVtYy5j b208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89a2F0aGxlZW4u bW9yaWFydHlAZW1jLmNvbT4+LCBCcmlhbiBUcmFtbWVsbCA8dHJhbW1lbGxAdGlrLmVlLmV0aHou Y2g8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89dHJhbW1lbGxA dGlrLmVlLmV0aHouY2g+Pg0KQ2M6ICJDLiBIZW5yeSBBZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAw QHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1j aGF0bGdhMjAwMEB5YWhvby5jb20+PiwgTUlMRSBJRVRGIDxtaWxlQGlldGYub3JnPGh0dHA6Ly91 cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFttaWxlXSBJT0NzDQoNClBhdWwsDQoNCkkgYWdyZWUgdGhhdCBjb25maWRlbmNl IGlzIHN1YmplY3RpdmUsIGJ1dCBzdWJqZWN0aXZpdHkgY2FuIGJlIHJlZHVjZWQNCndpdGhpbiBj b21tdW5pdGllcyB0aGF0IGludGVyYWN0IGZyZXF1ZW50bHkuICBQcmlvcml0aXphdGlvbiBvZiBp bmRpY2F0b3JzDQphbmQgcmVzcG9uc2UgYmV0d2VlbiB0aWdodGx5IGNvbm5lY3RlZCBzaGFyaW5n IHBhcnRuZXJzIG1pZ2h0IHJlcXVpcmUgYQ0KbW9yZSBzcGVjaWZpYyBsZXZlbCBvZiBkZXRhaWws IHBhcnRpY3VsYXJseSBkdXJpbmcgYSBjcmlzaXMgc2l0dWF0aW9uLg0KDQpGcm9tIHRoYXQgcGVy c3BlY3RpdmUsIEkgdGhpbmsgdGhlIGd1aWRhbmNlIHNob3VsZCBhbGxvdyBmb3IgYWRkaXRpb25h bA0KZ3JhbnVsYXJpdHksIHdoaWxlIHN0cmVzc2luZyB0aGUgImhpZ2gsIG1lZGl1bSwgbG93IiBh cyBwcmVmZXJyZWQgZm9yDQpicm9hZCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQotSm9obg0KDQpPbiAy LzEzLzEzIDg6MDQgQU0sICJTdG9lY2tlciwgUGF1bCIgPFBhdWwuU3RvZWNrZXJAcnNhLmNvbTxo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1QYXVsLlN0b2Vja2Vy QHJzYS5jb20+PiB3cm90ZToNCg0KSSBtYXkgaGF2ZSBiZWVuIHRvbyBzdWNjaW5jdCBpbiBteSBy ZXNwb25zZSA7LSkNCg0KQ29uZmlkZW5jZSBpcyBhIHN1YmplY3RpdmUgdGhpbmcsIHNvIEkgdGhp bmsgd2Ugc2hvdWxkIHVzZSBzdWJqZWN0aXZlDQp0ZXJtczogIExvdywgTWVkaXVtLCBIaWdoLiAg SGF2aW5nIGEgbnVtZXJpYyBzY2FsZSB3aXRoIGEgbWFwIHRoYXQNCmVzc2VudGlhbGx5IHdvdWxk IHNheSBzb21ldGhpbmcgbGlrZToNCg0KMS0zMyA9IExvdw0KMzQtNjc9IE1lZGl1bQ0KNjgtMTAw PUhpZ2gNCg0KSXMganVzdCBhIG1vcmUgY29tcGxpY2F0ZWQgd2F5IG9mIHNheWluZyB0aGF0IHNv bWV0aGluZyBpcyBMb3csIE1lZGl1bSwNCkhpZ2guLi5kbyB3ZSByZWFsbHkgdGhpbmcgdGhhdCBo b3cgSGlnaCBzb21ldGhpbmcgaXMgbWFrZXMgdGhhdCBtdWNoIG9mIGENCmRpZmZlcmVuY2U/DQoN ClRoaXMgaXMgbGlrZSB3aGVuIHlvdSBnZXQgeW91ciBQZXJmb3JtYW5jZSByZXZpZXcgd2hlcmUg aXQgaXMgRG9lcyBOb3QNCk1lZXQsIE1lZXRzIGFuZCBFeGNlZWRzLi4ueW91ciBib3NzIHRlbGxz IHlvdSB0aGF0IHlvdSBhcmUgYSBIaWdoDQpNZWV0cy4uLnlvdXINCmJvbnVzIHRlbGxzIHlvdSB0 aGF0IHlvdSBnb3QgdGhlIHNhbWUgYm9udXMgdGhhdCBhbGwgdGhlIG90aGVyIE1lZXRzIGdvdA0K Oy0pDQoNCkFueXdheSwgSSBkaWdyZXNzIGJ1dCB0cnlpbmcgdG8gcHJvdmUgYSBwb2ludCB0aGF0 IEkgd291bGQgYXJndWUgdGhhdA0KY29uZmlkZW5jZSBpbiB0aGlzIGNhc2UgaXMgZ29pbmcgdG8g YmUgYmFzaWNhbGx5IGEgZ3V0IGZlZWxpbmcsIHNvIHdoeSB1c2UNCm51bWVyaWMgdmFsdWVzIHdo ZW4gTG93LCBNZWRpdW0sIEhpZ2ggd291bGQgZG8ganVzdCBmaW5lLg0KDQoNClBhdWwgVy4gU3Rv ZWNrZXIsIFBoLkQuDQpTTUMgTGVhZCBDb250ZW50IEFyY2hpdGVjdA0KUlNBLCBUaGUgU2VjdXJp dHkgRGl2aXNpb24gb2YgRU1DDQpjZWxsOiAzMDIuMzc5LjMzNzUgfCBlOiBwYXVsLnN0b2Vja2Vy QHJzYS5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89cGF1 bC5zdG9lY2tlckByc2EuY29tPg0KDQoNCg0KDQoNCg0KT24gMi8xMy8xMyA3OjQ4IEFNLCAiTW9y aWFydHksIEthdGhsZWVuIiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTxodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29t Pj4NCndyb3RlOg0KDQpIZWxsbywNCg0KQm90aCBhcHByb2FjaGVzIHdpbGwgdmFsaWRhdGUgaW4g dGhlIGN1cnJlbnQgc2NoZW1hLiAgVGhlIHJlcHJlc2VudGF0aW9uDQpsb29rcyBhIGxpdHRsZSBk aWZmZXJlbnQgZm9yIGVhY2gsIGhlcmUgaXMgYW4gZXhhbXBsZToNCg0KPENvbmZpZGVuY2UgcmF0 aW5nPSJsb3ciLz4NCg0KVnM6DQoNCjxDb25maWRlbmNlIHJhdGluZz0ibnVtZXJpYyI+ODU8Lz4N Cg0KU2VhcmNoaW5nIGNhcGFiaWxpdHkgaXMgYSBncmVhdCBwb2ludCwgYWdyZWVkLiAgSSdkIGxp a2UgdG8gaGVhciBmcm9tDQptb3JlIHBlb3BsZSB0byBtYWtlIHN1cmUgd2UgZG9uJ3QgbG9zZSBh IGNhcGFiaWxpdHkgdGhhdCBvdGhlcnMgZmluZA0KZXh0cmVtZWx5IHVzZWZ1bCAobmVlZCB0byBn YXVnZSB0aGF0KS4gIE90aGVyIG9wdGlvbnMgaXMgdGhhdCB0aGUNCmd1aWRhbmNlIGNhbiBhbHNv IGRpc2NvdXJhZ2UgdGhlIHVzZSBvZiB0aGUgbnVtZXJpYyBpbiBhZGRpdGlvbiB0bw0Kc3BlY2lm eWluZyBob3cgdG8gc2VsZWN0IHJhbmdlcy4NCg0KQW55IG90aGVyIG9waW5pb25zPw0KDQpUaGFu a3MsDQpLYXRobGVlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RvZWNr ZXIsIFBhdWwNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTMgNzoxNCBBTQ0KVG86 IEJyaWFuIFRyYW1tZWxsDQpDYzogTW9yaWFydHksIEthdGhsZWVuOyBDLiBIZW5yeSBBZGFtcyAm IEJJRTsgTUlMRSBJRVRGDQpTdWJqZWN0OiBSZTogW21pbGVdIElPQ3MNCg0KQ2FudCB3ZSBtYWtl IENvbmZpZGVuY2UgYSBMaXN0IHRoYXQgaGFzIG9ubHkgMyB2YWx1ZXM6ICBIaWdoLCBNZWRpdW0s IGFuZA0KTG93PyAgQW55IG90aGVyIHZhbHVlIG1lYW5zIHRoYXQgdGhlIERvY3VtZW50IHdpbGwg bW90IHZhbGlkYXRlIGFnYWluc3QNCnRoZSBzY2hlbWEuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KT24gRmViIDEzLCAyMDEzLCBhdCAyOjE0IEFNLCAiQnJpYW4gVHJhbW1lbGwiIDx0cmFtbWVs bEB0aWsuZWUuZXRoei5jaDxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9z ZT90bz10cmFtbWVsbEB0aWsuZWUuZXRoei5jaD4+DQp3cm90ZToNCg0KSGksIEthdGhsZWVuLCBh bGwsDQoNCkkgdGhpbmsgMy4xMC40IGluIDUwNzAgdGFrZXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGhl cmU6IHRyeWluZyB0byBidWlsZA0KaW50ZXJvcGVyYWJsZSBudW1lcmljIHNjYWxlcyBmb3IgYXNz ZXNzbWVudCBpcyBhIHZlcnkgaGFyZCBwcm9ibGVtLg0KKFdlcmUgSSBjaGFyZ2VkIHdpdGggZGVm aW5pbmcgc3VjaCBhIHNjYWxlLCB0aGUgdmFsdWUgIjcwIiB3b3VsZCBtZWFuDQoid2UgY29tcGFy ZWQgdGhpcyBpbmNpZGVudCByZXBvcnQgdG8gTiBwYXN0IHNpbWlsYXIgaW5jaWRlbnQgcmVwb3J0 cw0KYWNjb3JkaW5nIHRvIHNpbWlsYXJpdHkgYWxnb3JpdGhtIFMsIGFuZCA3MCUgb2YgdGhlIHBh c3QgcmVwb3J0cyBoYWQNCmFzc2Vzc2VkIGltcGFjdHMgd2l0aGluIEUlIG9mIHRoZSBhY3R1YWws IG1lYXN1cmVkIGZpbmFsIGltcGFjdCAtLSBJDQp0aGluayBmb3IgbW9zdCBhcHBsaWNhdGlvbnMg dGhpcyBpcyB2YXN0bHkgbW9yZSBkaWZmaWN1bHQgYW5kIHJpZ29yb3VzDQp0aGFuIGl0IG5lZWRz IHRvIGJlLikNCg0KVW5sZXNzIGEgbnVtZXJpYyBDb25maWRlbmNlIHZhbHVlIGlzIGJhc2VkIG9u IHNvbWUgYWN0dWFsLCByZXBlYXRhYmx5DQptZWFzdXJhYmxlIGFzcGVjdCBvZiB0aGUgQXNzZXNz bWVudCByZXBvcnQgLS0gd2hpY2ggSSBzdXNwZWN0IGluDQptYW55L21vc3QvYWxsIGNhc2VzIGl0 J3Mgbm90IC0tIHRoZW4gaXQganVzdCByZXByZXNlbnRzIGEgZ3Vlc3MsIGhvd2V2ZXINCmVkdWNh dGVkLiAgRWFjaCB0ZWFtIHdpbGwgcHJvYmFibHkgbmF0dXJhbGx5IHR1bmUgaXRzIG93biBzY2Fs ZXMgc3VjaA0KdGhhdCBlYWNoIHZhbHVlIGdlbmVyYWxseSBtZWFucyB0aGUgc2FtZSB0aGluZyBp biBlYWNoIHJlcG9ydC4gQWNyb3NzDQp0ZWFtcywgSSBkb24ndCBrbm93Lg0KDQpPbiB0aGUgb3Ro ZXIgaGFuZCwgQXNzZXNzbWVudHMgYXJlIGJ5IHRoZWlyIHZlcnkgbmF0dXJlIGVkdWNhdGVkDQpn dWVzc2VzLCBhbnl3YXksIHNvIEkgZG9uJ3Qga25vdyB0aGF0IEknZCBmaW5kIG11Y2ggdXNlIGlu IGF1dG9tYXRpbmcgYQ0KcmVzcG9uc2UgYmFzZWQgb24gdGhlIGFzc2Vzc21lbnQgY29uZmlkZW5j ZS4gQ2hyaXMgaGFzIGEgZ29vZCBwb2ludCwNCnRob3VnaCAtLSBpdCBtYWtlcyBzZWFyY2hpbmcg ZGlmZmljdWx0IGFuZCBzb3J0aW5nIGtpbmQgb2YgcG9pbnRsZXNzLg0KDQpJZiB3ZSd2ZSBzZWVu IGEgZ2VuZXJhbCB0cmVuZCB0b3dhcmQgIjAgPSAwJSwgMTAwID0gMTAwJSIsIHRoZW4gSQ0KYWdy ZWUsIHdlIHNob3VsZCBwdXQgdGhhdCBpbiB0aGUgZ3VpZGFuY2UgZG9jdW1lbnQgKGFsb25nIHdp dGggYSBub3RlDQp0aGF0IDAtMzMgbWFwIHRvIGxvdywgMzQgLSA2NiBtYXAgdG8gbWVkaXVtLCBh bmQgNjcgLSAxMDAgbWFwIHRvIGhpZ2gsDQp1bmxlc3Mgd2Ugd2FudCB0byBkbyBpdCBub24tbGlu ZWFybHkpLiBJZiB0aGUgX3Zhc3RfbWFqb3JpdHlfIG9mIHRoZQ0KdXNlcnMgb2YgdGhpcyBmaWVs ZCB1c2UgYSAxMDAtcG9pbnQgc2NhbGUgd2l0aCAxMDAgbWVhbmluZyAieWVzIiBhbmQgMA0KbWVh bmluZyAiYW55IHJlc2VtYmxhbmNlIHRoZXNlIHZhbHVlcyBtYXkgaGF2ZSB0byBhY3R1YWwgZmFj dCBpcyBwdXJlbHkNCmNvaW5jaWRlbnRhbCIsIHRoZW4gbGV0J3MgY29uc2lkZXIgcmVuYW1pbmcg aXQgInBlcmNlbnQiIGluIDUwNzAtYmlzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkJyaWFuIChhcyBj b250cmlidXRvcikNCg0KDQpPbiBGZWIgMTIsIDIwMTMsIGF0IDk6NTYgUE0sICJNb3JpYXJ0eSwg S2F0aGxlZW4iDQo8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTxodHRwOi8vdXMubWM1MzQubWFp bC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPj4gd3Jv dGU6DQoNClBsZWFzZSBzZWUgc2VjdGlvbiAzLjEwLjQgb2YgUkZDNTA3MCBhcyBhIHN0YXJ0aW5n IHBvaW50LiAgV2UgY2FuDQpjaGFuZ2UgaXQgaWYgaXQgbmVlZHMgdG8gYmUgY2hhbmdlZC4gIFRo ZSB2YWx1ZSBpcyBmb3IgYSBjb25maWRlbmNlDQpyYXRpbmcgb24gdGhlIGluZGljYXRvcnMgc2hh cmVkLiAgVGhlIGRlZmluaXRpb25zIG1heSBiZSBoZWxwZnVsIGZvcg0KYW55b25lIHdobyB3YW50 cyB0byB3b3JrIG9uIHRoaXMgZGlzY3Vzc2lvbi4gIElPREVGIGhhcyB2YXJpb3VzIG1hcmtlcnMN CnRoYXQgY2FuIGJlIHVzZWQgaW4gYSBjb21wbGltZW50YXJ5IHdheSB3aXRob3V0IGNvbmZsYXRp bmcgdGhlIG1hcmtlcnMNCm1lYW5pbmcuDQoNCkkgdGhpbmsgc29tZSBwZW9wbGUgdXNpbmcgSU9E RUYgZmluZCB0aGUgbnVtZXJpY2FsIHZhbHVlcyBtb3JlDQpoZWxwZnVsLCBhbmQgaXQgd291bGQg YmUgZ29vZCB0byB1bmRlcnN0YW5kIHdoYXQgcGVvcGxlIGhhdmUgbGVhcm5lZA0KZnJvbSB1c2lu ZyB0aGUgY3VycmVudCBzdHJ1Y3R1cmUgKHdoYXQgd29ya3MvZG9lcyBub3Qgd29yaykuICBUaGUN CnNjYWxlcyBJIGhhdmUgc2VlbiBhcmUgMC0xMDAuICBUaGVyZSBpcyBvZiBjb3Vyc2UgYSBzdWJq ZWN0aXZlIGVsZW1lbnQNCnRvIGFzc2lnbmluZyBhIG51bWVyaWNhbCB2YWx1ZSB0byB0aGUgY29u ZmlkZW5jZSBhbmQgaXQgbWF5IHZhcnkgZnJvbQ0KZW50aXR5IHRvIGVudGl0eS4gIFdpdGggdGhp cyB0eXBlIG9mIHJhdGluZyB5b3UgbWF5IG5lZWQgdG8gY29uc2lkZXINCndobyBpdCBjYW1lIGZy b20gYW5kIGhvdyB0aGV5IHNjb3JlZCB0aGUgY29uZmlkZW5jZSByYXRpbmcgdG8gbWFwIHRvDQp5 b3VyIG93biByYXRpbmcuICBJdCB3b3VsZCBiZSBnb29kIHRvIGhlYXIgbW9yZSB0aG91Z2h0cyBv biB0aGlzLg0KDQpUaGFua3MsDQpLYXRobGVlbg0KDQpGcm9tOiBDLiBIZW5yeSBBZGFtcyAmIEJJ RSBbbWFpbHRvOmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhv by5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+XQ0KU2VudDogVHVlc2Rh eSwgRmVicnVhcnkgMTIsIDIwMTMgMjo0NiBQTQ0KVG86IE1JTEUgSUVURg0KQ2M6IE1vcmlhcnR5 LCBLYXRobGVlbjsgJ1Rha2VzaGkgVGFrYWhhc2hpJzsgU3RvZWNrZXIsIFBhdWwNClN1YmplY3Q6 IFJlOiBbbWlsZV0gSU9Dcw0KDQoNClJlZ2FyZGluZyB0aGUgSU9DcyBvciBJbmRpY2F0b3JzIG9m IENvbXByb21pc2UsIENocmlzIG1hZGUgYSB2aXRhbA0KcG9pbnQuICBEaWZmZXJlbnQgQ29uZmlk ZW5jZSBsZXZlbHMgd2lsbCBjYXVzZSBjb25mdXNpb24uICBJdCBhcHBlYXJzDQp0aGF0IHRoZXJl IG1heWJlIGEgbmVlZCBmb3Igc29tZSB0eXBlIG9mIHNpbXBsaWZpZWQgc3RhbmRhcmRpemF0aW9u IHRvDQpiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIGFsbCBTaGFyaW5nIEdyb3VwcyBpbiB0aGlzIHJl Z2FyZC4NCg0KUGVyaGFwcyBudW1lcmljYWwgc2NvcmluZyBzZXQgYXQgbG93ZXIgdmFsdWVzIHNo b3VsZCBleHByZXNzIGxldmVscyBvZg0KdXJnZW5jeS4NCiggaS5lLiAgMSA9IExlc3MgTGlrZWx5 LCAgIDIgPSBQcm9iYWJsZSwgIDMgPSBBIENvbmNlcm4sICA0ID0gIFVyZ2VudCwNCjUgPSBJbW1p bmVudCApDQoNClRoYW5rcywNCkMuIEhlbnJ5IEFkYW1zDQoNCg0KDQpJIHNlZSBzb21lIGNvbmZ1 c2lvbiBjb21pbmcgZG93biB0aGUgcGlrZSBpZiB3ZSBzdGFydCB1c2luZyBDb25maWRlbmNlDQp0 aGUNCndheSBpdCBpcyBzdXBwb3J0ZWQuIElmIEkgYW0gdXNpbmcgbG93L21lZC9oaWdoIGFuZCBz b21lb25lIHNlbmRzIG1lDQphbiBJb0MNCndpdGggYSBzY29yZSBvZiA3MCwgd2hhdCBkb2VzIHRo YXQgbWVhbiB0byBtZT8gV2hhdCBpZiBJIGFtIHVzaW5nIGENCnNjYWxlIG9mDQoxIHRvIDQgYW5k IHNvbWVvbmUgZWxzZSBpcyBvbiBhIHNjYWxlIG9mIDEgdG8gNT8gV2UgbG9zZSB0aGUgYWJpbGl0 eQ0KdG8NCmRlc2NyaWJlIHNvbWV0aGluZyB3aXRoIGEgY29uc2lzdGVudCBsYW5ndWFnZS4gSXQg cmVhbGx5IGdldHMgdWdseQ0Kd2hlbiB3ZQ0Kc3RvcmUgSW9DIGZyb20gbXVsdGlwbGUgc291cmNl cy4gSSBoYXZlIGNvbmZpZGVuY2UgdmFsdWVzIHRoYXQgYXJlDQpudW1lcmljDQphcyB3ZWxsIGFz IHRleHQuICBNYWtlcyBzZWFyY2hpbmcgLyBzb3J0aW5nIHZlcnkgcHJvYmxlbWF0aWMuDQoNCkF0 IHRoaXMgcG9pbnQgd2UgaGF2ZSB0byByb2xsIHdpdGggd2hhdCB3ZSBoYXZlLiBJIHdvdWxkIHN0 cm9uZ2x5DQpyZWNvbW1lbmQNCnRoYXQgd2UgcmV2aXNpdCB0aGlzIGF0IHNvbWUgcG9pbnQuDQoN ClRoYW5rcywNCg0KLS1DaHJpcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TW9yaWFydHksIEthdGhsZWVuDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyA5OjU5 IEFNDQpUbzogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7ICdUYWtlc2hpIFRha2FoYXNoaSc7IFN0 b2Vja2VyLCBQYXVsOw0KJ01JTEUNCklFVEYnDQpTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCg0K SGkgQ2hyaXMgJiBUYWtlLA0KDQpJJ2xsIGp1c3QgZm9jdXMgb24gdGhlIGNvbmZpZGVuY2Ugc2Nv cmluZy4gIFJpZ2h0IG5vdywgdGhlIHNjaGVtYQ0KYWxsb3dzIGZvcg0KeW91IHRvIGVpdGhlciB1 c2UgYSBudW1lcmljYWwgc2NvcmUgT1IgdGhlIHJhdGluZ3Mgb2YgbG93LCBtZWRpdW0sIGFuZA0K aGlnaC4NCkRpZmZlcmVudCBzaGFyaW5nIGdyb3VwcyBjYW4gZGVjaWRlIGhvdyB0aGV5IHdhbnQg dG8gc2hhcmUgdGhlIGRhdGEuDQpJZg0KcGVvcGxlIHdlcmUgdG8gdXNlIHRoZSBudW1lcmljYWwg dmFsdWVzLCBJIGFncmVlIGl0IHdvdWxkIGJlIGhlbHBmdWwNCnRvIGhhdmUNCmd1aWRhbmNlLiAg VGhpcyBjb3VsZCBnbyBpbiB0aGUgSU9ERSBndWlkYW5jZSBkb2N1bWVudC4NCg0KSSBoYXZlIHNl ZW4gZXhhbXBsZXMgb2YgY3VycmVudCB1c2VycyB0aGF0IHVzZSBlYWNoIG9mIHRoZSBhcHByb2Fj aGVzLA0Kc28NCndlJ2xsIG5lZWQgdG8ga2VlcCB0aGUgb3B0aW9uIGZvciBiYWNrd2FyZHMgY29t cGF0aWJpbGl0eSBhbmQgaXQgaXMNCm5pY2UgdG8NCmtlZXAgaW4gZmxleGlibGUgb3B0aW9ucyB3 aGVyZSB3ZSBjYW4uDQoNClRoYW5rIHlvdSwNCkthdGhsZWVuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcg0KU2VudDogVHVlc2RheSwg RmVicnVhcnkgMTIsIDIwMTMgOToyMiBBTQ0KVG86ICdUYWtlc2hpIFRha2FoYXNoaSc7IE1vcmlh cnR5LCBLYXRobGVlbjsgU3RvZWNrZXIsIFBhdWw7ICdNSUxFDQpJRVRGJw0KU3ViamVjdDogUkU6 IFttaWxlXSBJT0NzDQoNClRoZSBudW1iZXIgb2YgaW5kaWNhdG9ycyB3b3VsZG4ndCBuZWNlc3Nh cmlseSBkcml2ZSB0aGUgdXNlIG9mDQppbmRpY2F0b3Jfc2V0X2lkLiBUaGUgcHVycG9zZSBpcyB0 byBzaG93IHJlbGF0aW9uc2hpcC4gSWYgSSBzZW50IDMgSVANCmFkZHJlc3NlcyB0aGF0IHdlcmUg dXNlZCBhcyBDMiBmb3IgMyBkaWZmZXJlbnQgY2FtcGFpZ25zIEkgd291bGQgaGF2ZQ0Kc2VwYXJh dGUgaW5kaWNhdG9yX3NldF9pZHMsIGVhY2ggd2l0aCBvbmUgb2YgdGhlIDMgQzIgSVBzDQoNCk15 IHN1Z2dlc3Rpb24gd291bGQgYmUgYSBzaW1wbGUgbG93LCBtZWRpdW0sIGhpZ2guIEkgdGhpbmsg aWYgd2UgYnJlYWsNCml0DQpkb3duIHRvIG1vcmUgbGV2ZWxzIHRoYW4gdGhhdCB3ZSB3b3VsZCBu ZWVkIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24NCnNjb3JpbmcsDQpyYXRpbmcsIGV0Yy4gSSB0aGlu ayBtb3N0IHBlb3BsZSBzaG91bGQgYmUgYWJsZSB0byB1bmRlcnN0YW5kDQpsb3cvbWVkL2hpZ2gN CndpdGhvdXQgaGF2aW5nIHRvIGhhdmUgYSBtYXRoZW1hdGljYWwgbWV0aG9kIGZvciBhcnJpdmlu ZyBhdCB0aGUNCmxldmVsLg0KDQpMb3cgLSBJIGFtIG5vdCBzdXJlDQpNZWRpdW0gLSBJIGFtIHJl YXNvbmFibHkgc3VyZQ0KSGlnaCAtIEkgYW0gdmVyeSBzdXJlDQoNCg0KVGhhbmtzLA0KDQotLUNo cmlzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUYWtlc2hpIFRha2FoYXNo aSBbbWFpbHRvOnRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanA8aHR0cDovL3VzLm1jNTM0Lm1h aWwueWFob28uY29tL21jL2NvbXBvc2U/dG89dGFrZXNoaV90YWthaGFzaGlAbmljdC5nby5qcD5d DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyA0OjIxIEFNDQpUbzogSGFycmluZ3Rv biwgQ2hyaXN0b3BoZXI7IE1vcmlhcnR5LCBLYXRobGVlbjsgU3RvZWNrZXIsIFBhdWw7ICdNSUxF DQpJRVRGJw0KU3ViamVjdDogUkU6IFttaWxlXSBJT0NzDQoNClJlZ2FyZGluZyB0aGUgaW5kaWNh dG9yX3NldF9pZCwgSSBhZ3JlZSwgaXQgaXMgdXNlZnVsIHdoZW4gd2UgbmVlZCB0bw0KZGVhbA0K d2l0aCBsYXJnZSBzZXRzIG9mIGluZGljYXRvcnMuDQpTaW5jZSBpbmRpY2F0b3Jfc2V0X2lkIGF0 dHJpYnV0ZSBpcyBvcHRpb25hbCAocmlnaHQ/KSwgaXQgY291bGQgYmUNCm9taXR0ZWQNCmlmIHdl IG5lZWQgdG8gZGVhbCB3aXRoIG9ubHkgc21hbGwgbnVtYmVyIG9mIGluZGljYXRvcnMuDQoNClJl Z2FyZGluZyB0aGUgdXNlIGNhc2UsIEkgbGlrZSB0aGUgaWRlYSBvZiB1c2luZyB0aGUgY29uZmlk ZW5jZQ0KYXR0cmlidXRlDQpmb3IgdGhlIHJlYXNvbiBDaHJpcyBraW5kbHkgZGVzY3JpYmVkLg0K SSB3b3VsZCBsaWtlIHRvIGhlYXIgYSBiaXQgbW9yZSBvbiB0aGlzOiBpcyBpdCBnb2luZyB0byBi ZSBudW1lcmljYWw/DQpGb3INCmluc3RhbmNlLCAxIG1lYW5zICJubyBjb25maWRlbmNlIiB3aGls ZSA1IG1lYW5zICJzdHJvbmcgY29uZmlkZW5jZSIsDQpldGM/DQoNClRoYW5rIHlvdS4NClRha2UN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFycmluZ3RvbiwgQ2hyaXN0 b3BoZXIgW21haWx0bzpDaHJpc3RvcGhlci5IYXJyaW5ndG9uQGVtYy5jb208aHR0cDovL3VzLm1j NTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Q2hyaXN0b3BoZXIuSGFycmluZ3RvbkBl bWMuY29tPl0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDgsIDIwMTMgNDoxMSBBTQ0KVG86IE1v cmlhcnR5LCBLYXRobGVlbjsgVGFrZXNoaSBUYWthaGFzaGk7IFN0b2Vja2VyLCBQYXVsOyAnTUlM RQ0KSUVURicNClN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KDQpXaXRoIHJlc3BlY3QgdG8gdHlp bmcgdGhpbmdzIGJhY2sgdG8gdGhyZWF0IGFjdG9ycywgZnJvbSB3aGF0IEkgaGF2ZQ0Kc2VlbiBh bmQgdXNlIHRoaXMgaXMgYSBnZW5lcmFsbHkgYWNjZXB0ZWQgZ3JvdXBpbmc6DQoNCkluZGljYXRv ciAtLT4gSW5kaWN0b3IgU2V0IC0tPiBDYW1wYWlnbiAtLT4gVGhyZWF0IEFjdG9yDQoNCkNhbXBh aWduIGFuZCBUaHJlYXQgQWN0b3IgYXJlIHdoZXJlIGhhdmluZyBhICJDb25maWRlbmNlIiBhdHRy aWJ1dGUNCndvdWxkIGJlIGJlbmVmaWNpYWwgYXMgbWFraW5nIHRob3NlIGFzc29jaWF0aW9ucyBp cyBub3QgYSBwZXJmZWN0DQpzY2llbmNlIGJ5IGFueSBtZWFucy4NCg0KVGhhbmtzLA0KDQotLUNo cmlzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1vcmlhcnR5LCBLYXRo bGVlbg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEzIDI6MDAgUE0NClRvOiBUYWtl c2hpIFRha2FoYXNoaTsgSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7IFN0b2Vja2VyLCBQYXVsOyAn TUlMRQ0KSUVURicNClN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KDQpIaSBUYWtlICYgb3RoZXJz LA0KDQpUaGFua3MgZm9yIGNoaW1pbmcgaW4sIEkndmUgYmVlbiB0YWxraW5nIGFib3V0IHRoaXMg d2l0aCBDaHJpcyBhbmQgYQ0KZmV3IG90aGVycyBvbiB0aGVpciB1c2UgY2FzZXMgYW5kIHdvdWxk IGxpa2UgbW9yZSBvcGluaW9ucy4gIEknbGwNCnByb3ZpZGUgYW4gb3B0aW9uIGJlbG93IGZyb20g d2hhdCB3ZSBoYXZlIGRpc2N1c3NlZCBmcm9tIGEgQ0lSQyB2aWV3DQpwb2ludC4gIFdlIGFyZSBh bHNvIHdvbmRlcmluZyBob3cgdG8gYWxzbyBwcm92aWRlIGxvZ2ljIGluIElPREVGIHRoYXQNCmNv dWxkIGNyb3NzIG92ZXIgaW50byBTQ0kgYXR0YWNoZWQgc2NoZW1hcyBvciBJT0RFRiBleHRlbnNp b25zICh0aGUNCnNvbHV0aW9ucyBtYXkgYWxsIHRpZSB0b2dldGhlciB3aXRoIHRoaXMgZGlzY3Vz c2lvbiAtIG9yIHRoZXJlIG1heSBiZQ0KYmV0dGVyL21vcmUgZWxlZ2FudCBzb2x1dGlvbnMgb3Ro ZXJzIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBUYWtlc2hpIFRha2FoYXNoaSBbbWFpbHRvOnRha2VzaGlfdGFrYWhhc2hpQG5pY3Qu Z28uanA8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89dGFrZXNo aV90YWthaGFzaGlAbmljdC5nby5qcD5dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAx MyAxMjowNCBQTQ0KVG86IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyBTdG9lY2tlciwgUGF1bDsg TW9yaWFydHksIEthdGhsZWVuOw0KJ01JTEUNCklFVEYnDQpTdWJqZWN0OiBSRTogW21pbGVdIElP Q3MNCg0KSSBsaWtlIHRoaXMgZGlzY3Vzc2lvbi4NCkkgYWdyZWUsIGl0IHdvdWxkIGJlIGdvb2Qg aWRlYSB0byBoYXZlIGluZGljYXRvciBpZGVudGlmaWVycyBpbnNpZGUNCnRoZSBJT0MtcmVsYXRl ZCBjbGFzc2VzLg0KDQpLTU06IEF0IHRoZSBjbGFzcyBsZXZlbCwgd2UgbWF5IGhhdmUgc2V2ZXJh bCBpbmRpY2F0b3JzIGxpc3RlZCB0aGF0DQpzaG91bGQgYmUgdmlld2VkIGFzIGEgc2V0IGFuZCBt YXkgaGF2ZSBhbm90aGVyIGluc3RhbmNlIG9mIHRoYXQgc2FtZQ0KY2xhc3MgdGhhdCBpcyBhIHJl bGF0ZWQgaXNzdWUsIGJ1dCBhIHNlcGFyYXRlIHNldC4gIFdlIGNvdWxkIGFzIHlvdQ0Kc2F5LCBs aXN0IHRoZSBpbmRpY2F0b3IgSURzIGNvbm5lY3RlZCB0aHJvdWdoIHRoZSByZWZlcmVuY2UgY2xh c3MuDQpUaGUgc2V0IElEcyBtaWdodCBnaXZlIHVzIG90aGVyIHdheXMgdG8gZ3JvdXAgdGhlIHZh bHVlcyB3aGVuIHdlIGdldA0KaW50byBsb2dpYyBhbmQgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHNl dHMgb3IgaW5kaWNhdG9ycy4gIFRoaXMgY291bGQNCmFsc28gYmUgYSB3YXkgdG8gY29ubmVjdCBp bmRpY2F0b3JzIG9yIHNldHMgYWNyb3NzIFhNTCBkb2N1bWVudHMgdGhhdA0KY291bGQgaGF2ZSBi ZWVuIHNoYXJlZCBwcmV2aW91c2x5LiAgSWYgdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mDQpp bmRpY2F0b3JzIGluIHRoZSBzZXQsIHRoZW4gdGhpcyBiZWNvbWVzIHVzZWZ1bCwgZm9yIHNtYWxs ZXIgc2V0cywgSQ0KYWdyZWUgaXQgZG9lc24ndCBtYWtlIGFzIG11Y2ggc2Vuc2UuDQoNCldoYXQg ZG8gb3RoZXJzIHRoaW5rPw0KDQpUaGVuIGZvciBpbmRpY2F0b3JzIG5vdCBpbmNsdWRlZCBpbiB0 aGUgYmFzZSBzY2hlbWEgdGhhdCBtYXkgbm90DQpmaXQgaW50byBhIGNhdGVnb3J5IGluIHRoZSBT Q0kgZHJhZnQsIGRvIHdlIGNyZWF0ZSBhIHBsYWNlIGZvcg0KdGhlc2Ugb2ZmIG9mIFNDSSBvciBy aWdodCBvZmYgb2YgdGhlIElPREUgc2NoZW1hIGluIEV2ZW50RGF0YT8NCihtb3JlIGRldGFpbHMN Cm9uDQp0aGlzIGluIG15IGZpcnN0IG1lc3NhZ2UpLg0KDQpJZiB3ZSBjb3VsZCBzZWUgYW55IGlu ZGljYXRvciBvZiBjb21wcm9taXNlIGFzIGNvbXB1dGVyIGV2ZW50DQpyZWNvcmQsIHdlIGNvdWxk IHVzZSBTQ0k6RXZlbnRSZXBvcnQgY2xhc3MgYXMgdGhlIHBsYWNlIGZvciB0aGUNClhNTC1iYXNl ZCBJT0NzIHRoYXQgY291bGRuJ3QgZml0IGFueXdoZXJlIGVsc2UuDQoNCktNTTogVGhhdCBzb3Vu ZHMgbGlrZSBhIGdvb2QgaWRlYSB0byBtZS4gIFRoaXMgc2hvdWxkIGdvIGludG8NCmd1aWRhbmNl DQppbiB0aGUgU0NJIGRyYWZ0LiAgRG9lcyBhbnlvbmUgZWxzZSB3YW50IHRvIHdlaWdoIGluPw0K DQoNCkZvciB0aGUgbm9uLVhNTCBJT0NzLCB3ZSBjb3VsZCB1c2UgUmVjb3JkRGF0YSBjbGFzcywg YXMgc3VnZ2VzdGVkLg0KS01NOiBTb3VuZHMgZ29vZCwgdGhhbmtzIQ0KDQpJIGFncmVlIHRvIGhh dmUgaW5kaWNhdG9yX3VpZCwgYnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIG5lZWRzIG9mDQp0 aGUgaW5kaWNhdG9yX3NldF9pZC4NCkkgdW5kZXJzdGFuZCB3ZSBjb3VsZCBkbyBzb21lIGdyb3Vw aW5nIG9mIGluZGl2aWR1YWwgaW5kaWNhdG9yX3VpZHMNCmFuZCBpdHMgdXNhYmlsaXR5LCBidXQg SSBhbSBub3Qgc3VyZSB3aGV0aGVyIHdlIGRvIG5vdCBoYXZlIGFueQ0Kb3RoZXIgd2F5IHRvIGV4 cHJlc3MgdGhlc2UgZ3JvdXBpbmdzLg0KRm9yIGluc3RhbmNlLCAgYSBSZWZlcmVuY2UgY2xhc3Mg cmVmZXJzIHRvIHNldmVyYWwgaW5kaWNhZHRvcl91aWRzLg0KSW4NCnRoaXMgY2FzZSwgdGhleSBj b3VsZCBiZSwgaW4gYSBzZW5zZSwgZ3JvdXBlZC4gSXNuJ3QgaXQgZW5vdWdoPw0KDQpLTU06IEl0 IG1heSBiZSwgd2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgbGFyZ2Ugc2V0cyBvZiBpbmRpY2F0b3Jz IG9yDQpzdWJzZXF1ZW50IG1lc3NhZ2VzIHRoYXQgYWRkIGluZGljYXRvcnMgdG8gZXhpc3Rpbmcg c2V0cz8gIFdvdWxkIHRoaXMNCmhhcHBlbj8gIFdvdWxkIGl0IGJlIGVhc2llciB0byBleHByZXNz IHJlbGF0aW9uc2hpcHMgd2l0aCBzZXRzIG9mDQppbmRpY2F0b3JzIGluIGFkZGl0aW9uIHRvIGlu ZGl2aWR1YWwgaW5kaWNhdG9ycz8gIEJ5IHVzaW5nIHRoaXMsIGl0DQpjb3VsZCBnaXZlIHVzIGEg dW5pcXVlIHdheSB0byBhbHNvIHByb3ZpZGUgdGhlIGxvZ2ljIGFuZA0KcmVsYXRpb25zaGlwcw0K aW4gYSBuZXcgY2xhc3Mgb2YgSU9ERUYgc28gd2UgZG9uJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBh ZGRpbmcgaXQNCmludG8NCnRoZSBjdXJyZW50DQpzdHJ1Y3R1cmUuDQpJZiB0aGVyZSBhcmUgYmV0 dGVyIHdheXMgdG8gaGFuZGxlIHRoYXQsIGFuZCBvdGhlcnMgY2FuIHByb3ZpZGUgc29tZQ0Kb3B0 aW9ucywgdGhhdCB3b3VsZCBiZSBhcHByZWNpYXRlZCENCg0KVGhhbmsgeW91LA0KS2F0aGxlZW4N Cg0KSSB3b3VsZCBhcHByZWNpYXRlIGlmIGFueWJvZHkgY291bGQgc2hhcmUgZXhwZXJ0aXNlIG9u IHRoaXMuIFRob3VnaA0KSQ0KdGhpbmsgSSBoYXZlIHJlYWQgYWxsIHRoZSBlbWFpbHMgaW4gdGhl IGxpc3QsIEkgbWlnaHQgaGF2ZQ0KbWlzLXVuZGVyc3Rvb2Qgc29tZSBwb2ludHMuDQoNCkJ5IHRo ZSB3YXksIEkgdGhpbmsgdGhlIGluZGljYXRvcl91aWRzIHNob3VsZCBiZSBhZGRlZCB0byB0aGUg U0NJDQpjbGFzc2VzJw0KYXR0cmlidXRlcyBzbyB0aGF0IHRoZXkgY2FuIGJlIGNvcnJlbGF0ZWQg d2l0aCBhbm90aGVyIGluZm9ybWF0aW9uDQphcw0Kd2VsbC4NCg0KVGhhbmtzDQpUYWtlDQoNCg0K DQpGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28u Y29tL21jL2NvbXBvc2U/dG89bWlsZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1pbGUtYm91 bmNlc0BpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90 bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCk9mIEhhcnJpbmd0b24sIENocmlz dG9waGVyDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNSwgMjAxMyA0OjI1IEFNDQpUbzogU3Rv ZWNrZXIsIFBhdWw7IE1vcmlhcnR5LCBLYXRobGVlbjsgTUlMRSBJRVRGDQpTdWJqZWN0OiBSZTog W21pbGVdIElPQ3MNCg0KSSB0aGluayBzb21lIHNvcnQgb2YgZ3JvdXAgSUQgd291bGQgZG8gdGhl IHRyaWNrLiBXZSBhbHNvIG5lZWQgYQ0KbG9naWNhbCBhbmQgLyBvciBzb21ld2hlcmUgdG8gc2hv dyByZWxhdGlvbnNoaXAgYmV0d2VlbiBpbmRpY2F0b3JzLg0KSWYNCkkgZ2l2ZSB5b3UNCjINCnJl Z2lzdHJ5IGtleXMgZG8gdGhleSBib3RoIGhhdmUgdG8gYmUgcHJlc2VudCB0byBiZSBhbiBpbmRp Y2F0aW9uIG9mDQpjb21wcm9taXNlIG9yIGlzIGVpdGhlciBvbmUgYnkgdGhlbXNlbHZlcyBhbiBp bmRpY2F0b3I/IEJvdGggd291bGQNCmhhdmUgdGhlIHNhbWUgZ3JvdXAgSUQgc2luY2UgdGhleSBh cmUgcmVsYXRlZC4NCg0KVGhhbmtzLA0KLS1DaHJpcw0KDQpGcm9tOiBTdG9lY2tlciwgUGF1bA0K U2VudDogU3VuZGF5LCBGZWJydWFyeSAwMywgMjAxMyA4OjI2IFBNDQpUbzogTW9yaWFydHksIEth dGhsZWVuOyBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcjsgTUlMRSBJRVRGDQpTdWJqZWN0OiBSZTog W21pbGVdIElPQ3MNCg0KV2hhdCBpZiB3ZSBhZGRlZCBpbmRpY2F0b3IgZ3JvdXAgSUQgYWxvbmcg d2l0aCB0aGUgaW5kaWNhdG9yX3VpZD8NClRoaXMgd291bGQgYWxsb3cgeW91IHRvIGdyb3VwIGlu ZGljYXRvcnMgdGhhdCBhcmUgcmVsYXRlZCBpbnRvIHRoZQ0Kc2FtZSBncm91cCBJRC4NCldvdWxk IHRoaXMgcmVzb2x2ZSB0aGUgaXNzdWU/DQoNCkl0IGlzIGVpdGhlciB0aGF0IG9yIGdvaW5nIGJh Y2sgdG8gYWRkaW5nIGEgRGV0ZWN0aW9uIChvciBJbmRpY2F0b3JzKQ0KY2xhc3MgdGhhdCB3aWxs IHNob3VsZCBiZSB1c2VkIHRvIHRha2UgYWxsIG9mIHRoZSBpbmRpY2F0b3JzIHB1dCB0aGVtDQpp bnRvIG9uZSBwbGFjZSBhbmQgaGF2ZSB0aGUgYWJpbGl0eSB0byBncm91cCB0aGUgb25lcyB0aGF0 IGdvDQp0b2dldGhlci4gIEkgZG9uJ3QgbWVhbiBhIHBsYWNlIHRvIHB1dCBpbmRpY2F0b3JzIHRo YXQgYXJlIG1pc3NpbmcNCmZyb20gSU9ERUYuSSBtZWFuIGEgcGxhY2UgaW4gdGhlIElPREVGIGRv Y3VtZW50IHdoZXJlIHlvdSBwdXQgdGhlDQppbmRpY2F0b3JzIHRoYXQgYXJlIHVzZWQgZm9yIGRl dGVjdGlvbiBhbmQgcHJldmVudGlvbiBvZiB0aGUgc2hhcmVkDQpJbmNpZGVudC4gIEkgZG9uJ3Qg a25vdyB0aGUgYW5zd2VyIGhlcmUsIGJ1dCB0aGVyZSBoYXMgZ290IHRvIGJlIGENCmdvb2Qgd2F5 IGZvciBpbmRpY2F0b3JzIHRvIGJlIGlkZW50aWZpZWQgYW5kIGJlaW5nIGFibGUgdG8gZ3JvdXAg dGhlbQ0KYXMgQ2hyaXMgaGFzIHN1Z2dlc3RlZCB3aXRob3V0IGJhc2ljYWxseSByZWNyZWF0aW5n IHNvbWV0aGluZw0KY29tcGxpY2F0ZWQgbGlrZSBTVElYLg0KDQpQYXVsDQoNCg0KUGF1bCBXLiBT dG9lY2tlciwgUGguRC4NClNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0DQpSU0EsIFRoZSBTZWN1 cml0eSBEaXZpc2lvbiBvZiBFTUMNCmNlbGw6IDMwMi4zNzkuMzM3NSB8IGU6IHBhdWwuc3RvZWNr ZXJAcnNhLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1w YXVsLnN0b2Vja2VyQHJzYS5jb20+DQoNCg0KRnJvbTogPE1vcmlhcnR5PiwgS2F0aGxlZW4gPGth dGhsZWVuLm1vcmlhcnR5QGVtYy5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbT4+DQpEYXRlOiBTdW5kYXksIEZl YnJ1YXJ5IDMsIDIwMTMgNToxMSBQTQ0KVG86ICJIYXJyaW5ndG9uLCBDaHJpc3RvcGhlciIgPENo cmlzdG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5j b20vbWMvY29tcG9zZT90bz1DaHJpc3RvcGhlci5IYXJyaW5ndG9uQGVtYy5jb20+PiwgTUlMRQ0K SUVURiA8bWlsZUBpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29t cG9zZT90bz1taWxlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KDQpIaSBD aHJpcywNCg0KSSBhZ3JlZSwgd2UgaGF2ZSBzb21lIHdvcmsgdG8gZG8gaW4gdGhlIHVwZGF0ZWQg SU9ERUYsIFJGQzUwNzAtYmlzLg0KDQpUaGUgbGlzdCBoYXMgYWxyZWFkeSBzYWlkIHRoZXkgd291 bGQgbGlrZSB0byBzZWUgaW5kaWNhdG9ycyBhZGRlZCB0bw0KdGhlIGRlZmluaXRpb25zIGluIFJG QzUwNzAtYmlzLCB0byBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IGluY2x1ZGluZw0KaW5kaWNhdG9y cyBhbmQgc2V0cyBvZiBpbmRpY2F0b3JzIGluIElPREUgZG9jdW1lbnRzIGFzIG9wcG9zZWQgdG8N CidwYXJ0cyBvZiBhbiBpbmNpZGVudCBvciB0aGUgdXNlZnVsIGluZm9ybWF0aW9uIG9uIGFuIGlu Y2lkZW50IGZvcg0Kc2hhcmluZyBwdXJwb3Nlcy4gIEl0IHdhcyB3cml0dGVuIGJlZm9yZSB3ZSB1 c2VkIHRlcm1zIGxpa2UNCmluZGljYXRvcnMuICBXaXRoIHRoYXQgaW4gbWluZCwgUm9zZWxsYSBw cm9wb3NlZCBhIG51bWJlciBvZiBjaGFuZ2VzDQpiYWNrIGluIEp1bHksIGJvdGggZm9yIGd1aWRh bmNlIGFuZCBmb3INCmZvcm1hdA0KdXBkYXRlcy4gIEl0IG1heSBoZWxwIHRvIGhhdmUgdGhlIGZp cnN0IGRyYWZ0IHRyeSB0byBhZGRyZXNzIGF0IGxlYXN0DQpzb21lIG9mIHRoZXNlIGlzc3VlcyBz byBwZW9wbGUgY2FuIHVuZGVyc3RhbmQgdGhlIHByb2JsZW1zIGFuZCBhdA0KbGVhc3QgYSBwcm9w b3NlZCBzb2x1dGlvbi4NCg0KQXMgeW91IHBvaW50IG91dCwgd2UgbmVlZCB0byBiZSBhYmxlIHRv IHNob3cgcmVsYXRpb25zaGlwcyBiZXR3ZWVuDQpzZXRzIG9mIGluZGljYXRvcnMsIHdoZXJlIHdl IG1heSBoYXZlIGEgZmV3IHNldHMgb2YgaW5kaWNhdG9ycyB0aGF0DQpjb3VsZCBoYXZlIGEgcmVs YXRpb25zaGlwIHRvIGVhY2ggb3RoZXIgd2l0aGluIGEgZG9jdW1lbnQuICBJbiB0aGUNCkp1bHkg cHJlc2VudGF0aW9uLCBvbmUgb2YgdGhlIHF1ZXN0aW9ucyB3YXMgdG8gc2VlIGlmIHdlIHNob3Vs ZCBhZGQNCm5ldyBjYXRlZ29yeSBhdHRyaWJ1dGUgdmFsdWVzIGZvciB0aGUgU3lzdGVtIGNsYXNz IHRoYXQgd291bGQgY29ubmVjdA0KdGhlIGxpc3Qgb2YgaW5jbHVkZWQgaW5kaWNhdG9ycy4gIEkg dGhpbmsgd2Ugc2hvdWxkIHN0aWxsIGtlZXAgdGhlDQpjb25jZXB0IG9mIGEgTm9kZSB0byBhIHNp bmdsZSBub2RlLCBidXQgcGVyaGFwcyB3aXRoaW4gU3lzdGVtLCBsaXN0DQptdWx0aXBsZSBzZXRz IG9mIE5vZGVzIHRoYXQgbWF5IGJlIG9uZSB0eXBlIG9mIGF0dGFjay4gIFJvc2VsbGEgaGFkDQpz dWdnZXN0ZWQgcHVsbGluZyBmb3J3YXJkIHRoZSAiRnJhdWRUeXBlIiBmcm9tIFJGQzU5MDEsIHRo aXMgd291bGQNCmhlbHAgc29sdmUgdGhlIGlzc3VlIGFzIE5vZGVSb2xlIHZhbHVlcyB3b3VsZCBj b21wbGltZW50IGFuDQpBdHRhY2tUeXBlDQooRnJhdWRUeXBlIHZhbHVlcyBjb3VsZCBiZSBpbmNs dWRlZCBpbiBBdHRhY2tUeXBlIG9yIHNvbWUgYnJvYWRlcg0KdGVybSkuICBJdCBtYXkgYmUgYmV0 dGVyIHRvIGhhdmUgdGhlIEZyYXVkVHlwZXMsIHBsdXMgYXR0cmlidXRlDQp2YWx1ZXMNCmxpa2Ug IkMyLXNlcnZlciIsICJzaW5raG9sZSIsICAiTWFsd2FyZURpc3RyaWJ1dGlvbiIgZm9yIGFkZGVk DQpjb250ZXh0DQpzbyB5b3Uga25vdyB3aGF0IHRvIGRvIHdpdGggdGhlIHJlY2VpdmVkIHNldCBv ZiBpbmRpY2F0b3JzLg0KDQpJIGFtIHByb3Bvc2luZyB0aGF0IHdlIGNoYW5nZSBJT0RFRiB0byBp bmNsdWRlIG11bHRpcGxlIHNldHMgb2YNCmluZGljYXRvcnMsDQphZGQgYW4gQXR0YWNrVHlwZSBh dHRyaWJ1dGUgKG9yIHNvbWUgb3RoZXIgbmFtZSksIGEgbWV0aG9kIHRvIGNvbm5lY3QNCmluZGlj YXRvcnMgYW5kIGluZGljYXRvciBzZXRzIHdpdGhpbiBhbiBJT0RFRiB1c2luZyBhbiBhdHRyaWJ1 dGUgb2YNCmluZGljYXRvcl91aWQgKG9yIHNvbWUgb3RoZXIgbmFtZSkgd2l0aCBhIHN0cmluZyB2 YWx1ZSB0byBtYWtlIHRoZQ0KY29ubmVjdGlvbiBwb2ludHMsIGFuZCBhZGQgYSBmZXcgaW5kaWNh dG9ycyB0aGF0IGFyZSBjb21tb25seSBzaGFyZWQNCmludG8gdGhlIGJhc2UgSU9ERUYuDQoNCkJh Y2sgaW4gSnVseSwgd2UgdGFsa2VkIGFib3V0IGFkZGluZyBSZWdpc3RyeSBLZXkvVmFsdWUgcGFp cnMgYW5kDQpoYXNoZXMgdG8gdGhlIG1haW4gSU9ERUYgZG9jdW1lbnQgKHRyeWluZyB0byBzZWUg aWYgdGhpcyB3aWxsIGhlbHANCkNocmlzIGJlbG93KS4gIFdoYXQgaWYgd2UgYWRkZWQgdGhlIFJl Z2lzdHJ5IEtleS9WYWx1ZSBwYWlycyBhcyBhDQpjbGFzcyBvZmYgb2YgUmVjb3JkRGF0YSwgdXNp bmcgYSBzaW1pbGFyIHN0cnVjdHVyZSB0byB3aGF0IGlzIGluDQpSRkM1OTAxLCBhbmQgYWxzbyBh ZGRlZCB0aGUgYWJpbGl0eSB0byBpbmNsdWRlIGhhc2hlcyBpbiBSZWNvcmREYXRhPw0KSSB0aGlu ayBpZiB3ZSB0aGVuIGhhZCB0aGUgaW5kaWNhdG9yX3VpZCBhdCB0aGUgUmVjb3JkRGF0YSBsZXZl bCwgd2UNCmNvdWxkIGNvbm5lY3QgYSBzZXQgd2l0aGluIHRoYXQgc3RydWN0dXJlIGFuZCByZXBl YXQgdGhlIHN0cnVjdHVyZQ0KZm9yDQpvdGhlciBzZXRzIGluIHRoZSBzYW1lIHdheSB3ZSB3b3Vs ZCBkbyB3aXRoIE5vZGUgaW5zaWRlIG9mIHRoZSBTeXN0ZW0NCmNsYXNzLCB1c2luZyB0aGUgaW5k aWNhdG9yX3VpZCB0byB0aWUgdGhlIHNldCB0b2dldGhlci4gIFRoZW4gYXQgdGhlDQptb3JlIHNw ZWNpZmljIGxldmVsIGZvciB0aGUgaGFzaCwgcmVnaXN0cnkgS2V5L3ZhbHVlLCBJUCwgZXRjLiB1 c2UgYW4NCmluZGljYXRvcl91aWQgaWYgd2UgbmVlZGVkIHRoZW0gbWFya2VkIGF0IHRoaXMgbGV2 ZWwgYXMgd2VsbD8gIE1heWJlDQp3ZSB3YW50IGluZGljYXRvcl9zZXQgYXQgdGhlIGhpZ2hlciBs ZXZlbD8gIEknZCBsaWtlIHNvbWUgb3BpbmlvbnMgb24NCnRoaXMgYXBwcm9hY2guICArMSBpZiB5 b3UgYWdyZWUsIHN1Z2dlc3Rpb25zIGlmIHlvdSBoYXZlIG90aGVyIGlkZWFzDQp0aGF0IG1heSB3 b3JrIGJldHRlci4NCg0KV2UnbGwgYWxzbyBuZWVkIHRvIHdvcnJ5IGFib3V0IG1hcmtpbmcgdGhl IGluZGljYXRvcnMgdG8gcHJldmVudA0KZm9yd2FyZCBzaGFyaW5nIHdoZW4gbm90IHBlcm1pdHRl ZC4gIFdlIG1heSB3YW50IHRvIHVzZSB0aGVzZSB2YWx1ZXMNCm9yIHNvbWV0aGluZyBlbHNlLg0K DQpUaGFuayB5b3UhDQpLYXRobGVlbg0KDQpGcm9tOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhlcg0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAwMSwgMjAxMyAxMjowMSBQTQ0KVG86IE1vcmlhcnR5LCBL YXRobGVlbjsgTUlMRSBJRVRGDQpTdWJqZWN0OiBSRTogW21pbGVdIElPQ3MNCg0KSSB0aGluayB3 ZSBoYXZlIGEgYmlnZ2VyIHJlbGF0aW9uc2hpcCBpc3N1ZSB0byBhZGRyZXNzLiBMZXQgdXNlIHRo ZQ0KV2F0Y2hsaXN0IFVzZSBDYXNlLiBBIGJ1bmNoIG9mIGluZGljYXRvcnMgYXJlIHNlbnQgaW4g b25lIG1lc3NhZ2UuIEluDQp0aGF0IG1lc3NhZ2Ugd2UgY291bGQgaGF2ZSBncm91cGluZ3Mgb2Yg aW5kaWNhdG9ycyB0aGF0IHdlIG5lZWQgdG8NCnNob3cgYXJlDQpyZWxhdGVkOg0KDQpUd28gb3Ig bW9yZSBpbmRpY2F0b3JzIG9mIGRpZmZlcmVudCB0eXBlIHRoYXQgcmVsYXRlIHRvIHRoZSBzYW1l DQp0aHJlYXQ6DQogICAgICAgVGhlIGZpbGUgaGFzaCBvZiBhIG1hbGljaW91cyBmaWxlIGFuZCB0 aGUgVVJMIG9mIHRoZSBDMiB0aGF0DQp0aGUgZmlsZSB1c2VzLiBFaXRoZXIgb3IgYm90aCBtYXkg YmUgcHJlc2VudCB0byBpbmRpY2F0ZSBhDQpjb21wcm9taXNlLg0KDQpUd28gb3IgbW9yZSBpbmRp Y2F0b3JzIG9mIHRoZSBzYW1lIHR5cGUgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUNCnRocmVhdDoN CiAgICAgICAyIGRpZmZlcmVudCByZWdpc3RyeSB2YWx1ZXMgZm9yIHRoZSBzYW1lIHJlZ2lzdHJ5 IGtleS4gSWYNCmVpdGhlciB2YWx1ZSBpcyBwcmVzZW50IGl0IGlzIGEgY29tcHJvbWlzZSBpbmRp Y2F0b3IgYnV0IGJvdGggd2lsbA0Kbm90DQpiZQ0KcHJlc2VudC4NCg0KVGhlIHByb2JsZW0gY29t cG91bmRzIGl0c2VsZiB2ZXJ5IHF1aWNrbHkuIENvbnNpZGVyIHRoZSBzY2VuYXJpbw0Kd2hlcmUN CmJvdGggZ3JvdXBpbmdzIGFib3ZlIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIHRocmVhdC4gSSBuZWVk IHRvIHNob3cgdGhhdA0KbG9naWNhbCBncm91cGluZ3Mgb2YgSW5kaWNhdG9ycyBhcmUgcmVsYXRl ZCBhcyB3ZWxsLiBXZSBjYW4ndCBzZW5kDQptdWx0aXBsZSBJT0RFRiBtZXNzYWdlcyBmb3IgdGhp cyBmcm9tIHdoYXQgSSByZW1lbWJlciByZWFkaW5nLg0KDQpUaGUgbGFzdCBvbmUgSSBjYW4gdGhp bmsgb2Ygd291bGQgYmUgd2hlbiB5b3UgaGF2ZSAyIGRpZmZlcmVudA0KaW5kaWNhdG9ycyB0aGF0 IHJlcHJlc2VudCB0aGUgc2FtZSBpbmRpY2F0b3IuIEl0J3Mgbm90IHVuY29tbW9uIHRvDQpzZW5k IGJvdGggdGhlDQpNRDUNCmFuZCBTSEExIGhhc2ggb2YgYSBtYWxpY2lvdXMgZmlsZS4gVGhlIGlu ZGljYXRvciBpcyB0aGUgZmlsZSBidXQgdGhlDQpJT0NzIGFyZSB0aGUgMiBoYXNoIHZhbHVlcy4g SG93IGRvIHdlIHNob3cgdGhleSBhcmUgcmVsYXRlZD8gSWYgd2UNCnVzZQ0KYSB1bmlxdWUgSW5p ZGNhdG9yIElEIGZvciBlYWNoIGhhc2ggdmFsdWUgdGhlcmUgbmVlZHMgdG8gYmUgYSBoaWdoZXIN CmxldmVsDQpncm91cGluZy4NCg0KVGhvdWdodHM/DQoNClRoYW5rcywNCg0KLS1DaHJpcw0KDQpD aHJpc3RvcGhlciBIYXJyaW5ndG9uDQpDb25zdWx0aW5nIFNlY3VyaXR5IEVuZ2luZWVyDQpHU08g LSBDcml0aWNhbCBJbmNpZGVudCBSZXNwb25zZSBDZW50ZXIgRU1DIC0gV2hlcmUgSW5mb3JtYXRp b24gTGl2ZXMNCjE3NCBNaWRkbGVzZXggVHVybnBpa2UNCkJlZGZvcmQsIE1BIDAxNzMwDQo3ODEt NTE1LTU4NjIgKHdvcmspDQo2MDMtNTgzLTE1ODUgKGNlbGwpDQoNCkZyb206IG1pbGUtYm91bmNl c0BpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1t aWxlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPGh0dHA6 Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRm Lm9yZz5dIE9uIEJlaGFsZg0KT2YgTW9yaWFydHksIEthdGhsZWVuDQpTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDAxLCAyMDEzIDExOjI4IEFNDQpUbzogTUlMRSBJRVRGDQpTdWJqZWN0OiBSZTogW21p bGVdIElPQ3MNCg0KQWxsIC0NCg0KSSdkIGxpa2UgeW91ciBpbnB1dCBhbmQgd2lsbCByZWZvY3Vz IHRoZSB0aHJlYWQgdG8gZ2V0IG9waW5pb25zIGZyb20NCnRoZSBsaXN0IG9uIG9wdGlvbnMgdG8g aGVscCBzb2x2ZSB0aGUgcHJvYmxlbXMgcmFpc2VkIGluIG15IG1lc3NhZ2UNCmFuZCBhZGRpdGlv bmFsbHkgaW4gUGF1bCdzIG1lc3NhZ2UuDQoNCkludGVyZXN0aW5nIHBvaW50LCBDLiBIZW5yeS4g IE91ciBvYmplY3RpdmUgaGVyZSBpcyB0byBoYXZlIG1hY2hpbmUNCmF1dG9tYXRlZCBleGNoYW5n ZXMsIHNvIHdlIHJlbHkgb24gZW5jcnlwdGlvbiByYXRoZXIgdGhhbiBvYmZ1c2NhdGlvbg0KdG8g YWNoaWV2ZSB0aGUgbmVjZXNzYXJ5IGxldmVsIG9mIGNvbmZpZGVudGlhbGl0eS4NCg0KUGF1bCBt ZW50aW9uZWQgdGhlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggaW5kaWNhdG9ycyBvZiBjb21wcm9taXNl IGZyb20NCmNvbnRleHQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYWxzbyBpbmNsdWRlIElQIGFkZHJl c3Mgb3Igb3RoZXIgZGF0YQ0KdGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzLiAgVGhlIHF1ZXN0aW9u IEkgcmFpc2VkIHdhcyBvbiBob3cgdG8NCmNvbm5lY3QNCnNldHMgb2YgaW5kaWNhdG9ycyBpbiB0 aGUgc2FtZSBJT0RFRiBkb2N1bWVudCwgYXNzdW1pbmcgdGhlIGFiaWxpdHkNCnRvDQpoYXZlIHdh dGNobGlzdHMgdGhhdCBjb3VsZCBoYXZlIHNldmVyYWwgc2V0cyBvZiBpbmRpY2F0b3JzIGluY2x1 ZGVkLA0KYXMgd2VsbCBhcyB0byBjb25uZWN0IGluZGljYXRvcnMgdGhhdCBtYXkgYmUgaW5jbHVk ZWQgaW4gZW1iZWRkZWQNCnNjaGVtYXMuDQoNCklmIHdlIGFkZCBhbiBhdHRyaWJ1dGUgb24gYWxs IG9mIHRoZSByZWxldmFudCBpbmRpY2F0b3JzLCBsZXQncyBzYXkNCidpbmRpY2F0b3ItdWlkJyBo b3cgZG8gd2UgbWFyayB0aGUgaW5kaWNhdG9ycz8gIERvIHdlIHVzZSB0aGlzIHRvDQptYXJrDQp3 aG8gc2VudCB0aGUgaW5kaWNhdG9yIGFzIHdlbGwgc28gdGhhdCB3ZSBjYW4gcHJldmVudCBmb3J3 YXJkIHNoYXJpbmcNCndoZW4gaXQgaXMgbm90IHBlcm1pdHRlZCBvciBoYW5kbGUgdGhhdCBzZXBh cmF0ZWx5Pw0KDQpUaGVuIGZvciBpbmRpY2F0b3JzIG5vdCBpbmNsdWRlZCBpbiB0aGUgYmFzZSBz Y2hlbWEgdGhhdCBtYXkgbm90IGZpdA0KaW50byBhIGNhdGVnb3J5IGluIHRoZSBTQ0kgZHJhZnQs IGRvIHdlIGNyZWF0ZSBhIHBsYWNlIGZvciB0aGVzZSBvZmYNCm9mIFNDSSBvciByaWdodCBvZmYg b2YgdGhlIElPREUgc2NoZW1hIGluIEV2ZW50RGF0YT8gKG1vcmUgZGV0YWlscyBvbg0KdGhpcyBp biBteSBmaXJzdCBtZXNzYWdlKS4NCg0KQ29tbWVudHMgYW5kIHF1ZXN0aW9ucyBlbmNvdXJhZ2Vk IHRvIGZpZ3VyZSBvdXQgdGhlIHJpZ2h0IHRlY2huaWNhbA0Kc29sdXRpb24gdG8gaGF2ZSB0aGlz IG1hY2hpbmUgYXV0b21hdGFibGUuDQoNClRoYW5rIHlvdSwNCkthdGhsZWVuDQoNCkZyb206IG1p bGUtYm91bmNlc0BpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29t cG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYu b3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KT2YgQy4NCkhlbnJ5IEFkYW1zICYgQklFDQpTZW50 OiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTMgMTE6MjUgUE0NClRvOiBNSUxFIElFVEYNClN1Ympl Y3Q6IFJlOiBbbWlsZV0gSU9Dcw0KDQpUZW1wb3JhbCBEZXBlbmRlbmN5IHNvdW5kcyBpbnRlcmVz dGluZy4gIEkgcmVtZW1iZXIgd2hlbiBJIGZpcnN0IHJhbg0KYWNyb3NzIHRoaXMgcGFydGljdWxh ciBjcmFmdCwgYW4gZXhwZXJpZW5jZWQgY29sbGVhZ3VlIGFza2VkIG1lIGENCnBlY3VsaWFyIHF1 ZXN0aW9uLiAgSGUgc2FpZCwgIiBIb3cgZG8geW91IHN0b3Agc29tZW9uZSBmcm9tIHRyYWNraW5n DQp0aGUgSVAgQWRkcmVzcyB0byB5b3VyIGNvbXB1dGVyPyINCg0KSSByZXBsaWVkLCAiSSBkb24n dCBrbm93LCBob3c/Ig0KDQpUaGVuIGhlIHNhaWQsICJDdXQgdGhlIGRvZy1nb25lIHRoaW5nIG9m ZiAgYW5kIHRoZSBtb2RlbSB0aGF0IGl0IGlzDQpjb25uZWN0ZWQtIHdoaWNoIGlzIGNvbnN0YW50 bHkgb24hIiAgIExPTA0KDQpIZXJlJ3MgbXkgcG9pbnQgKEh5cG90aGV0aWNhbCBTaXR1YXRpb24p IDogIFRoZXJlIGlzIGEgMXN0IFJlc3BvbmRlcg0Kc2VhcmNoaW5nIGEgTmVpZ2hib3Job29kIGZv ciBTdXJ2aXZvcnMgd2hpY2ggd2VyZSBoaXQgYnkgYSBEaXNhc3Rlcg0Kb3INCmxldCdzIGp1c3Qg c2F5ICJMaXZlIiBUZXJyb3Jpc3QgU2l0dWF0aW9uLiAgSGUgL29yIFNoZSBuZWVkcyB0bw0KY29t bXVuaWNhdGlvbiBiYWNrIHRvIG90aGVyIE9mZmljaWFscyB0aGF0IGhlIC9vciBzb21laG93IGlz IGluDQpEYW5nZXIuICBUaGUgZGV2aWNlIHVzZWQgdG8gY29tbXVuaWNhdGUgaGFzIGJlZW4gY2Fw dHVyZWQgYnkgdGhlDQpncmVhdA0KbWluZHMgb2YgdGhlIGVuZW15LiAgSXQncyBvbmx5IGEgbWF0 dGVyIG9mIHRpbWUgYmVmb3JlIHRoZXkgdXRpbGl6ZQ0KcmV2ZXJzZSBlbmdpbmVlcmluZyB0byBm aWd1cmUgb3V0IGhvdyBpdCBmdW5jdGlvbnMuICBIb3dldmVyLCB0aGVpcg0KcHJpZGUgY29tZXMg YmVmb3JlIGEgZmFsbCB3aGVuIHNlZWtpbmcgdGhlIGxvY2F0aW9uIG9mIG90aGVyIHNpbWlsYXIN CmRldmljZXMgdG8gYXR0YWNrLiAgV2h5PyBQZXJoYXBzIHRoZSBsZXNzIHRob3VnaHQgb2YgY29u Y2VwdHMgdGhhdA0KbWFrZXMgdGhlIGRldmljZSBmdW5jdGlvbiBwcm9wZXJseSwgc2F2ZXMgdGhl IGRheSBieSBkaXNndWlzZSBvcg0KY3V0dGluZyBpdCBvZmYgKGZpZ3VyYXRpdmVseSBzcGVha2lu ZykuDQoNCkp1c3QgYSB2aXNpb25hcnkgdGhvdWdodC4NCg0KQy4gSGVucnkgQWRhbXMNCmNoZW5y eWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9t Yy9jb21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPg0KaHR0cDovL2JpZW1l ZGlhZ3JvdXAuY29tDQoNCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0Kb3JpZ2luYWwgcmVjaXBpZW50LiBUaGlzIGluZm9y bWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQNCmRpc3RyaWJ1dGlvbiB3aXRoaW4gdGhlIHJl Y2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZw0KcHVycG9zZXMgb25seS4g RnVydGhlciBkaXNzZW1pbmF0aW9uLCB3aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzDQpwcm9o aWJpdGVkLg0KDQotLS0gT24gTW9uLCAxLzI4LzEzLCBEYXZlIE1pc2VsbCA8ZGF2aWQubWlzZWxs QGJjcy5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89ZGF2 aWQubWlzZWxsQGJjcy5vcmc+PiB3cm90ZToNCg0KRnJvbTogRGF2ZSBNaXNlbGwgPGRhdmlkLm1p c2VsbEBiY3Mub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3Rv PWRhdmlkLm1pc2VsbEBiY3Mub3JnPj4NClN1YmplY3Q6IFJlOiBbbWlsZV0gSU9Dcw0KVG86ICJD LiBIZW5yeSBBZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+Pg0K RGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzLCA5OjI1IFBNIFVJRCBjb3VsZCBiZSBtaXJy b3JlZCB3aXRoDQpETlMNClNFQyBhIHBlbWFuZW50IGFuZCB0ZW1wb3JhbCBrZXksIHdpdGggYSB0 ZW1wb3JhbCBJZD8NCg0KWW91cnMgRmFpdGhmdWxseSwNCg0KRGF2ZSBNaXNlbGwgTVNjIENJU1NQ DQpTaWxlbnRDaXJjbGUgIGRzbQ0KMDc3MTAgMzgwMDQ0DQpkYXZpZC5taXNlbGxAYmNzLm9yZzxo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1kYXZpZC5taXNlbGxA YmNzLm9yZz4NCg0KDQpPbiAyOSBKYW4gMjAxMywgYXQgMDA6MzksIEMuIEhlbnJ5IEFkYW1zICYg QklFDQo8Y2hhdGxnYTIwMDBAeWFob28uY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNv bS9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbT4+DQp3cm90ZToNCg0KU2VyaWFs aXphdGlvbiBvZiBhIHBhcnRpY3VsYXIgTGlzdHMgb2YgWE1MIENsYXNzZXMgaW4gYSB1bmlxdWUg d2F5DQp3YXMNCmNsb3NlbHkgcmVsYXRlZCB0byB3aGF0IEkgYXR0ZW1wdGVkIHRvIGV4cHJlc3Mg d2hlbiBJIHN0YXRlZCwNCiJjb25zaWRlciB0byBhIGRlZ3JlZSB3aGF0IGFwcGVhcnMgdG8gYmUg aWxsb2dpY2FsIGluIGJyaWxsaWFudCBtaW5kcw0KaW4gc29tZSBpbnN0YW5jZXMuIg0KDQpIb3dl dmVyLCBJIHNlZSBEci4gU3RvZWNrZXIncyBwb2ludCBhIGxpdHRsZSBjbGVhcmVyLiAgSG93ZXZl ciwgaXQNCndvdWxkDQpiZSBuaWNlIGlmIHRoZSBVSUQgd2FzIGluIHNvbWUgd2F5IGRpc2d1aXNl ZCBmcm9tIHRob3NlIHdobyBzdHVkeQ0KdGhpcw0KU2VjdXJpdHkgQXJ0IEZvcm0gaW4gYSBuZWdh dGl2ZSB3YXkuDQoNCkMuIEhlbnJ5IEFkYW1zDQpjaGF0bGdhMjAwMEB5YWhvby5jb208aHR0cDov L3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28u Y29tPiAoRGlyZWN0IEVtYWlsKSBjaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbTxodHRwOi8v dXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGVucnlhZGFtc0BiaWVtZWRp YWdyb3VwLmNvbT4NCg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQpvcmlnaW5hbA0KcmVjaXBpZW50LiBUaGlzIGluZm9y bWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgZGlzdHJpYnV0aW9uDQp3aXRoaW4NCnRoZQ0K cmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1cnBvc2VzIG9ubHku IEZ1cnRoZXINCmRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBwdWJsaWMgaXMgcHJv aGliaXRlZC4NCg0KUmU6IFttaWxlXSBJT0NzDQoNClN1bmRheSwgSmFudWFyeSAyNywgMjAxMyA4 OjUyIFBNDQpGcm9tOg0KIlN0b2Vja2VyLCBQYXVsIiA8UGF1bC5TdG9lY2tlckByc2EuY29tPGh0 dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPVBhdWwuU3RvZWNrZXJA cnNhLmNvbT4+DQpUbzoNCiJtaWxlQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9v LmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+IiA8bWlsZUBpZXRmLm9yZzxodHRwOi8v dXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnPj4NCkkg d291bGQgbGlrZSB0byBsb29rIGF0IHRoaXMgZnJvbSBhIHNsaWdodGx5IGRpZmZlcmVudA0KcGVy c3BlY3RpdmXFoGxldCdzIHNheSBJIGdldCBhbiBYTUwgZG9jdW1lbnQgdGhhdCB0ZWxscyBtZSBh Ym91dCBhbg0KaW5jaWRlbnQuICBUaGlzIGRvY3VtZW50IGhhcyBzb3VyY2UgSVAgYW5kIGRlc3Rp bmF0aW9uIElQIHRoYXQgaXMNCmJlaW5nIHNoYXJlZC4gIEhvd2V2ZXIsIHdoYXQgSSBkb24ndCBr bm93IGlzIHdoaWNoIElQIGFkZHJlc3MgaXMgbXkNCmluZGljYXRvciBhbmQgd2hpY2ggaXMganVz dCBhIGNvbnRleHR1YWwgcGllY2Ugb2YgaW5mb3JtYXRpb24uICBUaGlzDQptZWFucyB0aGF0IG15 IGRldGVjdGlvbiBwcm9kdWN0IGlzbid0IGdvaW5nIHRvIGtub3cgd2hpY2ggb25lIHRvIHVzZQ0K ZWl0aGVyLCBiZWNhdXNlIHRoZXJlIGlzIG5vdGhpbmcgdG8gdGVsbCBtZSB3aGljaCBJUCBpcyB0 aGUgb25lLA0KZXZlbg0KaWYgdGhlIHJvbGVzIGFyZSBzZXQgaXQgc3RpbGwgbWlnaHQgbm90IGJl IGVub3VnaCB0byB0ZWxsIG15IHN5c3RlbQ0Kd2hpY2gNCm9uZSBJIHNob3VsZCB1c2UgYXMgdGhl IGluZGljYXRvci4NCg0KSWYgd2UgaGFkIHNvbWV0aGluZyBsaWtlIGluZGljYXRvcl9pZCBhcyBh biBhdHRyaWJ1dGUsIGl0IHdvdWxkDQphbGxvdw0KdXMgdG8gZWFzaWx5IGlkZW50aWZ5IGluZGlj YXRvcnMgZnJvbSBjb250ZXh0dWFsIGRhdGEuICBJIGRvIGFkbWl0DQp0bw0KYmVpbmcgYmlhc2Vk IGFzIEkgaGF2ZSBzcGVudCBtdWNoIG9mIG15IGNhcmVlciB3b3JraW5nIG9uIHRoZQ0KbW9uaXRv cmluZyBhbmQgZGV0ZWN0aW9uIHNpZGUgb2YgdGhlc2UgdGhpbmdzLCBzbyBJIGFtIGp1c3QgdGhp bmtpbmcNCm9mIHdheXMgdG8gbWFrZSBpdCB2ZXJ5IGNsZWFyIHdoYXQgdGhlIGluZGljYXRvcnMg YXJlIGluIHRoZSBYTUwNCmRvY3VtZW50IGFuZCB0aGUgb3RoZXIgZGF0YSB0aGF0IG1heSBiZSBp bXBvcnRhbnQgYXMgSSBpbnZlc3RpZ2F0ZQ0KYWN0aXZpdHkgdGhhdCBJIGhhdmUgZGV0ZWN0ZWQg b2ZmIG9mIHRob3NlIGluZGljYXRvcnMuDQoNCg0KSSBkaWQgc3VnZ2VzdCB0aGUgZGV0ZWN0aW9u IGNsYXNzLCBidXQgSSB0aGluayB3ZSBtYXkgZ2V0IG1vcmUNCmZsZXhpYmlsaXR5IHdpdGggdGhl IGluZGljYXRvcl91aWQuICBPbmUgdGhpbmcgdGhhdCBJIGhhdmVuJ3QNCmNvbnNpZGVyZWQgaXMg dGhlIFVJRCBwb3J0aW9uIG9mIHRoaXPFoGhvdyBkbyB3ZSB1c2UgdGhhdCBVSUQ/ICBIb3cNCmlz DQp0aGUgVUlEIGNyZWF0ZWQ/ICBBcmUgdGhlcmUgc3RhbmRhcmRzIGZvciBVSURzPw0KDQpSZWdh cmRzLA0KDQpQYXVsDQoNCg0KDQpQYXVsIFcuIFN0b2Vja2VyLCBQaC5ELg0KU01DIExlYWQgQ29u dGVudCBBcmNoaXRlY3QNClJTQSwgVGhlIFNlY3VyaXR5IERpdmlzaW9uIG9mIEVNQw0KY2VsbDog MzAyLjM3OS4zMzc1IHwgZTogcGF1bC5zdG9lY2tlckByc2EuY29tPGh0dHA6Ly91cy5tYzUzNC5t YWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPXBhdWwuc3RvZWNrZXJAcnNhLmNvbT4NCg0KLS0t IE9uIFNhdCwgMS8yNi8xMywgQy4gSGVucnkgQWRhbXMgJiBCSUUgPGNoYXRsZ2EyMDAwQHlhaG9v LmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdh MjAwMEB5YWhvby5jb20+Pg0Kd3JvdGU6DQoNCkZyb206IEMuIEhlbnJ5IEFkYW1zICYgQklFIDxj aGF0bGdhMjAwMEB5YWhvby5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2Nv bXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tPj4NClN1YmplY3Q6IFJFOiBbbWlsZV0gSU9D cw0KVG86ICJLYXRobGVlbk1vcmlhcnR5IiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTxodHRw Oi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0 eUBlbWMuY29tPj4NCkNjOiBtaWxlQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9v LmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmc+DQpEYXRlOiBTYXR1cmRheSwgSmFudWFy eSAyNiwgMjAxMywgNjoxNyBQTQ0KDQpHcmVldGluZ3MgS2F0aGxlZW4sDQoNCllvdXIgbG9naWMg c3RpbXVsYXRlcyBteSB2aXNpb25hcnkgYnJhaW4gYmVjYXVzZSBJJ20gYW1hemVkIGF0IHRoZQ0K bWFueQ0KYXZlbnVlcyB5b3UgcmV2aWV3IHdpdGggdGhpcyBhcHByb2FjaCBhdCBvbmNlLiAgSG93 ZXZlciwgIGNvdWxkIHlvdQ0Kc2hhcmUNCmENCmZldyBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRh Z2VzIHRvIHRoZSBsYXR0ZXI/DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiJ3ZSBjb3VsZCBjb250aW51ZSB0byBn cm91cCBpdGVtcyBpbiBsb2dpY2FsIHBsYWNlcyBhcyBpcyBkb25lIG5vdw0KaW4NCklPREVGIGFu ZCB0aGVuIGhhdmUgdGhlIGV4dGVuc2lvbiBwb2ludCBmb3IgY29tYmluZWQgaW5kaWNhdG9ycyB2 aWENClNDSS4iDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpZb3UgcG9pbnRlZCBvdXQgd2hhdCB5b3UgY29uc2lk ZXIgdG8gYmUgbG9naWNhbCBwbGFjZXMsIGJ1dCBpZiBJDQp3YW50ZWQgdG8NCnByb3RlY3QgaW5m b3JtYXRpb24gZnJvbSBwYXJ0aWVzIGNhcGFibGUgb2YgYXNjZXJ0YWluaW5nIGl0IGZyb20geW91 cg0KbG9naWNhbCBwbGFjZXMsIHBlcmhhcHMgd2Ugc2hvdWxkIGFsc28gY29uc2lkZXIgdG8gYSBk ZWdyZWUgd2hhdA0KYXBwZWFycw0KdG8NCmJlIGlsbG9naWNhbCBpbiBicmlsbGlhbnQgbWluZHMg aW4gc29tZSBpbnN0YW5jZXMuDQoNCg0KDQpDLiBIZW5yeSBBZGFtcw0KY2hhdGxnYTIwMDBAeWFo b28uY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNoYXRs Z2EyMDAwQHlhaG9vLmNvbT4gKERpcmVjdCBFbWFpbCkNCmNoZW5yeWFkYW1zQGJpZW1lZGlhZ3Jv dXAuY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNoZW5y eWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tPg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQpvcmlnaW5hbA0KcmVjaXBpZW50 LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQgZGlzdHJpYnV0aW9uDQp3 aXRoaW4NCnRoZQ0KcmVjaXBpZW50J3MgcGxhY2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1 cnBvc2VzIG9ubHkuIEZ1cnRoZXINCmRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBw dWJsaWMgaXMgcHJvaGliaXRlZC4NCg0KLS0tIE9uIFNhdCwgMS8yNi8xMywgTW9yaWFydHksIEth dGhsZWVuIDxrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlh aG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+Pg0Kd3JvdGU6 DQoNCkZyb206IE1vcmlhcnR5LCBLYXRobGVlbiA8a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTxo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3Jp YXJ0eUBlbWMuY29tPj4NClN1YmplY3Q6IFJFOiBbbWlsZV0gSU9Dcw0KVG86ICJDLiBIZW5yeSBB ZGFtcyAmIEJJRSIgPGNoYXRsZ2EyMDAwQHlhaG9vLmNvbTxodHRwOi8vdXMubWM1MzQubWFpbC55 YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20+PiwgIm1pbGVAaWV0 Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBp ZXRmLm9yZz4iDQo8bWlsZUBpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20v bWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnPj4NCkRhdGU6IFNhdHVyZGF5LCBKYW51YXJ5IDI2 LCAyMDEzLCAxMDoxMyBBTQ0KDQpIZWxsbyBDLiBIZW5yeSAmIG90aGVycywNCg0KVGhhbmtzIGZv ciB0YWtpbmcgYSBsb29rIGF0IHRoaXMuICBXZSBoYXZlIGEgZmV3IGNvbnNpZGVyYXRpb25zIGlu DQp0aGlzDQplbWFpbCB0aHJlYWQgSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhvdWdodHMgb24gKGFu ZCB0aGVyZSBtYXkgYmUgbW9yZQ0Kb25jZQ0KUkZDNTA3MC1iaXMgaXMgYWN0aXZlbHkgZWRpdGVk KS4NCg0KVGhlIEFkZGl0aW9uYWxEYXRhIGNsYXNzIGFuZCB0aGUgUmVjb3JkSXRlbSBjbGFzcyBi b3RoIGFsbG93IGZvcg0Kbm9uLVhNTA0KZXh0ZW5zaW9ucy4gIFdoZXJlIHlvdSBwbGFjZSB0aGUg ZXh0ZW5zaW9ucyBzaG91bGQgYmUgc3BlY2lmaWMgdG8gdGhlDQpsb2dpY2FsIGdyb3VwaW5nIG9m IHRoZSBwYXJlbnQgZWxlbWVudHMgc28geW91IGNhbiB1bmRlcnN0YW5kIG1vcmUNCmFib3V0DQp0 aGUNCmluY2x1ZGVkIGRhdGEgaW4gbW9zdCBjYXNlcy4NCg0KVGhlIEltcGFjdCBjbGFzcyBjYW4g YmUgdXNlZCB0byBwcm92aWRlIGNvbnRleHQgaW5mb3JtYXRpb24gb24gdGhlDQppbmNsdWRlZCBk YXRhIG9mIHRoZSByZXBvcnQgYW5kIGFsc28gY2FuIGluY2x1ZGUgYSBjb25maWRlbmNlIHJhdGlu Zw0Kb24NCnRoZQ0KcmVwb3J0IGFzIGEgd2hvbGUuICBFeHRlbnNpb25zIHJlbGF0ZWQgdG8gaW1w YWN0IHdvdWxkIGJlIG9uZSBsZXZlbA0KaGlnaGVyDQooYXQgdGhlIG1vbWVudCkgaW4gdGhlIEFz c2Vzc21lbnQgY2xhc3MgdXNpbmcgdGhlIEFkZGl0aW9uYWxEYXRhDQpleHRlbnNpb24NCnBvaW50 Lg0KDQpUYWtlIGFza2VkIGFib3V0IGluY2x1ZGluZyB2dWxuZXJhYmlsaXR5IGluZm9ybWF0aW9u LCBJIHdvdWxkIHRoaW5rDQp0aGF0DQp3b3VsZCBmaXQgdW5kZXIgdGhlIFZ1bG5lcmFiaWxpdHkg ZXh0ZW5zaW9uIHBvaW50IG9mIHRoZSBTQ0kgZHJhZnQgaW4NCnRoZQ0KTWV0aG9kIGNsYXNzLiAg SGUgZGlkIGFzayBhYm91dCBub24tWE1MLiAgUmVjb3JkSXRlbSBvcg0KQWRkaXRpb25hbERhdGEN CmRvDQphbGxvdyBmb3Igbm9uLVhNTCBleHRlbnNpb24gcG9pbnRzLCB3ZSBjb3VsZCBlaXRoZXIg aGF2ZSB0aGUgU0NJDQpkcmFmdA0KaGFuZGxlIHRoZXNlIGFzIHdlbGwgb3IgaGF2ZSB0aGUgZXh0 ZW5zaW9ucyB0aGF0IGFyZSBub24tWE1MIGNvbWUNCmRpcmVjdGx5DQpvZmYgdGhlIEFkZGl0aW9u YWxEYXRhIG9yIFJlY29yZEl0ZW0gY2xhc3NlcyBhY2NvcmRpbmcgdG8gd2hhdCBtYWtlcw0Kc2Vu c2UNCmZyb20gYSBsb2dpY2FsIHN0YW5kcG9pbnQuDQoNCkFzIGZvciBteSBxdWVzdGlvbiwgaXQg d2FzIHR3by1mb2xkLg0KDQpJbmRpY2F0b3IgYmFzZWQgc2NoZW1hcyBoYXZlIGEgcmVmZXJlbmNl IG51bWJlciBvciBhIEdVSUQgZm9yIHRoZQ0KdmFyaW91cw0KaW5kaWNhdG9ycyB0aGV5IHNoYXJl LiAgSWYgd2UgYXJlIGV4dGVuZGluZyB0byBlbWJlZCBvdGhlciBzY2hlbWFzDQp0aGF0DQppbmNs dWRlIHN1Y2ggcmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMsIGRvIHdlIHdhbnQgdG8gYWRk IGFuDQphdHRyaWJ1dGUNCnRvIHRoZSB2YXJpb3VzIGVsZW1lbnRzIGluIElPREVGIHRoYXQgY291 bGQgYmUgaW5kaWNhdG9ycz8gIElzIHRoaXMNCmVub3VnaA0KdG8gbWFrZSB0aGUgY29ubmVjdGlv bnMgb3IgaXMgc29tZXRoaW5nIGVsc2UgZWxzZSBuZWVkZWQ/ICBXZSBjb3VsZA0KYWRkDQpzb21l dGhpbmcgbGlrZSBhbiBJbmRpY2F0b3JfSUQgaW4gUkZDNTA3MC1iaXMgd2hpY2ggd291bGQgdGhl bg0KY29ycmVsYXRlDQp0bw0KdGhlIHJlZmVyZW5jZSBvciBHVUlEIGlkZW50aWZpZXJzLg0KDQpU aGVuIHRoZSBvdGhlciBxdWVzdGlvbiB3YXMgb24gaG93IHRvIGluY2x1ZGUgaW5kaWNhdG9ycyB0 aGF0IGFyZQ0Kbm90DQppbg0KdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IGJlIHJlbGF0ZWQgb3Ig aGF2ZSBsYW5ndWFnZSB3aXRoICJhbmQiICJvciINCnRvDQpzcGVjaWZ5IHRoZSByZWxhdGlvbnNo aXBzLiAgSW4gc29tZSBjYXNlcywgeW91IHdpbGwgd2FudCB0byBncm91cA0KdGhlc2UNCmluZGlj dG9ycyBpbiBvbmUgZXh0ZW5zaW9uIHBvaW50LCB3aGVyZSB0aGV5IG1heSBmaXQgbG9naWNhbGx5 IGluDQptdWx0aXBsZQ0KcGxhY2VzIGlmIHRoZSByZWxhdGlvbnNoaXBzIGRpZCBub3QgbmVlZCB0 byBiZSBzaG93biBpbiB0aGUgZGF0YQ0KZm9ybWF0LiAgSWYNCndlIGhhdmUgY2FzZXMgbGlrZSB0 aGlzIHdoZXJlIHlvdSBuZWVkIG1vcmUgY29tcGxleCByZXByZXNlbnRhdGlvbnMsDQpzaG91bGQN CndlIHVzZSBvbmUgZXh0ZW5zaW9uIHBvaW50IHZpYSB0aGUgU0NJIGRyYWZ0IG9mZiBvZiB0aGUg RXZlbnREYXRhDQpjbGFzcw0KQWRkaXRpb25hbERhdGEgZXh0ZW5zaW9uIHBvaW50PyAgT3Bpbmlv bnMgYXJlIG5lZWRlZCBoZXJlLi4uLg0KDQpBIGZldyBwZW9wbGUgaGF2ZSBtZW50aW9uZWQgd2Fu dGluZyB0byBpbmNsdWRlIHNvbWUgY29tbW9ubHkgc2hhcmVkDQppbmRpY3RvcnMgaW50byB0aGUg YmFzZSBJT0RFRiBkb2N1bWVudC4gIFdlIGNvdWxkIGhhdmUgYSBjYXRjaC1hbGwNCmNsYXNzDQp0 aGF0IGRvZXMgdGhpcyBhbmQgaGFzIGFuIGV4dGVuc2lvbiBwb2ludCBvZmYgb2YgaXQgaW4gRXZl bnREYXRhIG9yDQp3ZQ0KY291bGQNCmNvbnRpbnVlIHRvIGdyb3VwIGl0ZW1zIGluIGxvZ2ljYWwg cGxhY2VzIGFzIGlzIGRvbmUgbm93IGluIElPREVGIGFuZA0KdGhlbg0KaGF2ZSB0aGUgZXh0ZW5z aW9uIHBvaW50IGZvciBjb21iaW5lZCBpbmRpY2F0b3JzIHZpYSBTQ0kuICBJIHRoaW5rIEkNCmxp a2UNCnRoZSBsYXR0ZXIgYXBwcm9hY2guDQoNClRoYW5rIHlvdSwNCkthdGhsZWVuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtaWxlLWJvdW5jZXNAaWV0 Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZS1i b3VuY2VzQGlldGYub3JnPiBbbWlsZS1ib3VuY2VzQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5t YWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBDLg0KSGVucnkNCkFkYW1zICYgQklFIFtjaGF0bGdhMjAwMEB5YWhvby5jb208aHR0 cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFo b28uY29tPl0NClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDI2LCAyMDEzIDM6MDUgQU0NClRvOiBt aWxlQGlldGYub3JnPGh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3Rv PW1pbGVAaWV0Zi5vcmc+DQpDYzogQy4gSGVucnkgQWRhbXMNClN1YmplY3Q6IFJlOiBbbWlsZV0g SU9Dcw0KDQpHcmVldGluZ3MgRXZlcnlvbmUsDQoNClRha2UgbWVudGlvbmVkIHR3byB0eXBlcyBv ZiBpbmRpY2F0b3JzIGJhc2VkIG9uIHRoZSA6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxKSBJZiB0aGUgaW5kaWNhdG9ycyBhcmUgc29tZXRoaW5n IGxpa2UgYW4gWE1MLWJhc2VkIGFsZXJ0L3dhcm5pbmcNCm9mDQppbmZvcm1hdGlvbiBsZWFrYWdl LCBpdCBjb3VsZCBiZSBhbiBldmVudCB0aGF0IGFyZSBjb252ZXllZCBpbiB0aGUNClNDSSdzIEV2 ZW50UmVwb3J0IGNsYXNzLCBJTUhPLg0KDQoyKSBJZiB0aGUgaW5kaWNhdG9ycyBhcmUgc29tZXRo aW5nIGxpa2UgYW4gbm9uLVhNTCBvbmVzLCBJIGd1ZXNzIGl0DQpjb3VsZA0KYmUNCmNvbnZleWVk IHdpdGhvdXQgdXNpbmcgU0NJIGRyYWZ0Lg0KRm9yIGluc3RhbmNlLCB3ZSBjb3VsZCB1c2UgSW1w YWN0IGNsYXNzIG9mIHRoZSBiYXNlIElPREVGIHRvIGNvbnZleQ0KdGhlIGluZGljYXRvcnMuDQpX ZSBjb3VsZCBmb3IgaW5zdGFuY2UgZXh0ZW5kIHRoZSBsaXN0IG9mIGluZGljYXRvcnMgb2YgdGhl IEltcGFjdA0KY2xhc3MsDQppZg0KbmVlZGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJbiBkb2luZyBzbyBoZSBwb2ludGVkIG91dCB0aGUg IkltcGFjdCBDbGFzcyINCg0KV2hlcmVhcywgS2F0aGxlZW4gc3RhdGVkLA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ci0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGb3IgdGhlIGRpc2N1c3Npb24g YmVsb3csIEkgd2FzIHRoaW5raW5nIG1vcmUgb2YgY29tYmluZWQgc2V0IHdpdGgNCnJlbGF0aW9u c2hpcHMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4gYSBzaW5nbGUgZXh0ZW5zaW9uIHBvaW50LCBz bw0KdGhhdCdzDQp3aHkgSSB3YXMgdGhpbmtpbmcgYWJvdXQgdGhlIEV2ZW50RGF0YSBjbGFzcywg YnV0IHRoZXJlIG1heSBiZSBiZXR0ZXINCmxvY2F0aW9ucyBvciBhIHNwZWNpZmljIGFyZWEgd2l0 aGluIHRoZSBFdmVudERhdGEuDQoNClBhdWwgU3RvZWNrZXIgaGFkIHN1Z2dlc3RlZCBhICJEZXRl Y3Rpb24iIGNsYXNzIGFzIGEgY29uc2lkZXJhdGlvbi4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkthdGhsZWVuIHRob3VnaHRzIHJlbGF0ZWQgeWV0 IHN0aWxsIHdpdGggb3RoZXIgaW5kaWNhdG9ycyBhbmQgdGhlDQpFdmVudERhdGEgQ2xhc3MuDQoN CklzIHRoZXJlIGEgcG9zc2libGUgd2F5IHRvIGNyZWF0ZSBhIG5ldyBYTUwgY2xhc3Mgd2hpY2gg ZW5jb21wYXNzDQpjb21iaW5pbmcgdGhlIEV2ZW50RGF0YSwgRGV0ZWN0aW9uIGFuZCBiYXNlIElP REVGIGNsYXNzZXMgdG8gc2ltcGxpZnkNCnRoaXMNCmlzc3VlPw0KDQoNCkMuIEhlbnJ5IEFkYW1z DQpjaGF0bGdhMjAwMEB5YWhvby5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tPiAoRGlyZWN0IEVtYWlsKQ0KY2hlbnJ5 YWRhbXNAYmllbWVkaWFncm91cC5jb208aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21j L2NvbXBvc2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20+DQoNCg0KVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0K b3JpZ2luYWwNCnJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVkIGZvciBsaW1p dGVkIGRpc3RyaWJ1dGlvbg0Kd2l0aGluDQp0aGUNCnJlY2lwaWVudCdzIHBsYWNlIG9mIGJ1c2lu ZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBGdXJ0aGVyDQpkaXNzZW1pbmF0aW9uLCB3 aGV0aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxpc3QNCm1pbGVA aWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWls ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlsZSBt YWlsaW5nIGxpc3QNCm1pbGVAaWV0Zi5vcmc8aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29t L21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWlsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxpc3QNCm1pbGVAaWV0Zi5vcmc8aHR0cDovL3VzLm1j NTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWxlIG1haWxpbmcgbGlzdA0KbWlsZUBp ZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWxlIG1h aWxpbmcgbGlzdA0KbWlsZUBpZXRmLm9yZzxodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20v bWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9taWxlDQoNCg0K --_000_F5063677821E3B4F81ACFB7905573F24CEBDF2E4MX15Acorpemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi55aXYyMTI4NTA2MTc5YXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5 bGUtbmFtZTp5aXYyMTI4NTA2MTc5YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgeW91IHRoaW5rIG9mIElP REVGIGp1c3QgZm9yIHRyYW5zcG9ydCwgY291bGQgeW91IG1lZXQgeW91ciBuZWVkcyB3aXRoIHN0 b3JpbmcgdGhlIHZhbHVlcyBkaWZmZXJlbnRseSBpbiBhIGRhdGFiYXNlIChJT0RFRiBpcyBqdXN0 IG1lYW50IGZvciB0aGUgZXhjaGFuZ2UpPyZuYnNwOyBUaGUgbnVtYmVycyBtYXAgdG8gbG93L21l ZC9oaWdoIOKAkyBmb3IgZGIgc3RvcmFnZSDigJMgaWYgbnVtYmVycyBhcmUgdXNlZCwgeW91IGNv dWxkIHN0b3JlIHRoZSBlcXVpdmFsZW50IHZhbHVlLCBhZGRpbmcgdGhlIDIgYWRkaXRpb25hbCBv bmVzIHByb3ZpZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RG9lcyBpdCBtYWtlIHNlbnNlIHRvIGV4 cGFuZCB0aGUgc2V0IG9mIHZhbHVlcyB0byBtYXRjaCB3aGF0IENJRiBpcyBkb2luZyBpZiB3ZSB3 ZW50IGZvcndhcmQgd2l0aCB0aGUgYXBwcm9hY2ggb2Ygc3VwcG9ydGluZyBib3RoIG9wdGlvbnM/ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkthdGhsZWVuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gbWlsZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhh bGYgT2YgPC9iPkhhcnJpbmd0b24sIENocmlzdG9waGVyPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDEzLCAyMDEzIDExOjQ5IEFNPGJyPjxiPlRvOjwvYj4gJ0MuIEhlbnJ5IEFk YW1zICZhbXA7IEJJRSc7IE1JTEUgSUVURjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFttaWxlXSBJ T0NzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5Gcm9tIGEgZGF0YSBwcm9jZXNzaW5nIHN0YW5kcG9pbnQgaXQgaXMgZ29pbmcgdG8gY3Jl YXRlIGV4dHJhIHdvcmsgZm9yIHRoZSBwZW9wbGUgd2hvIGFyZSBnb2luZyB0byByZWNlaXZlIHRo aXMgZGF0YSBpZiB3ZSBzdXBwb3J0IGJvdGggbnVtZXJpYyBhbmQgYWxwaGEgY2hhcmFjdGVycyBp biB0aGUgc2FtZSBmaWVsZC4gSSBjYW4gZW52aXNpb24gcGVvcGxlIHdhbnRpbmcgdG8gc2VhcmNo LCBzb3J0LCBzdG9yZSwgZXRjIHRoZSBkYXRhIGluIHRoaXMgZmllbGQuIElmIHdlIGFsbG93IGJv dGggZGF0YSB0eXBlcyB0aGVuIGV2ZXJ5b25lIHdpbGwgbmVlZCB0byBoYXZlIGEgbWFwcGluZyBv ZiBzb21lIHNvcnQuIEkgaGF2ZSBhIGZpZWxkIGZvciBjb25maWRlbmNlIGluIG15IHRocmVhdCB0 cmFja2luZyBkYXRhYmFzZS4gSGF2aW5nIGJvdGggYSBudW1lcmljIHNjb3JlIGFuZCBhbHBoYSBj aGFyYWN0ZXJzIC8gd29yZHMgY3JlYXRlcyBpc3N1ZXMgd2hlbiB0cnlpbmcgdG8gaW50ZXJhY3Qg d2l0aCB0aGUgZGF0YS4gSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gc3VwcG9ydCBib3RoIGhvd2V2 ZXIgSSBkb27igJl0IHRoaW5rIGJvdGggc2hvdWxkIGJlIGluIHRoZSBzYW1lIGZpZWxkLiBJIHdv dWxkIG11Y2ggcmF0aGVyIHNlZSAyIGRpZmZlcmVudCBmaWVsZHMgZm9yIENvbmZpZGVuY2UgaWYg d2UgYXJlIGdvaW5nIHRvIHN1cHBvcnQgMiBkaWZmZXJlbnQgZGF0YSB0eXBlcy4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5UaGlzIHdpbGwgYmUgYSBsYXJnZXIgaXNzdWUgc2hvdWxkIENvbmZpZGVuY2Ug YmUgdXNlZCBlbHNld2hlcmUuIElkZWFsbHkgaW4gZnV0dXJlIHJldmlzaW9ucyBJIHdvdWxkIGxp a2UgdG8gc2VlIGF0dHJpYnV0aW9uIGV4cHJlc3NlZCBhcyZuYnNwOyBzb21lIGZvcm0gb2YgYXR0 cmlidXRpb24gaXMgYWxtb3N0IGFsd2F5cyBzaGFyZWQgd2l0aCBhbiBJb0MuJm5ic3A7IEN1cnJl bnRseSB0aGVyZSBhcmUgNSBhcmVhcyB3aGVyZSB3ZSZuYnNwOyAoRU1DKSB1c2VzIGNvbmZpZGVu Y2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW5kaWNhdG9yIChob3cgY29uZmlkZW50IGFyZSB5b3Ug dGhhdCB0aGlzIGlzIGEgdmFsaWQgSW9DKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JbmRpY2F0b3JfU2V0IChob3cgY29uZmlk ZW50IGFyZSB5b3UgdGhhdCBhbGwgb2YgdGhlIGluZGNhdG9ycyBpbiB0aGUgc2V0IHNob3VsZCBi ZSBpbiB0aGUgc2V0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5DYW1wYWlnbiAoaG93IGNvbmZpZGVudCBhcmUgeW91IHRoYXQg YWxsIEluZGljYXRvcl9TZXRzIGFyZSBwYXJ0IG9mIHRoaXMgY2FtcGFpZ24pPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRocmVh dCBBY3RvciAoaG93IGNvbmZpZGVudCBhcmUgeW91IHRoYXQgdGhlIENhbXBhaWduIGlzIGF0dHJp YnV0ZWQgdG8gdGhpcyBUaHJlYXQgQWN0b3IpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRocmVhdCBBY3RvciB0eXBlIChob3cg Y29uZmlkZW50IGFyZSB5b3UgdGhhdCB0aGlzIFRoZWF0IEFjdG9yIGlzIEFQVCwgQ3JpbWV3YXJl LCBvdGhlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSB0aHJlYXQgYWN0b3IgbmFtZSBhbmQgdGhl IHRocmVhdCBhY3RvciB0eXBlIGFyZSB1c3VhbGx5IHRoZSBmaXJzdCAyIHRoaW5ncyB0aGF0IGFu eW9uZSBwcm9jZXNzaW5nIElvQ3Mgd2FudHMgdG8ga25vdyBhcyB0aGV5IGRyaXZlIHByaW9yaXR5 LiAmbmJzcDtLbm93aW5nIGhvdyBzdXJlIHRoZSBzZW5kZXIgaXMgdGhhdCB0aGlzIElvQyBpcyBB UFRpcyBhIHZpdGFsIHBpZWNlIG9mIGluZm9ybWF0aW9uIGZvciB1cy4gJm5ic3A7U29ycnkgdG8g dGFrZSB1cyBhIGxpdHRsZSBvZmYgdGhlIHBhdGggYnV0IEkgd2FudGVkIHRvIHNob3cgd2hlcmUg Q29uZmlkZW5jZSBjb3VsZCBiZSB1c2VkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLUNocmlzPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZyI+bWls ZS1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOm1pbGUtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8 L2I+Qy4gSGVucnkgQWRhbXMgJmFtcDsgQklFPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDEzLCAyMDEzIDEwOjI0IEFNPGJyPjxiPlRvOjwvYj4gTUlMRSBJRVRGPGJyPjxiPlN1 YmplY3Q6PC9iPiBSZTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJs ZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCB2YWxpZ249dG9w IHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPkFnYWluLCBJ IHdvdWxkIGNvbmN1ciB0aGF0IGJvdGggYSBudW1lcmljIGFuZCBzdWJqZWN0aXZlIGFuYWx5c2lz IG9mIHRoZSBDb25maWRlbmNlIFJhdGluZyBuZWVkcyB0byBiZSBleHByZXNzLCBidXQgY29tYmlu ZWQgaW4gYSBzaW1wbGlmaWVkIHNjaGVtYSBhcyBzdWNoIGJlbG93Ojxicj48YnI+Jmx0O0NvbmZp ZGVuY2UgcmF0aW5nPSZxdW90OyBBbHBoYW51bWVyaWMmcXVvdDsmZ3Q7MUxMJmx0Oy8mZ3Q7IC4u Li4gZXRjLjxicj48YnI+Jmx0O0NvbmZpZGVuY2UgcmF0aW5nPSZxdW90OyBBbHBoYW51bWVyaWMm cXVvdDsmZ3Q7MlAmbHQ7LyZndDs8YnI+PGJyPiZsdDtDb25maWRlbmNlIHJhdGluZz0mcXVvdDsg QWxwaGFudW1lcmljJnF1b3Q7Jmd0OzNBQyZsdDsvJmd0Ozxicj48YnI+Jmx0O0NvbmZpZGVuY2Ug cmF0aW5nPSZxdW90OyBBbHBoYW51bWVyaWMmcXVvdDsmZ3Q7NFUmbHQ7LyZndDs8YnI+PGJyPiZs dDtDb25maWRlbmNlIHJhdGluZz0mcXVvdDsgQWxwaGFudW1lcmljJnF1b3Q7Jmd0OzVJJmx0Oy8m Z3Q7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+KCBpLmUuJm5ic3A7Jm5i c3A7MSA9IExlc3MgTGlrZWx5LCZuYnNwOyZuYnNwOyAyID0gUHJvYmFibGUsJm5ic3A7Jm5ic3A7 MyA9IEEgQ29uY2VybiwmbmJzcDsmbmJzcDs0ID0mbmJzcDsmbmJzcDtVcmdlbnQsIDUgPSBJbW1p bmVudCApPGJyPjxicj5IZXJlJ3MgbXkgcG9pbnQsIHBlcmhhcHMgYSBzZXQgb2YgbnVtZXJpYyBy ZWxhdGVkIG9yIGFzc29jaWF0ZWQgZGVmaW5pdGlvbnMgY2FuIGxvd2VyIHRoZSBwcm9wYWdhdGlv biBvZiBlcnJvciByZWdhcmRpbmcgdGhlIGFuYWx5c2lzLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPlRoYW5rcyw8YnI+Qy4gSGVucnkgQWRh bXM8YnI+PGJyPjxicj5JIGFncmVlIHRoYXQgd2hhdCB3ZSByZWFsbHkgbmVlZCBpcyBib3RoLiAm bmJzcDtJbiBtb3N0IHNpdHVhdGlvbnMgYSBsb3csIG1lZGl1bSBhbmQgaGlnaCBtYXkgYmUgYWNj ZXB0YWJsZSBidXQgdGhlcmUgYXJlIHRpbWVzIHdoZW4gd2Ugd2lsbCB3YW50IHRvIHNob3cgdGhh dCBjb25maWRlbmNlIGluIGEgc2l0dWF0aW9uIGlzIGluY3JlYXNpbmcgb3IgZGVjcmVhc2luZy4g Jm5ic3A7SWYgd2UgYXJlIG9ubHkgbG9va2luZyBhdCBhIHRocmVlIGxldmVscywgd2UgY2Fubm90 IGV4cHJlc3Mgd2hhdCBpcyBuZWVkZWQgdG8gc2hvdyBjb25maWRlbmNlIGlzIHRyZW5kaW5nIHVw IG9uIHRoZSBkYXRhIGJlaW5nIGV4Y2hhbmdlZCBhYm91dCB0aGUgZXZlbnQuPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+S2F0aGxlZW4gaW5jbHVkZWQgdGhlIGZvbGxvd2lu ZyBpbiBhIHByZXZpb3VzIG1lc3NhZ2UuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25z b2xhcyc+Jmx0O0NvbmZpZGVuY2UgcmF0aW5nPSZxdW90O2xvdyZxdW90Oy8mZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPlZzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz4mbHQ7Q29uZmlkZW5jZSByYXRpbmc9JnF1b3Q7bnVtZXJp YyZxdW90OyZndDs4NSZsdDsvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5JIHJlYWxseSB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGUgYm90aCBj YXBhYmlsaXRpZXMgYXMgSm9obiBhbGx1ZGVkIHRvIHNpbmNlIGNvbmZpZGVuY2UgaXMgbm90IGEg dGhyZWUgdGllcmVkIGl0ZW0gYnV0IHNvbWV0aGluZyB0aGF0IGlzIGluZGVlZCBzdWJqZWN0aXZl IGFuZCB3ZSBuZWVkIGEgbWVhbnMgdG8gc2hvdyBhIHJlYXNvbmFibHkgYWNjdXJhdGUgY29uZmlk ZW5jZSBpbmRleCB0aGF0IHRoZSBzZW5kZXIgaXMgdHJ5aW5nIHRvIGNvbnZleS48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+ S2VudCBMYW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcxJz48YnI+PGJy PjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5N Y0FmZWUgfCBBbiBJbnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25nPjxicj48c3BhbiBjbGFzcz15 aXYyMTI4NTA2MTc5YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNw Ozwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9eWl2MjEyODUwNjE3OWFwcGxlLXN0eWxlLXNwYW4+TW9i aWxlOiArMS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5ic3A7PC9zcGFuPjwvc3Ryb25nPjxz cGFuIGNsYXNzPXlpdjIxMjg1MDYxNzlhcHBsZS1zdHlsZS1zcGFuPjxhIGhyZWY9Imh0dHA6Ly93 d3cubWNhZmVlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6IzYwNkE3 MSc+d3d3Lm1jYWZlZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPiZsdDtCYW5naGFydCZndDssIEpvaG4gQmFuZ2hhcnQgJmx0OzxhIGhyZWY9Imh0dHA6Ly91 cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWpvaG4uYmFuZ2hhcnRAbmlzdC5n b3YiIHRhcmdldD0iX2JsYW5rIj5qb2huLmJhbmdoYXJ0QG5pc3QuZ292PC9hPiZndDs8YnI+PGI+ RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTMgNzoxNiBBTTxicj48Yj5Ubzog PC9iPiZxdW90O1N0b2Vja2VyLCBQYXVsJnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1QYXVsLlN0b2Vja2VyQHJzYS5jb20iIHRh cmdldD0iX2JsYW5rIj5QYXVsLlN0b2Vja2VyQHJzYS5jb208L2E+Jmd0OywgS2F0aGxlZW4gTW9y aWFydHkgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21w b3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXRobGVl bi5tb3JpYXJ0eUBlbWMuY29tPC9hPiZndDssIEJyaWFuIFRyYW1tZWxsICZsdDs8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz10cmFtbWVsbEB0aWsu ZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1tZWxsQHRpay5lZS5ldGh6LmNoPC9hPiZn dDs8YnI+PGI+Q2M6IDwvYj4mcXVvdDtDLiBIZW5yeSBBZGFtcyAmYW1wOyBCSUUmcXVvdDsgJmx0 OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWNo YXRsZ2EyMDAwQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNoYXRsZ2EyMDAwQHlhaG9vLmNv bTwvYT4mZ3Q7LCBNSUxFIElFVEYgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlh aG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5taWxl QGlldGYub3JnPC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbbWlsZV0gSU9DczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UGF1bCw8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGFncmVlIHRoYXQgY29uZmlkZW5jZSBpcyBzdWJq ZWN0aXZlLCBidXQgc3ViamVjdGl2aXR5IGNhbiBiZSByZWR1Y2VkPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2l0aGluIGNvbW11bml0aWVzIHRoYXQgaW50ZXJh Y3QgZnJlcXVlbnRseS4mbmJzcDsmbmJzcDtQcmlvcml0aXphdGlvbiBvZiBpbmRpY2F0b3JzPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YW5kIHJlc3BvbnNlIGJl dHdlZW4gdGlnaHRseSBjb25uZWN0ZWQgc2hhcmluZyBwYXJ0bmVycyBtaWdodCByZXF1aXJlIGE8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5tb3JlIHNwZWNpZmlj IGxldmVsIG9mIGRldGFpbCwgcGFydGljdWxhcmx5IGR1cmluZyBhIGNyaXNpcyBzaXR1YXRpb24u PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RnJvbSB0aGF0IHBlcnNwZWN0 aXZlLCBJIHRoaW5rIHRoZSBndWlkYW5jZSBzaG91bGQgYWxsb3cgZm9yIGFkZGl0aW9uYWw8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ncmFudWxhcml0eSwgd2hp bGUgc3RyZXNzaW5nIHRoZSAmcXVvdDtoaWdoLCBtZWRpdW0sIGxvdyZxdW90OyBhcyBwcmVmZXJy ZWQgZm9yPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YnJvYWQg aW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4t Sm9objxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIDIvMTMvMTMgODow NCBBTSwgJnF1b3Q7U3RvZWNrZXIsIFBhdWwmcXVvdDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5t YzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPVBhdWwuU3RvZWNrZXJAcnNhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPlBhdWwuU3RvZWNrZXJAcnNhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43 NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgbWF5IGhhdmUgYmVlbiB0b28gc3VjY2luY3QgaW4gbXkg cmVzcG9uc2UgOy0pPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q29uZmlk ZW5jZSBpcyBhIHN1YmplY3RpdmUgdGhpbmcsIHNvIEkgdGhpbmsgd2Ugc2hvdWxkIHVzZSBzdWJq ZWN0aXZlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGVybXM6 Jm5ic3A7Jm5ic3A7TG93LCBNZWRpdW0sIEhpZ2guJm5ic3A7Jm5ic3A7SGF2aW5nIGEgbnVtZXJp YyBzY2FsZSB3aXRoIGEgbWFwIHRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5lc3NlbnRpYWxseSB3b3VsZCBzYXkgc29tZXRoaW5nIGxpa2U6PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+MS0zMyA9IExvdzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjM0LTY3PSBNZWRpdW08bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD42OC0xMDA9SGlnaDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPklzIGp1c3QgYSBtb3JlIGNvbXBsaWNhdGVkIHdheSBvZiBz YXlpbmcgdGhhdCBzb21ldGhpbmcgaXMgTG93LCBNZWRpdW0sPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGlnaC4uLmRvIHdlIHJlYWxseSB0aGluZyB0aGF0IGhv dyBIaWdoIHNvbWV0aGluZyBpcyBtYWtlcyB0aGF0IG11Y2ggb2YgYTxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRpZmZlcmVuY2U/PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyBpcyBsaWtlIHdoZW4geW91IGdldCB5b3VyIFBlcmZv cm1hbmNlIHJldmlldyB3aGVyZSBpdCBpcyBEb2VzIE5vdDxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1lZXQsIE1lZXRzIGFuZCBFeGNlZWRzLi4ueW91ciBib3Nz IHRlbGxzIHlvdSB0aGF0IHlvdSBhcmUgYSBIaWdoPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+TWVldHMuLi55b3VyPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Ym9udXMgdGVsbHMgeW91IHRoYXQgeW91IGdvdCB0aGUgc2FtZSBi b251cyB0aGF0IGFsbCB0aGUgb3RoZXIgTWVldHMgZ290PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Oy0pPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+QW55d2F5LCBJIGRpZ3Jlc3MgYnV0IHRyeWluZyB0byBwcm92ZSBhIHBvaW50IHRoYXQg SSB3b3VsZCBhcmd1ZSB0aGF0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Y29uZmlkZW5jZSBpbiB0aGlzIGNhc2UgaXMgZ29pbmcgdG8gYmUgYmFzaWNhbGx5IGEg Z3V0IGZlZWxpbmcsIHNvIHdoeSB1c2U8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5udW1lcmljIHZhbHVlcyB3aGVuIExvdywgTWVkaXVtLCBIaWdoIHdvdWxkIGRv IGp1c3QgZmluZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QYXVsIFcuIFN0b2Vj a2VyLCBQaC5ELjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNN QyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+UlNBLCBUaGUgU2VjdXJpdHkgRGl2aXNpb24gb2YgRU1DPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y2VsbDogMzAyLjM3OS4zMzc1IHwgZTog PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89cGF1 bC5zdG9lY2tlckByc2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGF1bC5zdG9lY2tlckByc2EuY29t PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPk9uIDIvMTMvMTMgNzo0OCBBTSwgJnF1b3Q7TW9yaWFydHksIEthdGhsZWVu JnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29t cG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0aGxl ZW4ubW9yaWFydHlAZW1jLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+d3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGVsbG8sPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Qm90aCBhcHByb2FjaGVzIHdpbGwg dmFsaWRhdGUgaW4gdGhlIGN1cnJlbnQgc2NoZW1hLiZuYnNwOyZuYnNwO1RoZSByZXByZXNlbnRh dGlvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmxvb2tzIGEg bGl0dGxlIGRpZmZlcmVudCBmb3IgZWFjaCwgaGVyZSBpcyBhbiBleGFtcGxlOjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDtDb25maWRlbmNlIHJhdGluZz0mcXVvdDts b3cmcXVvdDsvJmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlZzOjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDtDb25maWRlbmNlIHJhdGlu Zz0mcXVvdDtudW1lcmljJnF1b3Q7Jmd0Ozg1Jmx0Oy8mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+U2VhcmNoaW5nIGNhcGFiaWxpdHkgaXMgYSBncmVhdCBwb2ludCwg YWdyZWVkLiZuYnNwOyZuYnNwO0knZCBsaWtlIHRvIGhlYXIgZnJvbTxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm1vcmUgcGVvcGxlIHRvIG1ha2Ugc3VyZSB3ZSBk b24ndCBsb3NlIGEgY2FwYWJpbGl0eSB0aGF0IG90aGVycyBmaW5kPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXh0cmVtZWx5IHVzZWZ1bCAobmVlZCB0byBnYXVn ZSB0aGF0KS4mbmJzcDsmbmJzcDtPdGhlciBvcHRpb25zIGlzIHRoYXQgdGhlPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Z3VpZGFuY2UgY2FuIGFsc28gZGlzY291 cmFnZSB0aGUgdXNlIG9mIHRoZSBudW1lcmljIGluIGFkZGl0aW9uIHRvPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c3BlY2lmeWluZyBob3cgdG8gc2VsZWN0IHJh bmdlcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Bbnkgb3RoZXIgb3Bp bmlvbnM/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzLDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkthdGhsZWVuPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiBTdG9lY2tl ciwgUGF1bDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTMgNzoxNCBBTTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBCcmlhbiBUcmFtbWVsbDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNjOiBNb3JpYXJ0eSwgS2F0aGxlZW47IEMu IEhlbnJ5IEFkYW1zICZhbXA7IEJJRTsgTUlMRSBJRVRGPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUmU6IFttaWxlXSBJT0NzPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2FudCB3ZSBtYWtlIENvbmZpZGVuY2UgYSBMaXN0 IHRoYXQgaGFzIG9ubHkgMyB2YWx1ZXM6Jm5ic3A7Jm5ic3A7SGlnaCwgTWVkaXVtLCBhbmQ8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Mb3c/Jm5ic3A7Jm5ic3A7 QW55IG90aGVyIHZhbHVlIG1lYW5zIHRoYXQgdGhlIERvY3VtZW50IHdpbGwgbW90IHZhbGlkYXRl IGFnYWluc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGUg c2NoZW1hLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlbnQgZnJvbSBt eSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBGZWIgMTMs IDIwMTMsIGF0IDI6MTQgQU0sICZxdW90O0JyaWFuIFRyYW1tZWxsJnF1b3Q7ICZsdDs8YSBocmVm PSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz10cmFtbWVsbEB0 aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1tZWxsQHRpay5lZS5ldGh6LmNoPC9h PiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF Ij48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSwgS2F0aGxlZW4sIGFsbCw8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHRoaW5rIDMuMTAuNCBpbiA1MDcwIHRha2VzIHRo ZSByaWdodCBhcHByb2FjaCBoZXJlOiB0cnlpbmcgdG8gYnVpbGQ8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbnRlcm9wZXJhYmxlIG51bWVyaWMgc2NhbGVzIGZv ciBhc3Nlc3NtZW50IGlzIGEgdmVyeSBoYXJkIHByb2JsZW0uPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+KFdlcmUgSSBjaGFyZ2VkIHdpdGggZGVmaW5pbmcgc3Vj aCBhIHNjYWxlLCB0aGUgdmFsdWUgJnF1b3Q7NzAmcXVvdDsgd291bGQgbWVhbjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90O3dlIGNvbXBhcmVkIHRoaXMg aW5jaWRlbnQgcmVwb3J0IHRvIE4gcGFzdCBzaW1pbGFyIGluY2lkZW50IHJlcG9ydHM8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hY2NvcmRpbmcgdG8gc2ltaWxh cml0eSBhbGdvcml0aG0gUywgYW5kIDcwJSBvZiB0aGUgcGFzdCByZXBvcnRzIGhhZDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFzc2Vzc2VkIGltcGFjdHMgd2l0 aGluIEUlIG9mIHRoZSBhY3R1YWwsIG1lYXN1cmVkIGZpbmFsIGltcGFjdCAtLSBJPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhpbmsgZm9yIG1vc3QgYXBwbGlj YXRpb25zIHRoaXMgaXMgdmFzdGx5IG1vcmUgZGlmZmljdWx0IGFuZCByaWdvcm91czxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYW4gaXQgbmVlZHMgdG8gYmUu KTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlVubGVzcyBhIG51bWVyaWMg Q29uZmlkZW5jZSB2YWx1ZSBpcyBiYXNlZCBvbiBzb21lIGFjdHVhbCwgcmVwZWF0YWJseTxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm1lYXN1cmFibGUgYXNwZWN0 IG9mIHRoZSBBc3Nlc3NtZW50IHJlcG9ydCAtLSB3aGljaCBJIHN1c3BlY3QgaW48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5tYW55L21vc3QvYWxsIGNhc2VzIGl0 J3Mgbm90IC0tIHRoZW4gaXQganVzdCByZXByZXNlbnRzIGEgZ3Vlc3MsIGhvd2V2ZXI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5lZHVjYXRlZC4mbmJzcDsmbmJz cDtFYWNoIHRlYW0gd2lsbCBwcm9iYWJseSBuYXR1cmFsbHkgdHVuZSBpdHMgb3duIHNjYWxlcyBz dWNoPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhhdCBlYWNo IHZhbHVlIGdlbmVyYWxseSBtZWFucyB0aGUgc2FtZSB0aGluZyBpbiBlYWNoIHJlcG9ydC4gQWNy b3NzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGVhbXMsIEkg ZG9uJ3Qga25vdy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiB0aGUg b3RoZXIgaGFuZCwgQXNzZXNzbWVudHMgYXJlIGJ5IHRoZWlyIHZlcnkgbmF0dXJlIGVkdWNhdGVk PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Z3Vlc3NlcywgYW55 d2F5LCBzbyBJIGRvbid0IGtub3cgdGhhdCBJJ2QgZmluZCBtdWNoIHVzZSBpbiBhdXRvbWF0aW5n IGE8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZXNwb25zZSBi YXNlZCBvbiB0aGUgYXNzZXNzbWVudCBjb25maWRlbmNlLiBDaHJpcyBoYXMgYSBnb29kIHBvaW50 LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRob3VnaCAtLSBp dCBtYWtlcyBzZWFyY2hpbmcgZGlmZmljdWx0IGFuZCBzb3J0aW5nIGtpbmQgb2YgcG9pbnRsZXNz LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHdlJ3ZlIHNlZW4gYSBn ZW5lcmFsIHRyZW5kIHRvd2FyZCAmcXVvdDswID0gMCUsIDEwMCA9IDEwMCUmcXVvdDssIHRoZW4g STxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFncmVlLCB3ZSBz aG91bGQgcHV0IHRoYXQgaW4gdGhlIGd1aWRhbmNlIGRvY3VtZW50IChhbG9uZyB3aXRoIGEgbm90 ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYXQgMC0zMyBt YXAgdG8gbG93LCAzNCAtIDY2IG1hcCB0byBtZWRpdW0sIGFuZCA2NyAtIDEwMCBtYXAgdG8gaGln aCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD51bmxlc3Mgd2Ug d2FudCB0byBkbyBpdCBub24tbGluZWFybHkpLiBJZiB0aGUgX3Zhc3RfbWFqb3JpdHlfIG9mIHRo ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnVzZXJzIG9mIHRo aXMgZmllbGQgdXNlIGEgMTAwLXBvaW50IHNjYWxlIHdpdGggMTAwIG1lYW5pbmcgJnF1b3Q7eWVz JnF1b3Q7IGFuZCAwPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ bWVhbmluZyAmcXVvdDthbnkgcmVzZW1ibGFuY2UgdGhlc2UgdmFsdWVzIG1heSBoYXZlIHRvIGFj dHVhbCBmYWN0IGlzIHB1cmVseTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPmNvaW5jaWRlbnRhbCZxdW90OywgdGhlbiBsZXQncyBjb25zaWRlciByZW5hbWluZyBp dCAmcXVvdDtwZXJjZW50JnF1b3Q7IGluIDUwNzAtYmlzLjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5CcmlhbiAoYXMgY29udHJpYnV0b3IpPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+T24gRmViIDEyLCAyMDEzLCBhdCA5OjU2IFBNLCAmcXVvdDtNb3JpYXJ0eSwgS2F0 aGxlZW4mcXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m bHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89 a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlh cnR5QGVtYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QbGVh c2Ugc2VlIHNlY3Rpb24gMy4xMC40IG9mIFJGQzUwNzAgYXMgYSBzdGFydGluZyBwb2ludC4mbmJz cDsmbmJzcDtXZSBjYW48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5jaGFuZ2UgaXQgaWYgaXQgbmVlZHMgdG8gYmUgY2hhbmdlZC4mbmJzcDsmbmJzcDtUaGUgdmFs dWUgaXMgZm9yIGEgY29uZmlkZW5jZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPnJhdGluZyBvbiB0aGUgaW5kaWNhdG9ycyBzaGFyZWQuJm5ic3A7Jm5ic3A7VGhl IGRlZmluaXRpb25zIG1heSBiZSBoZWxwZnVsIGZvcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmFueW9uZSB3aG8gd2FudHMgdG8gd29yayBvbiB0aGlzIGRpc2N1 c3Npb24uJm5ic3A7Jm5ic3A7SU9ERUYgaGFzIHZhcmlvdXMgbWFya2VyczxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYXQgY2FuIGJlIHVzZWQgaW4gYSBjb21w bGltZW50YXJ5IHdheSB3aXRob3V0IGNvbmZsYXRpbmcgdGhlIG1hcmtlcnM8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5tZWFuaW5nLjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgdGhpbmsgc29tZSBwZW9wbGUgdXNpbmcgSU9ERUYgZmlu ZCB0aGUgbnVtZXJpY2FsIHZhbHVlcyBtb3JlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+aGVscGZ1bCwgYW5kIGl0IHdvdWxkIGJlIGdvb2QgdG8gdW5kZXJzdGFu ZCB3aGF0IHBlb3BsZSBoYXZlIGxlYXJuZWQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5mcm9tIHVzaW5nIHRoZSBjdXJyZW50IHN0cnVjdHVyZSAod2hhdCB3b3Jr cy9kb2VzIG5vdCB3b3JrKS4mbmJzcDsmbmJzcDtUaGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5zY2FsZXMgSSBoYXZlIHNlZW4gYXJlIDAtMTAwLiZuYnNwOyZu YnNwO1RoZXJlIGlzIG9mIGNvdXJzZSBhIHN1YmplY3RpdmUgZWxlbWVudDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRvIGFzc2lnbmluZyBhIG51bWVyaWNhbCB2 YWx1ZSB0byB0aGUgY29uZmlkZW5jZSBhbmQgaXQgbWF5IHZhcnkgZnJvbTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmVudGl0eSB0byBlbnRpdHkuJm5ic3A7Jm5i c3A7V2l0aCB0aGlzIHR5cGUgb2YgcmF0aW5nIHlvdSBtYXkgbmVlZCB0byBjb25zaWRlcjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPndobyBpdCBjYW1lIGZyb20g YW5kIGhvdyB0aGV5IHNjb3JlZCB0aGUgY29uZmlkZW5jZSByYXRpbmcgdG8gbWFwIHRvPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+eW91ciBvd24gcmF0aW5nLiZu YnNwOyZuYnNwO0l0IHdvdWxkIGJlIGdvb2QgdG8gaGVhciBtb3JlIHRob3VnaHRzIG9uIHRoaXMu PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkthdGhsZWVuPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RnJvbTogQy4gSGVucnkgQWRhbXMgJmFtcDsgQklFIFs8 YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0 bGdhMjAwMEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86Y2hhdGxnYTIwMDBAeWFo b28uY29tPC9hPl08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5T ZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyAyOjQ2IFBNPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VG86IE1JTEUgSUVURjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNjOiBNb3JpYXJ0eSwgS2F0aGxlZW47ICdUYWtl c2hpIFRha2FoYXNoaSc7IFN0b2Vja2VyLCBQYXVsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUmU6IFttaWxlXSBJT0NzPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+UmVnYXJkaW5nIHRoZSBJT0NzIG9yIEluZGljYXRvcnMgb2YgQ29t cHJvbWlzZSwgQ2hyaXMgbWFkZSBhIHZpdGFsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+cG9pbnQuJm5ic3A7Jm5ic3A7RGlmZmVyZW50IENvbmZpZGVuY2UgbGV2 ZWxzIHdpbGwgY2F1c2UgY29uZnVzaW9uLiZuYnNwOyZuYnNwO0l0IGFwcGVhcnM8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGF0IHRoZXJlIG1heWJlIGEgbmVl ZCBmb3Igc29tZSB0eXBlIG9mIHNpbXBsaWZpZWQgc3RhbmRhcmRpemF0aW9uIHRvPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YmUgZXN0YWJsaXNoZWQgYmV0d2Vl biBhbGwgU2hhcmluZyBHcm91cHMgaW4gdGhpcyByZWdhcmQuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+UGVyaGFwcyBudW1lcmljYWwgc2NvcmluZyBzZXQgYXQgbG93ZXIg dmFsdWVzIHNob3VsZCBleHByZXNzIGxldmVscyBvZjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnVyZ2VuY3kuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+KCBpLmUuJm5ic3A7Jm5ic3A7MSA9IExlc3MgTGlrZWx5LCZuYnNwOyZu YnNwOyAyID0gUHJvYmFibGUsJm5ic3A7Jm5ic3A7MyA9IEEgQ29uY2VybiwmbmJzcDsmbmJzcDs0 ID0mbmJzcDsmbmJzcDtVcmdlbnQsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+NSA9IEltbWluZW50ICk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5UaGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Qy4gSGVucnkgQWRhbXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHNlZSBzb21lIGNvbmZ1 c2lvbiBjb21pbmcgZG93biB0aGUgcGlrZSBpZiB3ZSBzdGFydCB1c2luZyBDb25maWRlbmNlPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2F5IGl0IGlzIHN1cHBvcnRlZC4gSWYg SSBhbSB1c2luZyBsb3cvbWVkL2hpZ2ggYW5kIHNvbWVvbmUgc2VuZHMgbWU8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hbiBJb0M8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53aXRoIGEgc2NvcmUgb2YgNzAsIHdoYXQgZG9lcyB0 aGF0IG1lYW4gdG8gbWU/IFdoYXQgaWYgSSBhbSB1c2luZyBhPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c2NhbGUgb2Y8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4xIHRvIDQgYW5kIHNvbWVvbmUgZWxzZSBpcyBvbiBhIHNjYWxl IG9mIDEgdG8gNT8gV2UgbG9zZSB0aGUgYWJpbGl0eTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnRvPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+ZGVzY3JpYmUgc29tZXRoaW5nIHdpdGggYSBjb25zaXN0ZW50IGxhbmd1YWdlLiBJ dCByZWFsbHkgZ2V0cyB1Z2x5PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+d2hlbiB3ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PnN0b3JlIElvQyBmcm9tIG11bHRpcGxlIHNvdXJjZXMuIEkgaGF2ZSBjb25maWRlbmNlIHZhbHVl cyB0aGF0IGFyZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm51 bWVyaWM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hcyB3ZWxs IGFzIHRleHQuJm5ic3A7Jm5ic3A7TWFrZXMgc2VhcmNoaW5nIC8gc29ydGluZyB2ZXJ5IHByb2Js ZW1hdGljLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkF0IHRoaXMgcG9p bnQgd2UgaGF2ZSB0byByb2xsIHdpdGggd2hhdCB3ZSBoYXZlLiBJIHdvdWxkIHN0cm9uZ2x5PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cmVjb21tZW5kPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhhdCB3ZSByZXZpc2l0IHRo aXMgYXQgc29tZSBwb2ludC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5U aGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS1DaHJpczxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RnJvbTogTW9y aWFydHksIEthdGhsZWVuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgOTo1OSBBTTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhl cjsgJ1Rha2VzaGkgVGFrYWhhc2hpJzsgU3RvZWNrZXIsIFBhdWw7PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+J01JTEU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5JRVRGJzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlN1YmplY3Q6IFJFOiBbbWlsZV0gSU9DczxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkhpIENocmlzICZhbXA7IFRha2UsPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+SSdsbCBqdXN0IGZvY3VzIG9uIHRoZSBjb25maWRlbmNlIHNj b3JpbmcuJm5ic3A7Jm5ic3A7UmlnaHQgbm93LCB0aGUgc2NoZW1hPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YWxsb3dzIGZvcjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnlvdSB0byBlaXRoZXIgdXNlIGEgbnVtZXJpY2FsIHNj b3JlIE9SIHRoZSByYXRpbmdzIG9mIGxvdywgbWVkaXVtLCBhbmQ8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5oaWdoLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkRpZmZlcmVudCBzaGFyaW5nIGdyb3VwcyBjYW4gZGVjaWRlIGhv dyB0aGV5IHdhbnQgdG8gc2hhcmUgdGhlIGRhdGEuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+SWY8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5wZW9wbGUgd2VyZSB0byB1c2UgdGhlIG51bWVyaWNhbCB2YWx1ZXMsIEkgYWdyZWUg aXQgd291bGQgYmUgaGVscGZ1bDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPnRvIGhhdmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5ndWlkYW5jZS4mbmJzcDsmbmJzcDtUaGlzIGNvdWxkIGdvIGluIHRoZSBJT0RFIGd1aWRhbmNl IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgaGF2ZSBz ZWVuIGV4YW1wbGVzIG9mIGN1cnJlbnQgdXNlcnMgdGhhdCB1c2UgZWFjaCBvZiB0aGUgYXBwcm9h Y2hlcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zbzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPndlJ2xsIG5lZWQgdG8ga2Vl cCB0aGUgb3B0aW9uIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhbmQgaXQgaXM8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5uaWNlIHRvPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+a2VlcCBpbiBmbGV4aWJsZSBvcHRpb25z IHdoZXJlIHdlIGNhbi48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFu ayB5b3UsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+S2F0aGxl ZW48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZy b206IEhhcnJpbmd0b24sIENocmlzdG9waGVyPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTMgOToyMiBBTTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiAnVGFrZXNoaSBU YWthaGFzaGknOyBNb3JpYXJ0eSwgS2F0aGxlZW47IFN0b2Vja2VyLCBQYXVsOyAnTUlMRTxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklFVEYnPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUkU6IFttaWxlXSBJT0Nz PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIG51bWJlciBvZiBpbmRp Y2F0b3JzIHdvdWxkbid0IG5lY2Vzc2FyaWx5IGRyaXZlIHRoZSB1c2Ugb2Y8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmRpY2F0b3Jfc2V0X2lkLiBUaGUgcHVy cG9zZSBpcyB0byBzaG93IHJlbGF0aW9uc2hpcC4gSWYgSSBzZW50IDMgSVA8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hZGRyZXNzZXMgdGhhdCB3ZXJlIHVzZWQg YXMgQzIgZm9yIDMgZGlmZmVyZW50IGNhbXBhaWducyBJIHdvdWxkIGhhdmU8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zZXBhcmF0ZSBpbmRpY2F0b3Jfc2V0X2lk cywgZWFjaCB3aXRoIG9uZSBvZiB0aGUgMyBDMiBJUHM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5NeSBzdWdnZXN0aW9uIHdvdWxkIGJlIGEgc2ltcGxlIGxvdywgbWVkaXVt LCBoaWdoLiBJIHRoaW5rIGlmIHdlIGJyZWFrPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+aXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5kb3duIHRvIG1vcmUgbGV2ZWxzIHRoYW4gdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIHByb3Zp ZGUgZ3VpZGFuY2Ugb248bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5zY29yaW5nLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnJh dGluZywgZXRjLiBJIHRoaW5rIG1vc3QgcGVvcGxlIHNob3VsZCBiZSBhYmxlIHRvIHVuZGVyc3Rh bmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5sb3cvbWVkL2hp Z2g8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53aXRob3V0IGhh dmluZyB0byBoYXZlIGEgbWF0aGVtYXRpY2FsIG1ldGhvZCBmb3IgYXJyaXZpbmcgYXQgdGhlPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bGV2ZWwuPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+TG93IC0gSSBhbSBub3Qgc3VyZTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1lZGl1bSAtIEkgYW0gcmVhc29u YWJseSBzdXJlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGln aCAtIEkgYW0gdmVyeSBzdXJlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tQ2hyaXM8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZyb206IFRha2VzaGkg VGFrYWhhc2hpIFs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29t cG9zZT90bz10YWtlc2hpX3Rha2FoYXNoaUBuaWN0LmdvLmpwIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanA8L2E+XTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDEz IDQ6MjEgQU08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Ubzog SGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7IE1vcmlhcnR5LCBLYXRobGVlbjsgU3RvZWNrZXIsIFBh dWw7ICdNSUxFPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SUVU Ric8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBS RTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWdh cmRpbmcgdGhlIGluZGljYXRvcl9zZXRfaWQsIEkgYWdyZWUsIGl0IGlzIHVzZWZ1bCB3aGVuIHdl IG5lZWQgdG88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5kZWFs PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2l0aCBsYXJnZSBz ZXRzIG9mIGluZGljYXRvcnMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+U2luY2UgaW5kaWNhdG9yX3NldF9pZCBhdHRyaWJ1dGUgaXMgb3B0aW9uYWwgKHJpZ2h0 PyksIGl0IGNvdWxkIGJlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+b21pdHRlZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmlm IHdlIG5lZWQgdG8gZGVhbCB3aXRoIG9ubHkgc21hbGwgbnVtYmVyIG9mIGluZGljYXRvcnMuPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UmVnYXJkaW5nIHRoZSB1c2UgY2Fz ZSwgSSBsaWtlIHRoZSBpZGVhIG9mIHVzaW5nIHRoZSBjb25maWRlbmNlPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YXR0cmlidXRlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Zm9yIHRoZSByZWFzb24gQ2hyaXMga2luZGx5IGRl c2NyaWJlZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHdv dWxkIGxpa2UgdG8gaGVhciBhIGJpdCBtb3JlIG9uIHRoaXM6IGlzIGl0IGdvaW5nIHRvIGJlIG51 bWVyaWNhbD88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gb3I8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbnN0YW5jZSwgMSBt ZWFucyAmcXVvdDtubyBjb25maWRlbmNlJnF1b3Q7IHdoaWxlIDUgbWVhbnMgJnF1b3Q7c3Ryb25n IGNvbmZpZGVuY2UmcXVvdDssPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+ZXRjPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rIHlv dS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UYWtlPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5 aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiBIYXJyaW5ndG9uLCBDaHJpc3RvcGhl ciBbPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89 Q2hyaXN0b3BoZXIuSGFycmluZ3RvbkBlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkNo cmlzdG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbTwvYT5dPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwOCwgMjAxMyA0OjEx IEFNPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VG86IE1vcmlh cnR5LCBLYXRobGVlbjsgVGFrZXNoaSBUYWthaGFzaGk7IFN0b2Vja2VyLCBQYXVsOyAnTUlMRTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklFVEYnPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUkU6IFttaWxlXSBJ T0NzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2l0aCByZXNwZWN0IHRv IHR5aW5nIHRoaW5ncyBiYWNrIHRvIHRocmVhdCBhY3RvcnMsIGZyb20gd2hhdCBJIGhhdmU8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zZWVuIGFuZCB1c2UgdGhp cyBpcyBhIGdlbmVyYWxseSBhY2NlcHRlZCBncm91cGluZzo8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5JbmRpY2F0b3IgLS0mZ3Q7IEluZGljdG9yIFNldCAtLSZndDsgQ2Ft cGFpZ24gLS0mZ3Q7IFRocmVhdCBBY3RvcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPkNhbXBhaWduIGFuZCBUaHJlYXQgQWN0b3IgYXJlIHdoZXJlIGhhdmluZyBhICZxdW90 O0NvbmZpZGVuY2UmcXVvdDsgYXR0cmlidXRlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+d291bGQgYmUgYmVuZWZpY2lhbCBhcyBtYWtpbmcgdGhvc2UgYXNzb2Np YXRpb25zIGlzIG5vdCBhIHBlcmZlY3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5zY2llbmNlIGJ5IGFueSBtZWFucy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5UaGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+LS1DaHJpczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ RnJvbTogTW9yaWFydHksIEthdGhsZWVuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEzIDI6MDAgUE08bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UbzogVGFrZXNoaSBUYWth aGFzaGk7IEhhcnJpbmd0b24sIENocmlzdG9waGVyOyBTdG9lY2tlciwgUGF1bDsgJ01JTEU8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JRVRGJzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlN1YmplY3Q6IFJFOiBbbWlsZV0gSU9D czxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIFRha2UgJmFtcDsgb3Ro ZXJzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcyBmb3IgY2hp bWluZyBpbiwgSSd2ZSBiZWVuIHRhbGtpbmcgYWJvdXQgdGhpcyB3aXRoIENocmlzIGFuZCBhPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZmV3IG90aGVycyBvbiB0 aGVpciB1c2UgY2FzZXMgYW5kIHdvdWxkIGxpa2UgbW9yZSBvcGluaW9ucy4mbmJzcDsmbmJzcDtJ J2xsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cHJvdmlkZSBh biBvcHRpb24gYmVsb3cgZnJvbSB3aGF0IHdlIGhhdmUgZGlzY3Vzc2VkIGZyb20gYSBDSVJDIHZp ZXc8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5wb2ludC4mbmJz cDsmbmJzcDtXZSBhcmUgYWxzbyB3b25kZXJpbmcgaG93IHRvIGFsc28gcHJvdmlkZSBsb2dpYyBp biBJT0RFRiB0aGF0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Y291bGQgY3Jvc3Mgb3ZlciBpbnRvIFNDSSBhdHRhY2hlZCBzY2hlbWFzIG9yIElPREVGIGV4dGVu c2lvbnMgKHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNv bHV0aW9ucyBtYXkgYWxsIHRpZSB0b2dldGhlciB3aXRoIHRoaXMgZGlzY3Vzc2lvbiAtIG9yIHRo ZXJlIG1heSBiZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmJl dHRlci9tb3JlIGVsZWdhbnQgc29sdXRpb25zIG90aGVycyB3b3VsZCBsaWtlIHRvIHByb3Bvc2Up LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RnJv bTogVGFrZXNoaSBUYWthaGFzaGkgWzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9v LmNvbS9tYy9jb21wb3NlP3RvPXRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanAiIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86dGFrZXNoaV90YWthaGFzaGlAbmljdC5nby5qcDwvYT5dPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U2VudDogVHVlc2RheSwgRmVicnVh cnkgMDUsIDIwMTMgMTI6MDQgUE08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5UbzogSGFycmluZ3RvbiwgQ2hyaXN0b3BoZXI7IFN0b2Vja2VyLCBQYXVsOyBNb3Jp YXJ0eSwgS2F0aGxlZW47PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+J01JTEU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JRVRG JzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlN1YmplY3Q6IFJF OiBbbWlsZV0gSU9DczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgbGlrZSB0aGlzIGRpc2N1 c3Npb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhZ3Jl ZSwgaXQgd291bGQgYmUgZ29vZCBpZGVhIHRvIGhhdmUgaW5kaWNhdG9yIGlkZW50aWZpZXJzIGlu c2lkZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZSBJT0Mt cmVsYXRlZCBjbGFzc2VzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5LTU06IEF0IHRoZSBjbGFzcyBsZXZlbCwgd2UgbWF5IGhhdmUgc2V2ZXJhbCBp bmRpY2F0b3JzIGxpc3RlZCB0aGF0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+c2hvdWxkIGJlIHZpZXdlZCBhcyBhIHNldCBhbmQgbWF5IGhhdmUgYW5vdGhlciBp bnN0YW5jZSBvZiB0aGF0IHNhbWU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5jbGFzcyB0aGF0IGlzIGEgcmVsYXRlZCBpc3N1ZSwgYnV0IGEgc2VwYXJhdGUgc2V0 LiZuYnNwOyZuYnNwO1dlIGNvdWxkIGFzIHlvdTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPnNheSwgbGlzdCB0aGUgaW5kaWNhdG9yIElEcyBjb25uZWN0ZWQgdGhy b3VnaCB0aGUgcmVmZXJlbmNlIGNsYXNzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlRoZSBzZXQgSURzIG1pZ2h0IGdpdmUgdXMgb3RoZXIgd2F5cyB0byBncm91 cCB0aGUgdmFsdWVzIHdoZW4gd2UgZ2V0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+aW50byBsb2dpYyBhbmQgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHNldHMgb3Ig aW5kaWNhdG9ycy4mbmJzcDsmbmJzcDtUaGlzIGNvdWxkPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+YWxzbyBiZSBhIHdheSB0byBjb25uZWN0IGluZGljYXRvcnMg b3Igc2V0cyBhY3Jvc3MgWE1MIGRvY3VtZW50cyB0aGF0PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Y291bGQgaGF2ZSBiZWVuIHNoYXJlZCBwcmV2aW91c2x5LiZu YnNwOyZuYnNwO0lmIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZGljYXRvcnMgaW4gdGhlIHNldCwgdGhlbiB0 aGlzIGJlY29tZXMgdXNlZnVsLCBmb3Igc21hbGxlciBzZXRzLCBJPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YWdyZWUgaXQgZG9lc24ndCBtYWtlIGFzIG11Y2gg c2Vuc2UuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2hhdCBkbyBvdGhl cnMgdGhpbms/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlbiBmb3IgaW5kaWNhdG9ycyBub3QgaW5jbHVkZWQg aW4gdGhlIGJhc2Ugc2NoZW1hIHRoYXQgbWF5IG5vdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmZpdCBpbnRvIGEgY2F0ZWdvcnkgaW4gdGhlIFNDSSBkcmFmdCwg ZG8gd2UgY3JlYXRlIGEgcGxhY2UgZm9yPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+dGhlc2Ugb2ZmIG9mIFNDSSBvciByaWdodCBvZmYgb2YgdGhlIElPREUgc2No ZW1hIGluIEV2ZW50RGF0YT88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4obW9yZSBkZXRhaWxzPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vbjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxi bG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEy ODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxibG9ja3F1b3RlIHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRo aXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPklmIHdlIGNvdWxkIHNlZSBhbnkgaW5kaWNhdG9yIG9mIGNvbXBy b21pc2UgYXMgY29tcHV0ZXIgZXZlbnQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5yZWNvcmQsIHdlIGNvdWxkIHVzZSBTQ0k6RXZlbnRSZXBvcnQgY2xhc3MgYXMg dGhlIHBsYWNlIGZvciB0aGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5YTUwtYmFzZWQgSU9DcyB0aGF0IGNvdWxkbid0IGZpdCBhbnl3aGVyZSBlbHNlLjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5LTU06IFRoYXQg c291bmRzIGxpa2UgYSBnb29kIGlkZWEgdG8gbWUuJm5ic3A7Jm5ic3A7VGhpcyBzaG91bGQgZ28g aW50bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmd1aWRhbmNl PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW4gdGhlIFNDSSBk cmFmdC4mbmJzcDsmbmJzcDtEb2VzIGFueW9uZSBlbHNlIHdhbnQgdG8gd2VpZ2ggaW4/PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQn IGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Rm9yIHRoZSBub24tWE1MIElPQ3MsIHdlIGNvdWxkIHVzZSBSZWNvcmRE YXRhIGNsYXNzLCBhcyBzdWdnZXN0ZWQuPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPktNTTogU291bmRzIGdvb2QsIHRoYW5rcyE8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcg aWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5JIGFncmVlIHRvIGhhdmUgaW5kaWNhdG9yX3VpZCwgYnV0IEkg YW0gbm90IHN1cmUgYWJvdXQgdGhlIG5lZWRzIG9mPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+dGhlIGluZGljYXRvcl9zZXRfaWQuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSB1bmRlcnN0YW5kIHdlIGNvdWxkIGRvIHNvbWUg Z3JvdXBpbmcgb2YgaW5kaXZpZHVhbCBpbmRpY2F0b3JfdWlkczxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFuZCBpdHMgdXNhYmlsaXR5LCBidXQgSSBhbSBub3Qg c3VyZSB3aGV0aGVyIHdlIGRvIG5vdCBoYXZlIGFueTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPm90aGVyIHdheSB0byBleHByZXNzIHRoZXNlIGdyb3VwaW5ncy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gb3IgaW5zdGFuY2Us Jm5ic3A7Jm5ic3A7YSBSZWZlcmVuY2UgY2xhc3MgcmVmZXJzIHRvIHNldmVyYWwgaW5kaWNhZHRv cl91aWRzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5JbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoaXMgY2FzZSwgdGhl eSBjb3VsZCBiZSwgaW4gYSBzZW5zZSwgZ3JvdXBlZC4gSXNuJ3QgaXQgZW5vdWdoPzxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5LTU06IEl0IG1heSBi ZSwgd2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgbGFyZ2Ugc2V0cyBvZiBpbmRpY2F0b3JzIG9yPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c3Vic2VxdWVudCBtZXNz YWdlcyB0aGF0IGFkZCBpbmRpY2F0b3JzIHRvIGV4aXN0aW5nIHNldHM/Jm5ic3A7Jm5ic3A7V291 bGQgdGhpczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmhhcHBl bj8mbmJzcDsmbmJzcDtXb3VsZCBpdCBiZSBlYXNpZXIgdG8gZXhwcmVzcyByZWxhdGlvbnNoaXBz IHdpdGggc2V0cyBvZjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PmluZGljYXRvcnMgaW4gYWRkaXRpb24gdG8gaW5kaXZpZHVhbCBpbmRpY2F0b3JzPyZuYnNwOyZu YnNwO0J5IHVzaW5nIHRoaXMsIGl0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+Y291bGQgZ2l2ZSB1cyBhIHVuaXF1ZSB3YXkgdG8gYWxzbyBwcm92aWRlIHRoZSBs b2dpYyBhbmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZWxh dGlvbnNoaXBzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW4g YSBuZXcgY2xhc3Mgb2YgSU9ERUYgc28gd2UgZG9uJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBhZGRp bmcgaXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbnRvPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlIGN1cnJlbnQ8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c3Ry dWN0dXJlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHRoZXJlIGFyZSBiZXR0 ZXIgd2F5cyB0byBoYW5kbGUgdGhhdCwgYW5kIG90aGVycyBjYW4gcHJvdmlkZSBzb21lPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+b3B0aW9ucywgdGhhdCB3b3Vs ZCBiZSBhcHByZWNpYXRlZCE8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5U aGFuayB5b3UsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+S2F0 aGxlZW48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHdvdWxkIGFwcHJlY2lhdGUgaWYgYW55 Ym9keSBjb3VsZCBzaGFyZSBleHBlcnRpc2Ugb24gdGhpcy4gVGhvdWdoPG86cD48L286cD48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkk8bzpwPjwvbzpwPjwv cD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcg aWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD50aGluayBJIGhhdmUgcmVhZCBhbGwgdGhlIGVtYWlscyBpbiB0 aGUgbGlzdCwgSSBtaWdodCBoYXZlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+bWlzLXVuZGVyc3Rvb2Qgc29tZSBwb2ludHMuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+QnkgdGhlIHdheSwgSSB0aGluayB0aGUgaW5kaWNhdG9yX3VpZHMg c2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBTQ0k8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNsYXNzZXMnPG86cD48L286 cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg NC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYy MTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+YXR0cmlidXRlcyBzbyB0aGF0IHRoZXkgY2FuIGJlIGNvcnJlbGF0ZWQgd2l0 aCBhbm90aGVyIGluZm9ybWF0aW9uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+YXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+d2VsbC48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3M8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UYWtlPG86cD48L286cD48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZyb206IDxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5t YWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Imh0dHA6Ly91cy5t YzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhh bGY8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PZiBIYXJyaW5n dG9uLCBDaHJpc3RvcGhlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDEzIDQ6MjUgQU08bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UbzogU3RvZWNrZXIsIFBhdWw7IE1vcmlh cnR5LCBLYXRobGVlbjsgTUlMRSBJRVRGPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+U3ViamVjdDogUmU6IFttaWxlXSBJT0NzPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+SSB0aGluayBzb21lIHNvcnQgb2YgZ3JvdXAgSUQgd291bGQgZG8g dGhlIHRyaWNrLiBXZSBhbHNvIG5lZWQgYTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPmxvZ2ljYWwgYW5kIC8gb3Igc29tZXdoZXJlIHRvIHNob3cgcmVsYXRpb25z aGlwIGJldHdlZW4gaW5kaWNhdG9ycy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5JZjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkkgZ2l2ZSB5b3U8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4y PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cmVnaXN0cnkga2V5 cyBkbyB0aGV5IGJvdGggaGF2ZSB0byBiZSBwcmVzZW50IHRvIGJlIGFuIGluZGljYXRpb24gb2Y8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb21wcm9taXNlIG9y IGlzIGVpdGhlciBvbmUgYnkgdGhlbXNlbHZlcyBhbiBpbmRpY2F0b3I/IEJvdGggd291bGQ8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5oYXZlIHRoZSBzYW1lIGdy b3VwIElEIHNpbmNlIHRoZXkgYXJlIHJlbGF0ZWQuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPi0tQ2hyaXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9t OiBTdG9lY2tlciwgUGF1bDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPlNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMDMsIDIwMTMgODoyNiBQTTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBNb3JpYXJ0eSwgS2F0aGxlZW47IEhh cnJpbmd0b24sIENocmlzdG9waGVyOyBNSUxFIElFVEY8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XaGF0IGlmIHdlIGFkZGVkIGluZGljYXRvciBncm91 cCBJRCBhbG9uZyB3aXRoIHRoZSBpbmRpY2F0b3JfdWlkPzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgd291bGQgYWxsb3cgeW91IHRvIGdyb3VwIGluZGlj YXRvcnMgdGhhdCBhcmUgcmVsYXRlZCBpbnRvIHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnNhbWUgZ3JvdXAgSUQuPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+V291bGQgdGhpcyByZXNvbHZlIHRoZSBpc3N1ZT88bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JdCBpcyBlaXRoZXIgdGhhdCBvciBnb2lu ZyBiYWNrIHRvIGFkZGluZyBhIERldGVjdGlvbiAob3IgSW5kaWNhdG9ycyk8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jbGFzcyB0aGF0IHdpbGwgc2hvdWxkIGJl IHVzZWQgdG8gdGFrZSBhbGwgb2YgdGhlIGluZGljYXRvcnMgcHV0IHRoZW08bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbnRvIG9uZSBwbGFjZSBhbmQgaGF2ZSB0 aGUgYWJpbGl0eSB0byBncm91cCB0aGUgb25lcyB0aGF0IGdvPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dG9nZXRoZXIuJm5ic3A7Jm5ic3A7SSBkb24ndCBtZWFu IGEgcGxhY2UgdG8gcHV0IGluZGljYXRvcnMgdGhhdCBhcmUgbWlzc2luZzxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmZyb20gSU9ERUYuSSBtZWFuIGEgcGxhY2Ug aW4gdGhlIElPREVGIGRvY3VtZW50IHdoZXJlIHlvdSBwdXQgdGhlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5kaWNhdG9ycyB0aGF0IGFyZSB1c2VkIGZvciBk ZXRlY3Rpb24gYW5kIHByZXZlbnRpb24gb2YgdGhlIHNoYXJlZDxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkluY2lkZW50LiZuYnNwOyZuYnNwO0kgZG9uJ3Qga25v dyB0aGUgYW5zd2VyIGhlcmUsIGJ1dCB0aGVyZSBoYXMgZ290IHRvIGJlIGE8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5nb29kIHdheSBmb3IgaW5kaWNhdG9ycyB0 byBiZSBpZGVudGlmaWVkIGFuZCBiZWluZyBhYmxlIHRvIGdyb3VwIHRoZW08bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hcyBDaHJpcyBoYXMgc3VnZ2VzdGVkIHdp dGhvdXQgYmFzaWNhbGx5IHJlY3JlYXRpbmcgc29tZXRoaW5nPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29tcGxpY2F0ZWQgbGlrZSBTVElYLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBhdWw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5QYXVsIFcuIFN0b2Vja2VyLCBQaC5ELjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPlNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UlNBLCBUaGUgU2VjdXJpdHkgRGl2aXNp b24gb2YgRU1DPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y2Vs bDogMzAyLjM3OS4zMzc1IHwgZTogPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28u Y29tL21jL2NvbXBvc2U/dG89cGF1bC5zdG9lY2tlckByc2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cGF1bC5zdG9lY2tlckByc2EuY29tPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkZyb206ICZsdDtNb3JpYXJ0eSZndDssIEthdGhsZWVuICZsdDs8YSBocmVmPSJodHRwOi8vdXMu bWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1rYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTwvYT4mZ3Q7PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RGF0ZTogU3VuZGF5LCBG ZWJydWFyeSAzLCAyMDEzIDU6MTEgUE08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5UbzogJnF1b3Q7SGFycmluZ3RvbiwgQ2hyaXN0b3BoZXImcXVvdDsgJmx0Ozxh IGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPUNocmlz dG9waGVyLkhhcnJpbmd0b25AZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdG9waGVyLkhh cnJpbmd0b25AZW1jLmNvbTwvYT4mZ3Q7LCBNSUxFPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+SUVURiAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1p bGVAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPlN1YmplY3Q6IFJlOiBbbWlsZV0gSU9DczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkhpIENocmlzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPkkgYWdyZWUsIHdlIGhhdmUgc29tZSB3b3JrIHRvIGRvIGluIHRoZSB1cGRhdGVkIElPREVG LCBSRkM1MDcwLWJpcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUg bGlzdCBoYXMgYWxyZWFkeSBzYWlkIHRoZXkgd291bGQgbGlrZSB0byBzZWUgaW5kaWNhdG9ycyBh ZGRlZCB0bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZSBk ZWZpbml0aW9ucyBpbiBSRkM1MDcwLWJpcywgdG8gYmUgbW9yZSBleHBsaWNpdCBhYm91dCBpbmNs dWRpbmc8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmRpY2F0 b3JzIGFuZCBzZXRzIG9mIGluZGljYXRvcnMgaW4gSU9ERSBkb2N1bWVudHMgYXMgb3Bwb3NlZCB0 bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPidwYXJ0cyBvZiBh biBpbmNpZGVudCBvciB0aGUgdXNlZnVsIGluZm9ybWF0aW9uIG9uIGFuIGluY2lkZW50IGZvcjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNoYXJpbmcgcHVycG9z ZXMuJm5ic3A7Jm5ic3A7SXQgd2FzIHdyaXR0ZW4gYmVmb3JlIHdlIHVzZWQgdGVybXMgbGlrZTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZGljYXRvcnMuJm5i c3A7Jm5ic3A7V2l0aCB0aGF0IGluIG1pbmQsIFJvc2VsbGEgcHJvcG9zZWQgYSBudW1iZXIgb2Yg Y2hhbmdlczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmJhY2sg aW4gSnVseSwgYm90aCBmb3IgZ3VpZGFuY2UgYW5kIGZvcjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5mb3JtYXQ8bzpwPjwvbzpwPjwvcD48 L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9 InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD51cGRhdGVzLiZuYnNwOyZuYnNwO0l0IG1heSBoZWxwIHRvIGhhdmUg dGhlIGZpcnN0IGRyYWZ0IHRyeSB0byBhZGRyZXNzIGF0IGxlYXN0PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c29tZSBvZiB0aGVzZSBpc3N1ZXMgc28gcGVvcGxl IGNhbiB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtcyBhbmQgYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5sZWFzdCBhIHByb3Bvc2VkIHNvbHV0aW9uLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFzIHlvdSBwb2ludCBvdXQsIHdlIG5lZWQg dG8gYmUgYWJsZSB0byBzaG93IHJlbGF0aW9uc2hpcHMgYmV0d2VlbjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNldHMgb2YgaW5kaWNhdG9ycywgd2hlcmUgd2Ug bWF5IGhhdmUgYSBmZXcgc2V0cyBvZiBpbmRpY2F0b3JzIHRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb3VsZCBoYXZlIGEgcmVsYXRpb25zaGlwIHRvIGVh Y2ggb3RoZXIgd2l0aGluIGEgZG9jdW1lbnQuJm5ic3A7Jm5ic3A7SW4gdGhlPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SnVseSBwcmVzZW50YXRpb24sIG9uZSBv ZiB0aGUgcXVlc3Rpb25zIHdhcyB0byBzZWUgaWYgd2Ugc2hvdWxkIGFkZDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm5ldyBjYXRlZ29yeSBhdHRyaWJ1dGUgdmFs dWVzIGZvciB0aGUgU3lzdGVtIGNsYXNzIHRoYXQgd291bGQgY29ubmVjdDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZSBsaXN0IG9mIGluY2x1ZGVkIGluZGlj YXRvcnMuJm5ic3A7Jm5ic3A7SSB0aGluayB3ZSBzaG91bGQgc3RpbGwga2VlcCB0aGU8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb25jZXB0IG9mIGEgTm9kZSB0 byBhIHNpbmdsZSBub2RlLCBidXQgcGVyaGFwcyB3aXRoaW4gU3lzdGVtLCBsaXN0PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bXVsdGlwbGUgc2V0cyBvZiBOb2Rl cyB0aGF0IG1heSBiZSBvbmUgdHlwZSBvZiBhdHRhY2suJm5ic3A7Jm5ic3A7Um9zZWxsYSBoYWQ8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zdWdnZXN0ZWQgcHVs bGluZyBmb3J3YXJkIHRoZSAmcXVvdDtGcmF1ZFR5cGUmcXVvdDsgZnJvbSBSRkM1OTAxLCB0aGlz IHdvdWxkPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aGVscCBz b2x2ZSB0aGUgaXNzdWUgYXMgTm9kZVJvbGUgdmFsdWVzIHdvdWxkIGNvbXBsaW1lbnQgYW48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BdHRhY2tUeXBlPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+KEZyYXVkVHlwZSB2YWx1ZXMg Y291bGQgYmUgaW5jbHVkZWQgaW4gQXR0YWNrVHlwZSBvciBzb21lIGJyb2FkZXI8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50ZXJtKS4mbmJzcDsmbmJzcDtJdCBt YXkgYmUgYmV0dGVyIHRvIGhhdmUgdGhlIEZyYXVkVHlwZXMsIHBsdXMgYXR0cmlidXRlPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dmFsdWVzPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bGlrZSAmcXVvdDtDMi1zZXJ2ZXImcXVv dDssICZxdW90O3Npbmtob2xlJnF1b3Q7LCZuYnNwOyZuYnNwOyZxdW90O01hbHdhcmVEaXN0cmli dXRpb24mcXVvdDsgZm9yIGFkZGVkPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+Y29udGV4dDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPnNvIHlvdSBrbm93IHdoYXQgdG8gZG8gd2l0aCB0aGUgcmVjZWl2ZWQgc2V0IG9mIGluZGlj YXRvcnMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhbSBwcm9wb3Np bmcgdGhhdCB3ZSBjaGFuZ2UgSU9ERUYgdG8gaW5jbHVkZSBtdWx0aXBsZSBzZXRzIG9mPG86cD48 L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZGlj YXRvcnMsPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YWRkIGFuIEF0dGFja1R5cGUg YXR0cmlidXRlIChvciBzb21lIG90aGVyIG5hbWUpLCBhIG1ldGhvZCB0byBjb25uZWN0PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5kaWNhdG9ycyBhbmQgaW5k aWNhdG9yIHNldHMgd2l0aGluIGFuIElPREVGIHVzaW5nIGFuIGF0dHJpYnV0ZSBvZjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZGljYXRvcl91aWQgKG9yIHNv bWUgb3RoZXIgbmFtZSkgd2l0aCBhIHN0cmluZyB2YWx1ZSB0byBtYWtlIHRoZTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNvbm5lY3Rpb24gcG9pbnRzLCBhbmQg YWRkIGEgZmV3IGluZGljYXRvcnMgdGhhdCBhcmUgY29tbW9ubHkgc2hhcmVkPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW50byB0aGUgYmFzZSBJT0RFRi48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5CYWNrIGluIEp1bHksIHdlIHRhbGtl ZCBhYm91dCBhZGRpbmcgUmVnaXN0cnkgS2V5L1ZhbHVlIHBhaXJzIGFuZDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmhhc2hlcyB0byB0aGUgbWFpbiBJT0RFRiBk b2N1bWVudCAodHJ5aW5nIHRvIHNlZSBpZiB0aGlzIHdpbGwgaGVscDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNocmlzIGJlbG93KS4mbmJzcDsmbmJzcDtXaGF0 IGlmIHdlIGFkZGVkIHRoZSBSZWdpc3RyeSBLZXkvVmFsdWUgcGFpcnMgYXMgYTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNsYXNzIG9mZiBvZiBSZWNvcmREYXRh LCB1c2luZyBhIHNpbWlsYXIgc3RydWN0dXJlIHRvIHdoYXQgaXMgaW48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SRkM1OTAxLCBhbmQgYWxzbyBhZGRlZCB0aGUg YWJpbGl0eSB0byBpbmNsdWRlIGhhc2hlcyBpbiBSZWNvcmREYXRhPzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgdGhpbmsgaWYgd2UgdGhlbiBoYWQgdGhlIGlu ZGljYXRvcl91aWQgYXQgdGhlIFJlY29yZERhdGEgbGV2ZWwsIHdlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y291bGQgY29ubmVjdCBhIHNldCB3aXRoaW4gdGhh dCBzdHJ1Y3R1cmUgYW5kIHJlcGVhdCB0aGUgc3RydWN0dXJlPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Zm9yPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+b3RoZXIgc2V0cyBpbiB0aGUgc2FtZSB3YXkgd2Ugd291bGQgZG8gd2l0 aCBOb2RlIGluc2lkZSBvZiB0aGUgU3lzdGVtPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Y2xhc3MsIHVzaW5nIHRoZSBpbmRpY2F0b3JfdWlkIHRvIHRpZSB0aGUg c2V0IHRvZ2V0aGVyLiZuYnNwOyZuYnNwO1RoZW4gYXQgdGhlPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bW9yZSBzcGVjaWZpYyBsZXZlbCBmb3IgdGhlIGhhc2gs IHJlZ2lzdHJ5IEtleS92YWx1ZSwgSVAsIGV0Yy4gdXNlIGFuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5kaWNhdG9yX3VpZCBpZiB3ZSBuZWVkZWQgdGhlbSBt YXJrZWQgYXQgdGhpcyBsZXZlbCBhcyB3ZWxsPyZuYnNwOyZuYnNwO01heWJlPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2Ugd2FudCBpbmRpY2F0b3Jfc2V0IGF0 IHRoZSBoaWdoZXIgbGV2ZWw/Jm5ic3A7Jm5ic3A7SSdkIGxpa2Ugc29tZSBvcGluaW9ucyBvbjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoaXMgYXBwcm9hY2gu Jm5ic3A7Jm5ic3A7KzEgaWYgeW91IGFncmVlLCBzdWdnZXN0aW9ucyBpZiB5b3UgaGF2ZSBvdGhl ciBpZGVhczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYXQg bWF5IHdvcmsgYmV0dGVyLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldl J2xsIGFsc28gbmVlZCB0byB3b3JyeSBhYm91dCBtYXJraW5nIHRoZSBpbmRpY2F0b3JzIHRvIHBy ZXZlbnQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5mb3J3YXJk IHNoYXJpbmcgd2hlbiBub3QgcGVybWl0dGVkLiZuYnNwOyZuYnNwO1dlIG1heSB3YW50IHRvIHVz ZSB0aGVzZSB2YWx1ZXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5vciBzb21ldGhpbmcgZWxzZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5UaGFuayB5b3UhPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ S2F0aGxlZW48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiBIYXJy aW5ndG9uLCBDaHJpc3RvcGhlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMTMgMTI6MDEgUE08bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UbzogTW9yaWFydHksIEthdGhsZWVu OyBNSUxFIElFVEY8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5T dWJqZWN0OiBSRTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5JIHRoaW5rIHdlIGhhdmUgYSBiaWdnZXIgcmVsYXRpb25zaGlwIGlzc3VlIHRvIGFkZHJl c3MuIExldCB1c2UgdGhlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+V2F0Y2hsaXN0IFVzZSBDYXNlLiBBIGJ1bmNoIG9mIGluZGljYXRvcnMgYXJlIHNlbnQgaW4g b25lIG1lc3NhZ2UuIEluPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+dGhhdCBtZXNzYWdlIHdlIGNvdWxkIGhhdmUgZ3JvdXBpbmdzIG9mIGluZGljYXRvcnMgdGhh dCB3ZSBuZWVkIHRvPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ c2hvdyBhcmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZWxh dGVkOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlR3byBvciBtb3JlIGlu ZGljYXRvcnMgb2YgZGlmZmVyZW50IHR5cGUgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWU8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aHJlYXQ6PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoZSBmaWxlIGhhc2ggb2YgYSBtYWxpY2lvdXMgZmlsZSBhbmQgdGhlIFVS TCBvZiB0aGUgQzIgdGhhdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPnRoZSBmaWxlIHVzZXMuIEVpdGhlciBvciBib3RoIG1heSBiZSBwcmVzZW50IHRvIGluZGlj YXRlIGE8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb21wcm9t aXNlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlR3byBvciBtb3JlIGlu ZGljYXRvcnMgb2YgdGhlIHNhbWUgdHlwZSB0aGF0IHJlbGF0ZSB0byB0aGUgc2FtZTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRocmVhdDo8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMiBkaWZmZXJlbnQgcmVnaXN0cnkgdmFsdWVzIGZvciB0aGUgc2FtZSByZWdp c3RyeSBrZXkuIElmPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ ZWl0aGVyIHZhbHVlIGlzIHByZXNlbnQgaXQgaXMgYSBjb21wcm9taXNlIGluZGljYXRvciBidXQg Ym90aCB3aWxsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bm90 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YmU8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cHJlc2VudC48 bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgcHJvYmxlbSBjb21wb3VuZHMgaXRzZWxmIHZl cnkgcXVpY2tseS4gQ29uc2lkZXIgdGhlIHNjZW5hcmlvPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+d2hlcmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5ib3RoIGdyb3VwaW5ncyBhYm92ZSBhcmUgcGFydCBvZiB0aGUgc2FtZSB0 aHJlYXQuIEkgbmVlZCB0byBzaG93IHRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5sb2dpY2FsIGdyb3VwaW5ncyBvZiBJbmRpY2F0b3JzIGFyZSByZWxhdGVk IGFzIHdlbGwuIFdlIGNhbid0IHNlbmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5tdWx0aXBsZSBJT0RFRiBtZXNzYWdlcyBmb3IgdGhpcyBmcm9tIHdoYXQgSSBy ZW1lbWJlciByZWFkaW5nLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRo ZSBsYXN0IG9uZSBJIGNhbiB0aGluayBvZiB3b3VsZCBiZSB3aGVuIHlvdSBoYXZlIDIgZGlmZmVy ZW50PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5kaWNhdG9y cyB0aGF0IHJlcHJlc2VudCB0aGUgc2FtZSBpbmRpY2F0b3IuIEl0J3Mgbm90IHVuY29tbW9uIHRv PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c2VuZCBib3RoIHRo ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1ENTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFuZCBTSEExIGhhc2ggb2YgYSBt YWxpY2lvdXMgZmlsZS4gVGhlIGluZGljYXRvciBpcyB0aGUgZmlsZSBidXQgdGhlPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SU9DcyBhcmUgdGhlIDIgaGFzaCB2 YWx1ZXMuIEhvdyBkbyB3ZSBzaG93IHRoZXkgYXJlIHJlbGF0ZWQ/IElmIHdlPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dXNlPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YSB1bmlxdWUgSW5pZGNhdG9yIElEIGZvciBlYWNoIGhh c2ggdmFsdWUgdGhlcmUgbmVlZHMgdG8gYmUgYSBoaWdoZXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5sZXZlbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ncm91cGluZy48bzpwPjwvbzpwPjwvcD48L2Rp dj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Inlp djIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5U aGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS1DaHJpczxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNocmlzdG9waGVyIEhhcnJpbmd0b248 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Db25zdWx0aW5nIFNl Y3VyaXR5IEVuZ2luZWVyPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+R1NPIC0gQ3JpdGljYWwgSW5jaWRlbnQgUmVzcG9uc2UgQ2VudGVyIEVNQyAtIFdoZXJlIElu Zm9ybWF0aW9uIExpdmVzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+MTc0IE1pZGRsZXNleCBUdXJucGlrZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkJlZGZvcmQsIE1BIDAxNzMwPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+NzgxLTUxNS01ODYyICh3b3JrKTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjYwMy01ODMtMTU4NSAoY2VsbCk8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiA8YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJodHRwOi8vdXMu bWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T2YgTW9yaWFy dHksIEthdGhsZWVuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ U2VudDogRnJpZGF5LCBGZWJydWFyeSAwMSwgMjAxMyAxMToyOCBBTTxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBNSUxFIElFVEY8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BbGwgLTxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkknZCBsaWtlIHlvdXIgaW5wdXQgYW5kIHdpbGwgcmVmb2N1 cyB0aGUgdGhyZWFkIHRvIGdldCBvcGluaW9ucyBmcm9tPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlIGxpc3Qgb24gb3B0aW9ucyB0byBoZWxwIHNvbHZlIHRo ZSBwcm9ibGVtcyByYWlzZWQgaW4gbXkgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmFuZCBhZGRpdGlvbmFsbHkgaW4gUGF1bCdzIG1lc3NhZ2UuPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SW50ZXJlc3RpbmcgcG9pbnQsIEMu IEhlbnJ5LiZuYnNwOyZuYnNwO091ciBvYmplY3RpdmUgaGVyZSBpcyB0byBoYXZlIG1hY2hpbmU8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hdXRvbWF0ZWQgZXhj aGFuZ2VzLCBzbyB3ZSByZWx5IG9uIGVuY3J5cHRpb24gcmF0aGVyIHRoYW4gb2JmdXNjYXRpb248 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50byBhY2hpZXZlIHRo ZSBuZWNlc3NhcnkgbGV2ZWwgb2YgY29uZmlkZW50aWFsaXR5LjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPlBhdWwgbWVudGlvbmVkIHRoZSBuZWVkIHRvIGRpc3Rpbmd1aXNo IGluZGljYXRvcnMgb2YgY29tcHJvbWlzZSBmcm9tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Y29udGV4dCBpbmZvcm1hdGlvbiB0aGF0IG1heSBhbHNvIGluY2x1 ZGUgSVAgYWRkcmVzcyBvciBvdGhlciBkYXRhPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+dGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzLiZuYnNwOyZuYnNwO1RoZSBx dWVzdGlvbiBJIHJhaXNlZCB3YXMgb24gaG93IHRvPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Y29ubmVjdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPnNldHMgb2YgaW5kaWNhdG9ycyBpbiB0aGUgc2FtZSBJT0RFRiBkb2N1bWVu dCwgYXNzdW1pbmcgdGhlIGFiaWxpdHk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD50bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PmhhdmUgd2F0Y2hsaXN0cyB0aGF0IGNvdWxkIGhhdmUgc2V2ZXJhbCBzZXRzIG9mIGluZGljYXRv cnMgaW5jbHVkZWQsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ YXMgd2VsbCBhcyB0byBjb25uZWN0IGluZGljYXRvcnMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4g ZW1iZWRkZWQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zY2hl bWFzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHdlIGFkZCBhbiBh dHRyaWJ1dGUgb24gYWxsIG9mIHRoZSByZWxldmFudCBpbmRpY2F0b3JzLCBsZXQncyBzYXk8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4naW5kaWNhdG9yLXVpZCcg aG93IGRvIHdlIG1hcmsgdGhlIGluZGljYXRvcnM/Jm5ic3A7Jm5ic3A7RG8gd2UgdXNlIHRoaXMg dG88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5tYXJrPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2hvIHNlbnQgdGhlIGluZGlj YXRvciBhcyB3ZWxsIHNvIHRoYXQgd2UgY2FuIHByZXZlbnQgZm9yd2FyZCBzaGFyaW5nPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d2hlbiBpdCBpcyBub3QgcGVy bWl0dGVkIG9yIGhhbmRsZSB0aGF0IHNlcGFyYXRlbHk/PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+VGhlbiBmb3IgaW5kaWNhdG9ycyBub3QgaW5jbHVkZWQgaW4gdGhlIGJh c2Ugc2NoZW1hIHRoYXQgbWF5IG5vdCBmaXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5pbnRvIGEgY2F0ZWdvcnkgaW4gdGhlIFNDSSBkcmFmdCwgZG8gd2UgY3Jl YXRlIGEgcGxhY2UgZm9yIHRoZXNlIG9mZjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPm9mIFNDSSBvciByaWdodCBvZmYgb2YgdGhlIElPREUgc2NoZW1hIGluIEV2 ZW50RGF0YT8gKG1vcmUgZGV0YWlscyBvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPnRoaXMgaW4gbXkgZmlyc3QgbWVzc2FnZSkuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Q29tbWVudHMgYW5kIHF1ZXN0aW9ucyBlbmNvdXJhZ2VkIHRv IGZpZ3VyZSBvdXQgdGhlIHJpZ2h0IHRlY2huaWNhbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnNvbHV0aW9uIHRvIGhhdmUgdGhpcyBtYWNoaW5lIGF1dG9tYXRh YmxlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rIHlvdSw8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5LYXRobGVlbjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZyb206IDxhIGhyZWY9Imh0dHA6Ly91cy5t YzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Imh0dHA6 Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGUtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGY8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PZiBD LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhlbnJ5IEFkYW1z ICZhbXA7IEJJRTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNl bnQ6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxMyAxMToyNSBQTTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBNSUxFIElFVEY8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UZW1wb3JhbCBEZXBlbmRlbmN5IHNvdW5k cyBpbnRlcmVzdGluZy4mbmJzcDsmbmJzcDtJIHJlbWVtYmVyIHdoZW4gSSBmaXJzdCByYW48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hY3Jvc3MgdGhpcyBwYXJ0 aWN1bGFyIGNyYWZ0LCBhbiBleHBlcmllbmNlZCBjb2xsZWFndWUgYXNrZWQgbWUgYTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnBlY3VsaWFyIHF1ZXN0aW9uLiZu YnNwOyZuYnNwO0hlIHNhaWQsICZxdW90OyBIb3cgZG8geW91IHN0b3Agc29tZW9uZSBmcm9tIHRy YWNraW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlIElQ IEFkZHJlc3MgdG8geW91ciBjb21wdXRlcj8mcXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5JIHJlcGxpZWQsICZxdW90O0kgZG9uJ3Qga25vdywgaG93PyZxdW90Ozxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZW4gaGUgc2FpZCwgJnF1b3Q7 Q3V0IHRoZSBkb2ctZ29uZSB0aGluZyBvZmYmbmJzcDsmbmJzcDthbmQgdGhlIG1vZGVtIHRoYXQg aXQgaXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb25uZWN0 ZWQtIHdoaWNoIGlzIGNvbnN0YW50bHkgb24hJnF1b3Q7Jm5ic3A7Jm5ic3A7IExPTDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhlcmUncyBteSBwb2ludCAoSHlwb3RoZXRp Y2FsIFNpdHVhdGlvbikgOiZuYnNwOyZuYnNwO1RoZXJlIGlzIGEgMXN0IFJlc3BvbmRlcjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNlYXJjaGluZyBhIE5laWdo Ym9yaG9vZCBmb3IgU3Vydml2b3JzIHdoaWNoIHdlcmUgaGl0IGJ5IGEgRGlzYXN0ZXI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vcjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmxldCdzIGp1c3Qgc2F5ICZxdW90O0xpdmUmcXVv dDsgVGVycm9yaXN0IFNpdHVhdGlvbi4mbmJzcDsmbmJzcDtIZSAvb3IgU2hlIG5lZWRzIHRvPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29tbXVuaWNhdGlvbiBi YWNrIHRvIG90aGVyIE9mZmljaWFscyB0aGF0IGhlIC9vciBzb21laG93IGlzIGluPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RGFuZ2VyLiZuYnNwOyZuYnNwO1Ro ZSBkZXZpY2UgdXNlZCB0byBjb21tdW5pY2F0ZSBoYXMgYmVlbiBjYXB0dXJlZCBieSB0aGU8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ncmVhdDxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm1pbmRzIG9mIHRoZSBlbmVteS4mbmJz cDsmbmJzcDtJdCdzIG9ubHkgYSBtYXR0ZXIgb2YgdGltZSBiZWZvcmUgdGhleSB1dGlsaXplPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cmV2ZXJzZSBlbmdpbmVl cmluZyB0byBmaWd1cmUgb3V0IGhvdyBpdCBmdW5jdGlvbnMuJm5ic3A7Jm5ic3A7SG93ZXZlciwg dGhlaXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5wcmlkZSBj b21lcyBiZWZvcmUgYSBmYWxsIHdoZW4gc2Vla2luZyB0aGUgbG9jYXRpb24gb2Ygb3RoZXIgc2lt aWxhcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRldmljZXMg dG8gYXR0YWNrLiZuYnNwOyZuYnNwO1doeT8gUGVyaGFwcyB0aGUgbGVzcyB0aG91Z2h0IG9mIGNv bmNlcHRzIHRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5t YWtlcyB0aGUgZGV2aWNlIGZ1bmN0aW9uIHByb3Blcmx5LCBzYXZlcyB0aGUgZGF5IGJ5IGRpc2d1 aXNlIG9yPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y3V0dGlu ZyBpdCBvZmYgKGZpZ3VyYXRpdmVseSBzcGVha2luZykuPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+SnVzdCBhIHZpc2lvbmFyeSB0aG91Z2h0LjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkMuIEhlbnJ5IEFkYW1zPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFo b28uY29tL21jL2NvbXBvc2U/dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaGVucnlhZGFtc0BiaWVtZWRpYWdyb3VwLmNvbTwvYT48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJodHRwOi8vYmllbWVkaWFn cm91cC5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vYmllbWVkaWFncm91cC5jb208L2E+PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaXMgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm9yaWdpbmFsIHJlY2lwaWVudC4gVGhpcyBpbmZvcm1h dGlvbiBpcyBncmFudGVkIGZvciBsaW1pdGVkPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+ZGlzdHJpYnV0aW9uIHdpdGhpbiB0aGUgcmVjaXBpZW50J3MgcGxhY2Ug b2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+cHVycG9zZXMgb25seS4gRnVydGhlciBkaXNzZW1pbmF0aW9uLCB3aGV0aGVy IHByaXZhdGUgb3IgcHVibGljIGlzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+cHJvaGliaXRlZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD4tLS0gT24gTW9uLCAxLzI4LzEzLCBEYXZlIE1pc2VsbCAmbHQ7PGEgaHJlZj0iaHR0cDovL3Vz Lm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89ZGF2aWQubWlzZWxsQGJjcy5vcmci IHRhcmdldD0iX2JsYW5rIj5kYXZpZC5taXNlbGxAYmNzLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZyb206IERhdmUgTWlzZWxsICZsdDs8 YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1kYXZp ZC5taXNlbGxAYmNzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLm1pc2VsbEBiY3Mub3JnPC9h PiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0 OiBSZTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5UbzogJnF1b3Q7Qy4gSGVucnkgQWRhbXMgJmFtcDsgQklFJnF1b3Q7ICZsdDs8YSBocmVm PSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAw MEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGF0bGdhMjAwMEB5YWhvby5jb208L2E+Jmd0 OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkRhdGU6IE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxMywgOToyNSBQTSBVSUQgY291bGQgYmUgbWlycm9yZWQgd2l0aDxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkROUzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNFQyBhIHBlbWFuZW50IGFuZCB0ZW1w b3JhbCBrZXksIHdpdGggYSB0ZW1wb3JhbCBJZD88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5Zb3VycyBGYWl0aGZ1bGx5LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkRhdmUgTWlzZWxsIE1TYyBDSVNTUDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPlNpbGVudENpcmNsZSZuYnNwOyZuYnNwO2RzbTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjA3NzEwIDM4MDA0NDxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHA6Ly91cy5tYzUz NC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWRhdmlkLm1pc2VsbEBiY3Mub3JnIiB0YXJn ZXQ9Il9ibGFuayI+ZGF2aWQubWlzZWxsQGJjcy5vcmc8L2E+PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+T24gMjkgSmFuIDIwMTMsIGF0IDAwOjM5LCBDLiBIZW5yeSBBZGFtcyAmYW1w OyBCSUU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbHQ7PGEg aHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxn YTIwMDBAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9h PiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF Ij48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TZXJpYWxpemF0aW9uIG9mIGEgcGFydGljdWxhciBM aXN0cyBvZiBYTUwgQ2xhc3NlcyBpbiBhIHVuaXF1ZSB3YXk8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53YXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y2xvc2VseSByZWxhdGVkIHRvIHdoYXQgSSBhdHRl bXB0ZWQgdG8gZXhwcmVzcyB3aGVuIEkgc3RhdGVkLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90O2NvbnNpZGVyIHRvIGEgZGVncmVlIHdoYXQgYXBwZWFy cyB0byBiZSBpbGxvZ2ljYWwgaW4gYnJpbGxpYW50IG1pbmRzPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW4gc29tZSBpbnN0YW5jZXMuJnF1b3Q7PG86cD48L286 cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+SG93ZXZlciwgSSBzZWUgRHIuIFN0b2Vja2VyJ3MgcG9pbnQgYSBs aXR0bGUgY2xlYXJlci4mbmJzcDsmbmJzcDtIb3dldmVyLCBpdDxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPndvdWxkPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmJlIG5pY2UgaWYgdGhlIFVJRCB3YXMgaW4g c29tZSB3YXkgZGlzZ3Vpc2VkIGZyb20gdGhvc2Ugd2hvIHN0dWR5PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhpczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPlNlY3VyaXR5IEFydCBGb3JtIGluIGEgbmVnYXRpdmUgd2F5Ljxv OnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkMuIEhlbnJ5IEFkYW1zPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwu eWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFob28uY29tIiB0YXJnZXQ9Il9i bGFuayI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPiAoRGlyZWN0IEVtYWlsKSA8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGVucnlhZGFtc0Bi aWVtZWRpYWdyb3VwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNoZW5yeWFkYW1zQGJpZW1lZGlhZ3Jv dXAuY29tPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGU8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vcmlnaW5hbDxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZWNpcGllbnQu IFRoaXMgaW5mb3JtYXRpb24gaXMgZ3JhbnRlZCBmb3IgbGltaXRlZCBkaXN0cmlidXRpb248bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53aXRoaW48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGU8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZWNpcGllbnQncyBwbGFjZSBvZiBidXNpbmVzcyBm b3IgcGxhbm5pbmcgcHVycG9zZXMgb25seS4gRnVydGhlcjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRpc3NlbWluYXRpb24sIHdoZXRoZXIgcHJpdmF0ZSBvciBw dWJsaWMgaXMgcHJvaGliaXRlZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZTogW21pbGVd IElPQ3M8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdW5kYXksIEphbnVh cnkgMjcsIDIwMTMgODo1MiBQTTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPkZyb206PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ JnF1b3Q7U3RvZWNrZXIsIFBhdWwmcXVvdDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5t YWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPVBhdWwuU3RvZWNrZXJAcnNhLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPlBhdWwuU3RvZWNrZXJAcnNhLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VG86PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFo b28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhv by5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlsZUBp ZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SSB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgdGhpcyBmcm9tIGEgc2xpZ2h0bHkgZGlmZmVyZW50 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cGVyc3BlY3RpdmXF oGxldCdzIHNheSBJIGdldCBhbiBYTUwgZG9jdW1lbnQgdGhhdCB0ZWxscyBtZSBhYm91dCBhbjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluY2lkZW50LiZuYnNw OyZuYnNwO1RoaXMgZG9jdW1lbnQgaGFzIHNvdXJjZSBJUCBhbmQgZGVzdGluYXRpb24gSVAgdGhh dCBpczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmJlaW5nIHNo YXJlZC4mbmJzcDsmbmJzcDtIb3dldmVyLCB3aGF0IEkgZG9uJ3Qga25vdyBpcyB3aGljaCBJUCBh ZGRyZXNzIGlzIG15PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ aW5kaWNhdG9yIGFuZCB3aGljaCBpcyBqdXN0IGEgY29udGV4dHVhbCBwaWVjZSBvZiBpbmZvcm1h dGlvbi4mbmJzcDsmbmJzcDtUaGlzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+bWVhbnMgdGhhdCBteSBkZXRlY3Rpb24gcHJvZHVjdCBpc24ndCBnb2luZyB0byBr bm93IHdoaWNoIG9uZSB0byB1c2U8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5laXRoZXIsIGJlY2F1c2UgdGhlcmUgaXMgbm90aGluZyB0byB0ZWxsIG1lIHdoaWNo IElQIGlzIHRoZSBvbmUsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+ZXZlbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmlmIHRo ZSByb2xlcyBhcmUgc2V0IGl0IHN0aWxsIG1pZ2h0IG5vdCBiZSBlbm91Z2ggdG8gdGVsbCBteSBz eXN0ZW08bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+d2hpY2g8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5v bmUgSSBzaG91bGQgdXNlIGFzIHRoZSBpbmRpY2F0b3IuPG86cD48L286cD48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4 NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SWYgd2UgaGFkIHNvbWV0aGluZyBsaWtlIGluZGljYXRvcl9pZCBhcyBhbiBhdHRyaWJ1dGUs IGl0IHdvdWxkPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YWxs b3c8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD51cyB0byBlYXNp bHkgaWRlbnRpZnkgaW5kaWNhdG9ycyBmcm9tIGNvbnRleHR1YWwgZGF0YS4mbmJzcDsmbmJzcDtJ IGRvIGFkbWl0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dG88 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5iZWluZyBiaWFzZWQg YXMgSSBoYXZlIHNwZW50IG11Y2ggb2YgbXkgY2FyZWVyIHdvcmtpbmcgb24gdGhlPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bW9uaXRvcmluZyBhbmQgZGV0ZWN0 aW9uIHNpZGUgb2YgdGhlc2UgdGhpbmdzLCBzbyBJIGFtIGp1c3QgdGhpbmtpbmc8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vZiB3YXlzIHRvIG1ha2UgaXQgdmVy eSBjbGVhciB3aGF0IHRoZSBpbmRpY2F0b3JzIGFyZSBpbiB0aGUgWE1MPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZG9jdW1lbnQgYW5kIHRoZSBvdGhlciBkYXRh IHRoYXQgbWF5IGJlIGltcG9ydGFudCBhcyBJIGludmVzdGlnYXRlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YWN0aXZpdHkgdGhhdCBJIGhhdmUgZGV0ZWN0ZWQg b2ZmIG9mIHRob3NlIGluZGljYXRvcnMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ SSBkaWQgc3VnZ2VzdCB0aGUgZGV0ZWN0aW9uIGNsYXNzLCBidXQgSSB0aGluayB3ZSBtYXkgZ2V0 IG1vcmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5mbGV4aWJp bGl0eSB3aXRoIHRoZSBpbmRpY2F0b3JfdWlkLiZuYnNwOyZuYnNwO09uZSB0aGluZyB0aGF0IEkg aGF2ZW4ndDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNvbnNp ZGVyZWQgaXMgdGhlIFVJRCBwb3J0aW9uIG9mIHRoaXPFoGhvdyBkbyB3ZSB1c2UgdGhhdCBVSUQ/ Jm5ic3A7Jm5ic3A7SG93PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+aXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGUgVUlE IGNyZWF0ZWQ/Jm5ic3A7Jm5ic3A7QXJlIHRoZXJlIHN0YW5kYXJkcyBmb3IgVUlEcz88bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBhdWw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QYXVs IFcuIFN0b2Vja2VyLCBQaC5ELjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPlNNQyBMZWFkIENvbnRlbnQgQXJjaGl0ZWN0PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+UlNBLCBUaGUgU2VjdXJpdHkgRGl2aXNpb24gb2YgRU1DPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y2VsbDogMzAyLjM3OS4z Mzc1IHwgZTogPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBv c2U/dG89cGF1bC5zdG9lY2tlckByc2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGF1bC5zdG9lY2tl ckByc2EuY29tPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLSBP biBTYXQsIDEvMjYvMTMsIEMuIEhlbnJ5IEFkYW1zICZhbXA7IEJJRSAmbHQ7PGEgaHJlZj0iaHR0 cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89Y2hhdGxnYTIwMDBAeWFo b28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hhdGxnYTIwMDBAeWFob28uY29tPC9hPiZndDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53cm90ZTo8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiBDLiBIZW5yeSBBZGFtcyAmYW1wOyBC SUUgJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3Nl P3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNoYXRsZ2EyMDAwQHlh aG9vLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+U3ViamVjdDogUkU6IFttaWxlXSBJT0NzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+VG86ICZxdW90O0thdGhsZWVuTW9yaWFydHkmcXVvdDsgJmx0OzxhIGhy ZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVu Lm1vcmlhcnR5QGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5D YzogPGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89 bWlsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RGF0ZTogU2F0dXJkYXksIEphbnVh cnkgMjYsIDIwMTMsIDY6MTcgUE08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5HcmVldGluZ3MgS2F0aGxlZW4sPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+WW91ciBsb2dpYyBzdGltdWxhdGVzIG15IHZpc2lvbmFyeSBicmFpbiBiZWNhdXNlIEknbSBh bWF6ZWQgYXQgdGhlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ bWFueTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5hdmVudWVzIHlvdSByZXZpZXcgd2l0aCB0aGlzIGFwcHJvYWNoIGF0IG9uY2UuJm5ic3A7 Jm5ic3A7SG93ZXZlciwmbmJzcDsmbmJzcDtjb3VsZCB5b3U8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zaGFyZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPmE8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5mZXcgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyB0byB0aGUgbGF0dGVyPzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tLS0tLS08bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ JnF1b3Q7d2UgY291bGQgY29udGludWUgdG8gZ3JvdXAgaXRlbXMgaW4gbG9naWNhbCBwbGFjZXMg YXMgaXMgZG9uZSBub3c8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5pbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5JT0RFRiBhbmQgdGhlbiBoYXZlIHRoZSBleHRlbnNpb24gcG9pbnQgZm9yIGNvbWJpbmVk IGluZGljYXRvcnMgdmlhPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+U0NJLiZxdW90OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ LS0tLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD48 L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9 InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5Zb3UgcG9pbnRlZCBvdXQgd2hhdCB5b3UgY29uc2lkZXIgdG8gYmUgbG9naWNh bCBwbGFjZXMsIGJ1dCBpZiBJPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+d2FudGVkIHRvPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPnByb3RlY3QgaW5mb3JtYXRpb24gZnJvbSBwYXJ0aWVzIGNhcGFibGUg b2YgYXNjZXJ0YWluaW5nIGl0IGZyb20geW91cjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPmxvZ2ljYWwgcGxhY2VzLCBwZXJoYXBzIHdlIHNob3VsZCBhbHNvIGNv bnNpZGVyIHRvIGEgZGVncmVlIHdoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5hcHBlYXJzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+dG88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5iZSBp bGxvZ2ljYWwgaW4gYnJpbGxpYW50IG1pbmRzIGluIHNvbWUgaW5zdGFuY2VzLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43 NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPkMuIEhlbnJ5IEFkYW1zPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89Y2hhdGxnYTIwMDBAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hhdGxnYTIwMDBAeWFo b28uY29tPC9hPiAoRGlyZWN0IEVtYWlsKTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9j b21wb3NlP3RvPWNoZW5yeWFkYW1zQGJpZW1lZGlhZ3JvdXAuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb208L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPm9yaWdpbmFsPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnJlY2lwaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBncmFudGVk IGZvciBsaW1pdGVkIGRpc3RyaWJ1dGlvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPndpdGhpbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPnRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnJl Y2lwaWVudCdzIHBsYWNlIG9mIGJ1c2luZXNzIGZvciBwbGFubmluZyBwdXJwb3NlcyBvbmx5LiBG dXJ0aGVyPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZGlzc2Vt aW5hdGlvbiwgd2hldGhlciBwcml2YXRlIG9yIHB1YmxpYyBpcyBwcm9oaWJpdGVkLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPi0tLSBPbiBTYXQsIDEvMjYvMTMsIE1vcmlhcnR5LCBLYXRobGVl biAmbHQ7PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1v cmlhcnR5QGVtYy5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYx NzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5G cm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4gJmx0OzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWls LnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPWthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20iIHRhcmdl dD0iX2JsYW5rIj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSRTogW21pbGVdIElPQ3M8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UbzogJnF1b3Q7Qy4g SGVucnkgQWRhbXMgJmFtcDsgQklFJnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0bGdhMjAwMEB5YWhvby5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaGF0bGdhMjAwMEB5YWhvby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i aHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVAaWV0Zi5vcmc8L2E+JnF1b3Q7PG86cD48L286cD48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDs8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWlsZUBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9k aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5 aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+RGF0ZTogU2F0dXJkYXksIEphbnVhcnkgMjYsIDIwMTMsIDEwOjEzIEFN PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGVsbG8gQy4gSGVucnkgJmFt cDsgb3RoZXJzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcyBm b3IgdGFraW5nIGEgbG9vayBhdCB0aGlzLiZuYnNwOyZuYnNwO1dlIGhhdmUgYSBmZXcgY29uc2lk ZXJhdGlvbnMgaW48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50 aGlzPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPmVtYWlsIHRocmVhZCBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aG91Z2h0cyBvbiAoYW5kIHRo ZXJlIG1heSBiZSBtb3JlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+b25jZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJGQzUw NzAtYmlzIGlzIGFjdGl2ZWx5IGVkaXRlZCkuPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVv dGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5 TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhl IEFkZGl0aW9uYWxEYXRhIGNsYXNzIGFuZCB0aGUgUmVjb3JkSXRlbSBjbGFzcyBib3RoIGFsbG93 IGZvcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm5vbi1YTUw8 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ ZXh0ZW5zaW9ucy4mbmJzcDsmbmJzcDtXaGVyZSB5b3UgcGxhY2UgdGhlIGV4dGVuc2lvbnMgc2hv dWxkIGJlIHNwZWNpZmljIHRvIHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPmxvZ2ljYWwgZ3JvdXBpbmcgb2YgdGhlIHBhcmVudCBlbGVtZW50cyBzbyB5b3Ug Y2FuIHVuZGVyc3RhbmQgbW9yZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPmFib3V0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ dGhlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5jbHVkZWQg ZGF0YSBpbiBtb3N0IGNhc2VzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBJbXBhY3Qg Y2xhc3MgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBjb250ZXh0IGluZm9ybWF0aW9uIG9uIHRoZTxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5p bmNsdWRlZCBkYXRhIG9mIHRoZSByZXBvcnQgYW5kIGFsc28gY2FuIGluY2x1ZGUgYSBjb25maWRl bmNlIHJhdGluZzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm9u PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cmVwb3J0IGFzIGEgd2hvbGUuJm5i c3A7Jm5ic3A7RXh0ZW5zaW9ucyByZWxhdGVkIHRvIGltcGFjdCB3b3VsZCBiZSBvbmUgbGV2ZWw8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5oaWdoZXI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4oYXQgdGhlIG1vbWVudCkgaW4g dGhlIEFzc2Vzc21lbnQgY2xhc3MgdXNpbmcgdGhlIEFkZGl0aW9uYWxEYXRhPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXh0ZW5zaW9uPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cG9pbnQuPG86cD48L286cD48L3A+PC9kaXY+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg NC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYy MTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+VGFrZSBhc2tlZCBhYm91dCBpbmNsdWRpbmcgdnVsbmVyYWJpbGl0eSBpbmZvcm1hdGlv biwgSSB3b3VsZCB0aGluazxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPnRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+d291bGQgZml0IHVuZGVyIHRoZSBWdWxuZXJhYmlsaXR5IGV4dGVuc2lvbiBwb2lu dCBvZiB0aGUgU0NJIGRyYWZ0IGluPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+dGhlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ TWV0aG9kIGNsYXNzLiZuYnNwOyZuYnNwO0hlIGRpZCBhc2sgYWJvdXQgbm9uLVhNTC4mbmJzcDsm bmJzcDtSZWNvcmRJdGVtIG9yPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+QWRkaXRpb25hbERhdGE8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5kbzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFs bG93IGZvciBub24tWE1MIGV4dGVuc2lvbiBwb2ludHMsIHdlIGNvdWxkIGVpdGhlciBoYXZlIHRo ZSBTQ0k8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5kcmFmdDxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmhhbmRsZSB0aGVzZSBh cyB3ZWxsIG9yIGhhdmUgdGhlIGV4dGVuc2lvbnMgdGhhdCBhcmUgbm9uLVhNTCBjb21lPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZGlyZWN0bHk8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vZmYgdGhlIEFkZGl0aW9uYWxEYXRh IG9yIFJlY29yZEl0ZW0gY2xhc3NlcyBhY2NvcmRpbmcgdG8gd2hhdCBtYWtlczxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNlbnNlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZnJvbSBhIGxvZ2ljYWwgc3RhbmRwb2ludC48bzpw PjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BcyBmb3IgbXkgcXVlc3Rpb24sIGl0IHdhcyB0d28tZm9s ZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JbmRpY2F0b3IgYmFzZWQg c2NoZW1hcyBoYXZlIGEgcmVmZXJlbmNlIG51bWJlciBvciBhIEdVSUQgZm9yIHRoZTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnZhcmlvdXM8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5kaWNhdG9ycyB0 aGV5IHNoYXJlLiZuYnNwOyZuYnNwO0lmIHdlIGFyZSBleHRlbmRpbmcgdG8gZW1iZWQgb3RoZXIg c2NoZW1hczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYXQ8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmNsdWRlIHN1Y2gg cmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMsIGRvIHdlIHdhbnQgdG8gYWRkIGFuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YXR0cmlidXRlPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dG8gdGhlIHZhcmlvdXMgZWxlbWVu dHMgaW4gSU9ERUYgdGhhdCBjb3VsZCBiZSBpbmRpY2F0b3JzPyZuYnNwOyZuYnNwO0lzIHRoaXM8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5lbm91Z2g8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50byBtYWtlIHRoZSBjb25uZWN0 aW9ucyBvciBpcyBzb21ldGhpbmcgZWxzZSBlbHNlIG5lZWRlZD8mbmJzcDsmbmJzcDtXZSBjb3Vs ZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmFkZDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNvbWV0aGluZyBsaWtlIGFuIElu ZGljYXRvcl9JRCBpbiBSRkM1MDcwLWJpcyB3aGljaCB3b3VsZCB0aGVuPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29ycmVsYXRlPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dG88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD50aGUgcmVmZXJlbmNlIG9yIEdVSUQgaWRlbnRpZmllcnMuPG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlbiB0aGUgb3RoZXIgcXVlc3Rpb24gd2FzIG9uIGhvdyB0 byBpbmNsdWRlIGluZGljYXRvcnMgdGhhdCBhcmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5ub3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5pbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD50aGUgYmFzZSBzY2hlbWEgdGhhdCBtYXkgYmUgcmVsYXRlZCBvciBoYXZlIGxh bmd1YWdlIHdpdGggJnF1b3Q7YW5kJnF1b3Q7ICZxdW90O29yJnF1b3Q7PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dG88bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5zcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXBzLiZuYnNwOyZuYnNw O0luIHNvbWUgY2FzZXMsIHlvdSB3aWxsIHdhbnQgdG8gZ3JvdXA8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGVzZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmluZGljdG9ycyBpbiBvbmUgZXh0ZW5zaW9uIHBvaW50LCB3aGVy ZSB0aGV5IG1heSBmaXQgbG9naWNhbGx5IGluPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+bXVsdGlwbGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5wbGFjZXMgaWYgdGhlIHJlbGF0aW9uc2hpcHMgZGlkIG5vdCBuZWVkIHRvIGJl IHNob3duIGluIHRoZSBkYXRhPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Zm9ybWF0LiZuYnNwOyZuYnNwO0lmPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+d2UgaGF2ZSBjYXNlcyBsaWtlIHRoaXMgd2hlcmUgeW91IG5lZWQgbW9y ZSBjb21wbGV4IHJlcHJlc2VudGF0aW9ucyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5zaG91bGQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD53ZSB1c2Ugb25lIGV4dGVuc2lvbiBwb2ludCB2aWEgdGhlIFNDSSBkcmFmdCBvZmYg b2YgdGhlIEV2ZW50RGF0YTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPmNsYXNzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QWRk aXRpb25hbERhdGEgZXh0ZW5zaW9uIHBvaW50PyZuYnNwOyZuYnNwO09waW5pb25zIGFyZSBuZWVk ZWQgaGVyZS4uLi48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BIGZldyBwZW9wbGUgaGF2ZSBt ZW50aW9uZWQgd2FudGluZyB0byBpbmNsdWRlIHNvbWUgY29tbW9ubHkgc2hhcmVkPG86cD48L286 cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZGljdG9y cyBpbnRvIHRoZSBiYXNlIElPREVGIGRvY3VtZW50LiZuYnNwOyZuYnNwO1dlIGNvdWxkIGhhdmUg YSBjYXRjaC1hbGw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5j bGFzczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoYXQgZG9l cyB0aGlzIGFuZCBoYXMgYW4gZXh0ZW5zaW9uIHBvaW50IG9mZiBvZiBpdCBpbiBFdmVudERhdGEg b3I8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD53ZTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNvdWxkPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29udGludWUgdG8gZ3JvdXAgaXRlbXMgaW4g bG9naWNhbCBwbGFjZXMgYXMgaXMgZG9uZSBub3cgaW4gSU9ERUYgYW5kPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlbjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPmhhdmUgdGhlIGV4dGVuc2lvbiBwb2ludCBmb3IgY29tYmlu ZWQgaW5kaWNhdG9ycyB2aWEgU0NJLiZuYnNwOyZuYnNwO0kgdGhpbmsgSTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmxpa2U8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGUgbGF0dGVyIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj QjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBp ZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5LYXRobGVlbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiA8YSBocmVmPSJodHRwOi8v dXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJo dHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC ZWhhbGYgT2YgQy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5I ZW5yeTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5BZGFtcyAmYW1wOyBCSUUgWzxhIGhyZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9v LmNvbS9tYy9jb21wb3NlP3RvPWNoYXRsZ2EyMDAwQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNoYXRsZ2EyMDAwQHlhaG9vLmNvbTwvYT5dPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVv dGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5 TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+U2VudDogU2F0dXJkYXksIEphbnVhcnkgMjYsIDIwMTMgMzowNSBBTTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiA8YSBocmVmPSJodHRwOi8vdXMubWM1 MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWlsZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5DYzogQy4gSGVucnkgQWRhbXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSZTogW21pbGVdIElPQ3M8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5HcmVldGluZ3MgRXZlcnlvbmUsPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGFrZSBtZW50aW9uZWQgdHdvIHR5cGVzIG9mIGluZGlj YXRvcnMgYmFzZWQgb24gdGhlIDo8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNC NUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlk PSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+MSkgSWYgdGhlIGluZGljYXRvcnMgYXJlIHNvbWV0aGluZyBsaWtl IGFuIFhNTC1iYXNlZCBhbGVydC93YXJuaW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+b2Y8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5pbmZvcm1hdGlvbiBsZWFrYWdlLCBpdCBjb3VsZCBiZSBhbiBldmVudCB0aGF0IGFyZSBj b252ZXllZCBpbiB0aGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5TQ0kncyBFdmVudFJlcG9ydCBjbGFzcywgSU1ITy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4yKSBJZiB0aGUgaW5kaWNhdG9ycyBhcmUgc29tZXRoaW5nIGxpa2UgYW4g bm9uLVhNTCBvbmVzLCBJIGd1ZXNzIGl0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Y291bGQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+YmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb252 ZXllZCB3aXRob3V0IHVzaW5nIFNDSSBkcmFmdC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5Gb3IgaW5zdGFuY2UsIHdlIGNvdWxkIHVzZSBJbXBhY3QgY2xhc3Mg b2YgdGhlIGJhc2UgSU9ERUYgdG8gY29udmV5PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+dGhlIGluZGljYXRvcnMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+V2UgY291bGQgZm9yIGluc3RhbmNlIGV4dGVuZCB0aGUgbGlzdCBv ZiBpbmRpY2F0b3JzIG9mIHRoZSBJbXBhY3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5jbGFzcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+aWY8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNf T1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5u ZWVkZWQuPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+LS0tLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1 b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3 OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklu IGRvaW5nIHNvIGhlIHBvaW50ZWQgb3V0IHRoZSAmcXVvdDtJbXBhY3QgQ2xhc3MmcXVvdDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XaGVyZWFzLCBLYXRobGVlbiBzdGF0 ZWQsPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+LS0tLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Rm9yIHRoZSBkaXNjdXNzaW9uIGJlbG93LCBJIHdhcyB0aGlua2luZyBtb3JlIG9mIGNvbWJpbmVk IHNldCB3aXRoPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPnJlbGF0aW9uc2hpcHMgdGhhdCBtYXkgYmUgaW5jbHVkZWQgaW4gYSBzaW5nbGUg ZXh0ZW5zaW9uIHBvaW50LCBzbzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPnRoYXQnczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PndoeSBJIHdhcyB0aGlua2luZyBhYm91dCB0aGUgRXZlbnREYXRhIGNsYXNzLCBidXQgdGhlcmUg bWF5IGJlIGJldHRlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PmxvY2F0aW9ucyBvciBhIHNwZWNpZmljIGFyZWEgd2l0aGluIHRoZSBFdmVudERhdGEuPG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQnIGlkPSJ5aXYyMTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+UGF1bCBTdG9lY2tlciBoYWQgc3VnZ2VzdGVkIGEgJnF1b3Q7 RGV0ZWN0aW9uJnF1b3Q7IGNsYXNzIGFzIGEgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLS0tLS0tLTxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0JyBpZD0ieWl2MjEyODUwNjE3OU1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkthdGhsZWVuIHRob3VnaHRzIHJlbGF0ZWQg eWV0IHN0aWxsIHdpdGggb3RoZXIgaW5kaWNhdG9ycyBhbmQgdGhlPG86cD48L286cD48L3A+PC9k aXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkV2ZW50RGF0YSBDbGFzcy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCcgaWQ9InlpdjIxMjg1MDYxNzlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JcyB0aGVyZSBhIHBvc3NpYmxlIHdheSB0byBjcmVh dGUgYSBuZXcgWE1MIGNsYXNzIHdoaWNoIGVuY29tcGFzczxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb21iaW5pbmcgdGhlIEV2ZW50RGF0 YSwgRGV0ZWN0aW9uIGFuZCBiYXNlIElPREVGIGNsYXNzZXMgdG8gc2ltcGxpZnk8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGlzPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aXNzdWU/PG86cD48L286cD48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYyMTI4 NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Qy4g SGVucnkgQWRhbXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1jaGF0 bGdhMjAwMEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGF0bGdhMjAwMEB5YWhvby5jb208 L2E+IChEaXJlY3QgRW1haWwpPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89Y2hlbnJ5YWRhbXNAYmllbWVkaWFncm91cC5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGVucnlh ZGFtc0BiaWVtZWRpYWdyb3VwLmNvbTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1 c2Ugb2YgdGhlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+b3Jp Z2luYWw8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+cmVjaXBpZW50LiBUaGlzIGluZm9ybWF0aW9uIGlzIGdyYW50ZWQgZm9yIGxpbWl0ZWQg ZGlzdHJpYnV0aW9uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ d2l0aGluPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cmVjaXBpZW50J3MgcGxh Y2Ugb2YgYnVzaW5lc3MgZm9yIHBsYW5uaW5nIHB1cnBvc2VzIG9ubHkuIEZ1cnRoZXI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5kaXNzZW1pbmF0aW9uLCB3aGV0 aGVyIHByaXZhdGUgb3IgcHVibGljIGlzIHByb2hpYml0ZWQuPG86cD48L286cD48L3A+PC9kaXY+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg NC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJ5aXYy MTI4NTA2MTc5TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5taWxlIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhy ZWY9Imh0dHA6Ly91cy5tYzUzNC5tYWlsLnlhaG9vLmNvbS9tYy9jb21wb3NlP3RvPW1pbGVAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5taWxlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWlsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlsZTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+bWlsZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJodHRwOi8vdXMubWM1MzQubWFpbC55YWhvby5j b20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlsZUBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PG86 cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bWlsZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJodHRwOi8vdXMubWM1MzQu bWFpbC55YWhvby5jb20vbWMvY29tcG9zZT90bz1taWxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWlsZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p bGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pbGU8L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm1pbGUgbWFpbGlu ZyBsaXN0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJl Zj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/dG89bWlsZUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9taWxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9taWxlPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pm1pbGUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGEgaHJlZj0iaHR0cDovL3VzLm1jNTM0Lm1haWwueWFob28uY29tL21jL2NvbXBvc2U/ dG89bWlsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlPC9hPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L3RkPjwvdHI+PC90YWJs ZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_F5063677821E3B4F81ACFB7905573F24CEBDF2E4MX15Acorpemccom_-- From Christopher.Harrington@emc.com Wed Feb 13 11:08:29 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575DC1F0D0A for ; Wed, 13 Feb 2013 11:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.576 X-Spam-Level: * X-Spam-Status: No, score=1.576 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BZF8y6RS+9V for ; Wed, 13 Feb 2013 11:08:23 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2421F0CB7 for ; Wed, 13 Feb 2013 11:08:21 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DJ8Ie9018411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Feb 2013 14:08:21 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 13 Feb 2013 14:08:06 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1DJ86YJ029590 for ; Wed, 13 Feb 2013 14:08:06 -0500 Received: from mx36a.corp.emc.com ([169.254.1.17]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Wed, 13 Feb 2013 14:08:05 -0500 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , MILE IETF Date: Wed, 13 Feb 2013 14:08:04 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4J/nM0FwsOXwAHQbisW5VEKlAi4AACYgwgAAU1dVAAABjLgA== Message-ID: References: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0084_01CE09F3.8A8BBE40" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:08:29 -0000 ------=_NextPart_000_0084_01CE09F3.8A8BBE40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0085_01CE09F3.8A8BBE40" ------=_NextPart_001_0085_01CE09F3.8A8BBE40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That will work provided I (and everyone else) has a mapping for the = numbers. I would prefer a simple low/med/high scheme. The more we add = the more you have to be able to differentiate between them. However for = potential interoperability I do see the benefit of the 5.=20 =20 Thanks, --Chris =20 From: Moriarty, Kathleen=20 Sent: Wednesday, February 13, 2013 2:05 PM To: Harrington, Christopher; MILE IETF Subject: RE: [mile] IOCs =20 =20 If you think of IODEF just for transport, could you meet your needs with = storing the values differently in a database (IODEF is just meant for = the exchange)? The numbers map to low/med/high =E2=80=93 for db storage = =E2=80=93 if numbers are used, you could store the equivalent value, = adding the 2 additional ones provided. =20 Does it make sense to expand the set of values to match what CIF is = doing if we went forward with the approach of supporting both options? =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Harrington, Christopher Sent: Wednesday, February 13, 2013 11:49 AM To: 'C. Henry Adams & BIE'; MILE IETF Subject: Re: [mile] IOCs =20 >From a data processing standpoint it is going to create extra work for = the people who are going to receive this data if we support both numeric = and alpha characters in the same field. I can envision people wanting to = search, sort, store, etc the data in this field. If we allow both data = types then everyone will need to have a mapping of some sort. I have a = field for confidence in my threat tracking database. Having both a = numeric score and alpha characters / words creates issues when trying to = interact with the data. I agree that we need to support both however I = don=E2=80=99t think both should be in the same field. I would much = rather see 2 different fields for Confidence if we are going to support = 2 different data types.=20 =20 This will be a larger issue should Confidence be used elsewhere. Ideally = in future revisions I would like to see attribution expressed as some = form of attribution is almost always shared with an IoC. Currently = there are 5 areas where we (EMC) uses confidence.=20 =20 Indicator (how confident are you that this is a valid IoC) Indicator_Set (how confident are you that all of the indcators in the = set should be in the set) Campaign (how confident are you that all Indicator_Sets are part of this = campaign) Threat Actor (how confident are you that the Campaign is attributed to = this Threat Actor) Threat Actor type (how confident are you that this Theat Actor is APT, = Crimeware, other) =20 The threat actor name and the threat actor type are usually the first 2 = things that anyone processing IoCs wants to know as they drive priority. = Knowing how sure the sender is that this IoC is APTis a vital piece of = information for us. Sorry to take us a little off the path but I wanted = to show where Confidence could be used.=20 =20 Thanks, --Chris =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = C. Henry Adams & BIE Sent: Wednesday, February 13, 2013 10:24 AM To: MILE IETF Subject: Re: [mile] IOCs =20 Again, I would concur that both a numeric and subjective analysis of the = Confidence Rating needs to be express, but combined in a simplified = schema as such below: 1LL .... etc. 2P 3AC 4U 5I ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) Here's my point, perhaps a set of numeric related or associated = definitions can lower the propagation of error regarding the analysis. = Thanks, C. Henry Adams I agree that what we really need is both. In most situations a low, = medium and high may be acceptable but there are times when we will want = to show that confidence in a situation is increasing or decreasing. If = we are only looking at a three levels, we cannot express what is needed = to show confidence is trending up on the data being exchanged about the = event. =20 Kathleen included the following in a previous message. =20 =20 Vs: =20 85 =20 I really think we need to include both capabilities as John alluded to = since confidence is not a three tiered item but something that is indeed = subjective and we need a means to show a reasonably accurate confidence = index that the sender is trying to convey. =20 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 From: , John Banghart = > Date: Wednesday, February 13, 2013 7:16 AM To: "Stoecker, Paul" = >, Kathleen Moriarty >, Brian Trammell = > Cc: "C. Henry Adams & BIE" = >, MILE IETF > Subject: Re: [mile] IOCs =20 Paul, =20 I agree that confidence is subjective, but subjectivity can be reduced within communities that interact frequently. Prioritization of = indicators and response between tightly connected sharing partners might require a more specific level of detail, particularly during a crisis situation. =20 >From that perspective, I think the guidance should allow for additional granularity, while stressing the "high, medium, low" as preferred for broad interoperability. =20 -John =20 On 2/13/13 8:04 AM, "Stoecker, Paul" > = wrote: =20 I may have been too succinct in my response ;-) =20 Confidence is a subjective thing, so I think we should use subjective terms: Low, Medium, High. Having a numeric scale with a map that essentially would say something like: =20 1-33 =3D Low 34-67=3D Medium 68-100=3DHigh =20 Is just a more complicated way of saying that something is Low, Medium, High...do we really thing that how High something is makes that much of = a difference? =20 This is like when you get your Performance review where it is Does Not Meet, Meets and Exceeds...your boss tells you that you are a High Meets...your bonus tells you that you got the same bonus that all the other Meets got ;-) =20 Anyway, I digress but trying to prove a point that I would argue that confidence in this case is going to be basically a gut feeling, so why = use numeric values when Low, Medium, High would do just fine. =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 =20 =20 =20 =20 =20 On 2/13/13 7:48 AM, "Moriarty, Kathleen" > wrote: =20 Hello, =20 Both approaches will validate in the current schema. The representation looks a little different for each, here is an example: =20 =20 Vs: =20 85 =20 Searching capability is a great point, agreed. I'd like to hear from more people to make sure we don't lose a capability that others find extremely useful (need to gauge that). Other options is that the guidance can also discourage the use of the numeric in addition to specifying how to select ranges. =20 Any other opinions? =20 Thanks, Kathleen =20 -----Original Message----- From: Stoecker, Paul Sent: Wednesday, February 13, 2013 7:14 AM To: Brian Trammell Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF Subject: Re: [mile] IOCs =20 Cant we make Confidence a List that has only 3 values: High, Medium, = and Low? Any other value means that the Document will mot validate against the schema. =20 Sent from my iPhone =20 On Feb 13, 2013, at 2:14 AM, "Brian Trammell" = > wrote: =20 Hi, Kathleen, all, =20 I think 3.10.4 in 5070 takes the right approach here: trying to build interoperable numeric scales for assessment is a very hard problem. (Were I charged with defining such a scale, the value "70" would mean "we compared this incident report to N past similar incident reports according to similarity algorithm S, and 70% of the past reports had assessed impacts within E% of the actual, measured final impact -- I think for most applications this is vastly more difficult and rigorous than it needs to be.) =20 Unless a numeric Confidence value is based on some actual, repeatably measurable aspect of the Assessment report -- which I suspect in many/most/all cases it's not -- then it just represents a guess, however educated. Each team will probably naturally tune its own scales such that each value generally means the same thing in each report. Across teams, I don't know. =20 On the other hand, Assessments are by their very nature educated guesses, anyway, so I don't know that I'd find much use in automating a response based on the assessment confidence. Chris has a good point, though -- it makes searching difficult and sorting kind of pointless. =20 If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I agree, we should put that in the guidance document (along with a note that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, unless we want to do it non-linearly). If the _vast_majority_ of the users of this field use a 100-point scale with 100 meaning "yes" and 0 meaning "any resemblance these values may have to actual fact is purely coincidental", then let's consider renaming it "percent" in 5070-bis. =20 Best regards, =20 Brian (as contributor) =20 =20 On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" > wrote: =20 Please see section 3.10.4 of RFC5070 as a starting point. We can change it if it needs to be changed. The value is for a confidence rating on the indicators shared. The definitions may be helpful for anyone who wants to work on this discussion. IODEF has various markers that can be used in a complimentary way without conflating the markers meaning. =20 I think some people using IODEF find the numerical values more helpful, and it would be good to understand what people have learned from using the current structure (what works/does not work). The scales I have seen are 0-100. There is of course a subjective element to assigning a numerical value to the confidence and it may vary from entity to entity. With this type of rating you may need to consider who it came from and how they scored the confidence rating to map to your own rating. It would be good to hear more thoughts on this. =20 Thanks, Kathleen =20 From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com = ] Sent: Tuesday, February 12, 2013 2:46 PM To: MILE IETF Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul Subject: Re: [mile] IOCs =20 =20 Regarding the IOCs or Indicators of Compromise, Chris made a vital point. Different Confidence levels will cause confusion. It appears that there maybe a need for some type of simplified standardization to be established between all Sharing Groups in this regard. =20 Perhaps numerical scoring set at lower values should express levels of urgency. ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) =20 Thanks, C. Henry Adams =20 =20 =20 I see some confusion coming down the pike if we start using Confidence the way it is supported. If I am using low/med/high and someone sends me an IoC with a score of 70, what does that mean to me? What if I am using a scale of 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to describe something with a consistent language. It really gets ugly when we store IoC from multiple sources. I have confidence values that are numeric as well as text. Makes searching / sorting very problematic. =20 At this point we have to roll with what we have. I would strongly recommend that we revisit this at some point. =20 Thanks, =20 --Chris =20 -----Original Message----- From: Moriarty, Kathleen Sent: Tuesday, February 12, 2013 9:59 AM To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Hi Chris & Take, =20 I'll just focus on the confidence scoring. Right now, the schema allows for you to either use a numerical score OR the ratings of low, medium, and high. Different sharing groups can decide how they want to share the data. If people were to use the numerical values, I agree it would be helpful to have guidance. This could go in the IODE guidance document. =20 I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can. =20 Thank you, Kathleen =20 -----Original Message----- From: Harrington, Christopher Sent: Tuesday, February 12, 2013 9:22 AM To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 The number of indicators wouldn't necessarily drive the use of indicator_set_id. The purpose is to show relationship. If I sent 3 IP addresses that were used as C2 for 3 different campaigns I would have separate indicator_set_ids, each with one of the 3 C2 IPs =20 My suggestion would be a simple low, medium, high. I think if we break it down to more levels than that we would need to provide guidance on scoring, rating, etc. I think most people should be able to understand low/med/high without having to have a mathematical method for arriving at the level. =20 Low - I am not sure Medium - I am reasonably sure High - I am very sure =20 =20 Thanks, =20 --Chris =20 -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp = ] Sent: Tuesday, February 12, 2013 4:21 AM To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Regarding the indicator_set_id, I agree, it is useful when we need to deal with large sets of indicators. Since indicator_set_id attribute is optional (right?), it could be omitted if we need to deal with only small number of indicators. =20 Regarding the use case, I like the idea of using the confidence attribute for the reason Chris kindly described. I would like to hear a bit more on this: is it going to be numerical? For instance, 1 means "no confidence" while 5 means "strong confidence", etc? =20 Thank you. Take =20 =20 -----Original Message----- From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com = ] Sent: Friday, February 08, 2013 4:11 AM To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 With respect to tying things back to threat actors, from what I have seen and use this is a generally accepted grouping: =20 Indicator --> Indictor Set --> Campaign --> Threat Actor =20 Campaign and Threat Actor are where having a "Confidence" attribute would be beneficial as making those associations is not a perfect science by any means. =20 Thanks, =20 --Chris =20 =20 -----Original Message----- From: Moriarty, Kathleen Sent: Thursday, February 07, 2013 2:00 PM To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE IETF' Subject: RE: [mile] IOCs =20 Hi Take & others, =20 Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions. I'll provide an option below from what we have discussed from a CIRC view point. We are also wondering how to also provide logic in IODEF that could cross over into SCI attached schemas or IODEF extensions (the solutions may all tie together with this discussion - or there may be better/more elegant solutions others would like to propose). =20 -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp = ] Sent: Tuesday, February 05, 2013 12:04 PM To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF' Subject: RE: [mile] IOCs =20 I like this discussion. I agree, it would be good idea to have indicator identifiers inside the IOC-related classes. =20 KMM: At the class level, we may have several indicators listed that should be viewed as a set and may have another instance of that same class that is a related issue, but a separate set. We could as you say, list the indicator IDs connected through the reference class. The set IDs might give us other ways to group the values when we get into logic and relationships between sets or indicators. This could also be a way to connect indicators or sets across XML documents that could have been shared previously. If there are a large number of indicators in the set, then this becomes useful, for smaller sets, I agree it doesn't make as much sense. =20 What do others think? =20 Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). =20 If we could see any indicator of compromise as computer event record, we could use SCI:EventReport class as the place for the XML-based IOCs that couldn't fit anywhere else. =20 KMM: That sounds like a good idea to me. This should go into guidance in the SCI draft. Does anyone else want to weigh in? =20 =20 For the non-XML IOCs, we could use RecordData class, as suggested. KMM: Sounds good, thanks! =20 I agree to have indicator_uid, but I am not sure about the needs of the indicator_set_id. I understand we could do some grouping of individual indicator_uids and its usability, but I am not sure whether we do not have any other way to express these groupings. For instance, a Reference class refers to several indicadtor_uids. In this case, they could be, in a sense, grouped. Isn't it enough? =20 KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets? Would this happen? Would it be easier to express relationships with sets of indicators in addition to individual indicators? By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current structure. If there are better ways to handle that, and others can provide some options, that would be appreciated! =20 Thank you, Kathleen =20 I would appreciate if anybody could share expertise on this. Though I think I have read all the emails in the list, I might have mis-understood some points. =20 By the way, I think the indicator_uids should be added to the SCI classes' attributes so that they can be correlated with another information as well. =20 Thanks Take =20 =20 =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of Harrington, Christopher Sent: Tuesday, February 05, 2013 4:25 AM To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF Subject: Re: [mile] IOCs =20 I think some sort of group ID would do the trick. We also need a logical and / or somewhere to show relationship between indicators. If I give you 2 registry keys do they both have to be present to be an indication of compromise or is either one by themselves an indicator? Both would have the same group ID since they are related. =20 Thanks, --Chris =20 From: Stoecker, Paul Sent: Sunday, February 03, 2013 8:26 PM To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF Subject: Re: [mile] IOCs =20 What if we added indicator group ID along with the indicator_uid? This would allow you to group indicators that are related into the same group ID. Would this resolve the issue? =20 It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together. I don't mean a place to put indicators that are missing from IODEF.I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident. I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX. =20 Paul =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 =20 From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM To: "Harrington, Christopher" >, MILE IETF > Subject: Re: [mile] IOCs =20 Hi Chris, =20 I agree, we have some work to do in the updated IODEF, RFC5070-bis. =20 The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an incident or the useful information on an incident for sharing purposes. It was written before we used terms like indicators. With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates. It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution. =20 As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document. In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators. I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack. Rosella had suggested pulling forward the "FraudType" from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term). It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole", "MalwareDistribution" for added context so you know what to do with the received set of indicators. =20 I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF. =20 Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below). What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData? I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together. Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well? Maybe we want indicator_set at the higher level? I'd like some opinions on this approach. +1 if you agree, suggestions if you have other ideas that may work better. =20 We'll also need to worry about marking the indicators to prevent forward sharing when not permitted. We may want to use these values or something else. =20 Thank you! Kathleen =20 From: Harrington, Christopher Sent: Friday, February 01, 2013 12:01 PM To: Moriarty, Kathleen; MILE IETF Subject: RE: [mile] IOCs =20 I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related: =20 Two or more indicators of different type that relate to the same threat: The file hash of a malicious file and the URL of the C2 that the file uses. Either or both may be present to indicate a compromise. =20 Two or more indicators of the same type that relate to the same threat: 2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. =20 The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading. =20 The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. =20 Thoughts? =20 Thanks, =20 --Chris =20 Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of Moriarty, Kathleen Sent: Friday, February 01, 2013 11:28 AM To: MILE IETF Subject: Re: [mile] IOCs =20 All - =20 I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message. =20 Interesting point, C. Henry. Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality. =20 Paul mentioned the need to distinguish indicators of compromise from context information that may also include IP address or other data that could be indicators. The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas. =20 If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators? Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately? =20 Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message). =20 Comments and questions encouraged to figure out the right technical solution to have this machine automatable. =20 Thank you, Kathleen =20 From: mile-bounces@ietf.org = = [mailto:mile-bounces@ietf.org = ] = On Behalf Of C. Henry Adams & BIE Sent: Monday, January 28, 2013 11:25 PM To: MILE IETF Subject: Re: [mile] IOCs =20 Temporal Dependency sounds interesting. I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question. He said, " How do you stop someone from tracking the IP Address to your computer?" =20 I replied, "I don't know, how?" =20 Then he said, "Cut the dog-gone thing off and the modem that it is connected- which is constantly on!" LOL =20 Here's my point (Hypothetical Situation) : There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let's just say "Live" Terrorist Situation. He /or She needs to communication back to other Officials that he /or somehow is in Danger. The device used to communicate has been captured by the great minds of the enemy. It's only a matter of time before they utilize reverse engineering to figure out how it functions. However, their pride comes before a fall when seeking the location of other similar devices to attack. Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking). =20 Just a visionary thought. =20 C. Henry Adams chenryadams@biemediagroup.com = =20 http://biemediagroup.com =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 --- On Mon, 1/28/13, Dave Misell > = wrote: =20 From: Dave Misell > Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id? =20 Yours Faithfully, =20 Dave Misell MSc CISSP SilentCircle dsm 07710 380044 david.misell@bcs.org = =20 =20 =20 On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > wrote: =20 Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to a degree what appears to be illogical in brilliant minds in some instances." =20 However, I see Dr. Stoecker's point a little clearer. However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way. =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 Re: [mile] IOCs =20 Sunday, January 27, 2013 8:52 PM From: "Stoecker, Paul" > To: "mile@ietf.org = " = > I would like to look at this from a slightly different perspective=C5=A0let's say I get an XML document that tells me about an incident. This document has source IP and destination IP that is being shared. However, what I don't know is which IP address is my indicator and which is just a contextual piece of information. This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. =20 If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data. I do admit to being biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. =20 =20 I did suggest the detection class, but I think we may get more flexibility with the indicator_uid. One thing that I haven't considered is the UID portion of this=C5=A0how do we use that UID? How is the UID created? Are there standards for UIDs? =20 Regards, =20 Paul =20 =20 =20 Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com = =20 =20 --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: =20 From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs To: "KathleenMoriarty" > Cc: mile@ietf.org = =20 Date: Saturday, January 26, 2013, 6:17 PM =20 Greetings Kathleen, =20 Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once. However, could you share a few advantages and disadvantages to the latter? -------------------------------------------------------------------- -------- ---------------------------------------------- "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI." -------------------------------------------------------------------- -------- --------------------------------------------- =20 You pointed out what you consider to be logical places, but if I wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances. =20 =20 =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. =20 --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: =20 From: Moriarty, Kathleen > Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" = >, "mile@ietf.org = " > Date: Saturday, January 26, 2013, 10:13 AM =20 Hello C. Henry & others, =20 Thanks for taking a look at this. We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited). =20 The AdditionalData class and the RecordItem class both allow for non-XML extensions. Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about the included data in most cases. =20 The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole. Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point. =20 Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class. He did ask about non-XML. RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint. =20 As for my question, it was two-fold. =20 Indicator based schemas have a reference number or a GUID for the various indicators they share. If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators? Is this enough to make the connections or is something else else needed? We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers. =20 Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships. In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format. If we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point? Opinions are needed here.... =20 A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document. We could have a catch-all class that does this and has an extension point off of it in EventData or we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI. I think I like the latter approach. =20 Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org = = [mile-bounces@ietf.org = ] = On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.com = ] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org = =20 Cc: C. Henry Adams Subject: Re: [mile] IOCs =20 Greetings Everyone, =20 Take mentioned two types of indicators based on the : -------------------------------------------------------------------- -------- -------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. =20 2) If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. -------------------------------------------------------------------- -------- -------------------------- =20 In doing so he pointed out the "Impact Class" =20 Whereas, Kathleen stated, -------------------------------------------------------------------- -------- ------------------------- For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. =20 Paul Stoecker had suggested a "Detection" class as a consideration. -------------------------------------------------------------------- -------- ------------------------ =20 Kathleen thoughts related yet still with other indicators and the EventData Class. =20 Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? =20 =20 C. Henry Adams chatlga2000@yahoo.com = = (Direct Email) chenryadams@biemediagroup.com = =20 =20 =20 The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 _______________________________________________ mile mailing list mile@ietf.org = =20 https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0085_01CE09F3.8A8BBE40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That will work provided I (and everyone else) has a mapping for the = numbers.=C2=A0 I would prefer a simple low/med/high scheme. The more we = add the more you have to be able to differentiate between them. However = for potential interoperability I do see the benefit of the 5. =

 

Thanks,

--Chris

 

From:= = Moriarty, Kathleen
Sent: Wednesday, February 13, 2013 2:05 = PM
To: Harrington, Christopher; MILE IETF
Subject: = RE: [mile] IOCs

 

 

If you think of IODEF just for transport, could you meet your needs = with storing the values differently in a database (IODEF is just meant = for the exchange)?  The numbers map to low/med/high =E2=80=93 for = db storage =E2=80=93 if numbers are used, you could store the equivalent = value, adding the 2 additional ones provided.

 

Does it make sense to expand the set of values to match what CIF is = doing if we went forward with the approach of supporting both = options?

 

Thank you,

Kathleen

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of Harrington, Christopher
Sent: = Wednesday, February 13, 2013 11:49 AM
To: 'C. Henry Adams = & BIE'; MILE IETF
Subject: Re: [mile] = IOCs

 

From a data processing standpoint it is going to create extra work = for the people who are going to receive this data if we support both = numeric and alpha characters in the same field. I can envision people = wanting to search, sort, store, etc the data in this field. If we allow = both data types then everyone will need to have a mapping of some sort. = I have a field for confidence in my threat tracking database. Having = both a numeric score and alpha characters / words creates issues when = trying to interact with the data. I agree that we need to support both = however I don=E2=80=99t think both should be in the same field. I would = much rather see 2 different fields for Confidence if we are going to = support 2 different data types.

 

This will be a larger issue should Confidence be used elsewhere. = Ideally in future revisions I would like to see attribution expressed = as  some form of attribution is almost always shared with an = IoC.  Currently there are 5 areas where we  (EMC) uses = confidence.

 

Indicator (how confident are you that this is a valid = IoC)

Indicator_Set (how confident are you that all of the indcators in the = set should be in the set)

Campaign (how confident are you that all Indicator_Sets are part of = this campaign)

Threat Actor (how confident are you that the Campaign is attributed = to this Threat Actor)

Threat Actor type (how confident are you that this Theat Actor is = APT, Crimeware, other)

 

The threat actor name and the threat actor type are usually the first = 2 things that anyone processing IoCs wants to know as they drive = priority.  Knowing how sure the sender is that this IoC is APTis a = vital piece of information for us.  Sorry to take us a little off = the path but I wanted to show where Confidence could be used. =

 

Thanks,

--Chris

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of C. Henry Adams & BIE
Sent: Wednesday, = February 13, 2013 10:24 AM
To: MILE IETF
Subject: = Re: [mile] IOCs

 

Again, I would concur = that both a numeric and subjective analysis of the Confidence Rating = needs to be express, but combined in a simplified schema as such = below:

<Confidence rating=3D" = Alphanumeric">1LL</> .... etc.

<Confidence = rating=3D" Alphanumeric">2P</>

<Confidence = rating=3D" Alphanumeric">3AC</>

<Confidence = rating=3D" Alphanumeric">4U</>

<Confidence = rating=3D" Alphanumeric">5I</>

( i.e.  1 =3D Less Likely,   2 =3D = Probable,  3 =3D A Concern,  4 = =3D  Urgent, 5 =3D Imminent )

Here's my point, perhaps = a set of numeric related or associated definitions can lower the = propagation of error regarding the analysis.   =


Thanks,
C. Henry = Adams


I agree that what we really need is both.  In most = situations a low, medium and high may be acceptable but there are times = when we will want to show that confidence in a situation is increasing = or decreasing.  If we are only looking at a three levels, we cannot = express what is needed to show confidence is trending up on the data = being exchanged about the event.

 

Kathleen included the following in a previous = message.

 

<Confidence = rating=3D"low"/>

 <= /p>

Vs:

=

 <= /p>

<Confidence = rating=3D"numeric">85</>

 

I really think we need to include both capabilities as = John alluded to since confidence is not a three tiered item but = something that is indeed subjective and we need a means to show a = reasonably accurate confidence index that the sender is trying to = convey.

 

= Kent Landfield=

McAfee = | An Intel Company
Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: <Banghart>, John Banghart <john.banghart@nist.gov>
Date: = Wednesday, February 13, 2013 7:16 AM
To: "Stoecker, = Paul" <Paul.Stoecker@rsa.com>, Kathleen Moriarty = <kathleen.moriarty@emc.com>, Brian = Trammell <trammell@tik.ee.ethz.ch>
Cc: = "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, MILE IETF <mile@ietf.org>
Subject: Re: [mile] = IOCs

 

Paul,

 

I = agree that confidence is subjective, but subjectivity can be = reduced

within communities = that interact frequently.  Prioritization of = indicators

and response = between tightly connected sharing partners might require = a

more specific level of = detail, particularly during a crisis = situation.

 

From that perspective, I think the guidance should = allow for additional

granularity, while stressing the "high, medium, = low" as preferred for

broad interoperability.

 

-John

 

On 2/13/13 8:04 AM, "Stoecker, Paul" <Paul.Stoecker@rsa.com> = wrote:

 

I may have been too succinct in my response = ;-)

 

Confidence is a subjective thing, so I think we should = use subjective

terms:  Low, Medium, High.  Having = a numeric scale with a map that

essentially would say something = like:

 

1-33 =3D Low

34-67=3D Medium

68-100=3DHigh

 

Is just a more complicated way of saying that = something is Low, Medium,

High...do we really thing that how High something is = makes that much of a

difference?

 

This is like when you get your Performance review = where it is Does Not

Meet, = Meets and Exceeds...your boss tells you that you are a = High

Meets...your

bonus tells you that you got the same bonus that all = the other Meets got

;-)

 

Anyway, I digress but trying to prove a point that I = would argue that

confidence in this case is going to be basically a gut = feeling, so why use

numeric values when Low, Medium, High would do just = fine.

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

 

 

 

 

 

On 2/13/13 7:48 AM, "Moriarty, Kathleen" = <kathleen.moriarty@emc.com>

<= div>

wrote:

 

Hello,

 

Both approaches will validate in the current = schema.  The representation

looks a little different for each, here is an = example:

 

<Confidence = rating=3D"low"/>

 

Vs:

 

<Confidence = rating=3D"numeric">85</>

 

Searching capability is a great point, = agreed.  I'd like to hear from

more people to make sure we don't lose a capability = that others find

extremely = useful (need to gauge that).  Other options is that = the

guidance can also = discourage the use of the numeric in addition = to

specifying how to = select ranges.

 

Any other opinions?

 

Thanks,

Kathleen

 

-----Original Message-----

From: Stoecker, Paul

Sent: Wednesday, February 13, 2013 7:14 = AM

To: Brian = Trammell

Cc: Moriarty, = Kathleen; C. Henry Adams & BIE; MILE = IETF

Subject: Re: [mile] = IOCs

 

Cant we make Confidence a List that has only 3 = values:  High, Medium, and

Low?  Any other value means that the = Document will mot validate against

the schema.

 

Sent from my iPhone

 

On Feb 13, 2013, at 2:14 AM, "Brian = Trammell" <trammell@tik.ee.ethz.ch>

wrote:

 

Hi, Kathleen, all,

 

I = think 3.10.4 in 5070 takes the right approach here: trying to = build

interoperable = numeric scales for assessment is a very hard = problem.

(Were I charged = with defining such a scale, the value "70" would = mean

"we compared = this incident report to N past similar incident = reports

according to = similarity algorithm S, and 70% of the past reports = had

assessed impacts = within E% of the actual, measured final impact -- = I

think for most = applications this is vastly more difficult and = rigorous

than it needs to = be.)

 

Unless a numeric Confidence value is based on some = actual, repeatably

measurable aspect of the Assessment report -- which I = suspect in

many/most/all = cases it's not -- then it just represents a guess, = however

educated.  Each team will probably naturally = tune its own scales such

that each value generally means the same thing in each = report. Across

teams, I = don't know.

 

On the other hand, Assessments are by their very = nature educated

guesses, = anyway, so I don't know that I'd find much use in automating = a

response based on the = assessment confidence. Chris has a good = point,

though -- it makes = searching difficult and sorting kind of = pointless.

 

If we've seen a general trend toward "0 =3D 0%, = 100 =3D 100%", then I

agree, we should put that in the guidance document = (along with a note

that = 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to = high,

unless we want to do = it non-linearly). If the _vast_majority_ of = the

users of this field = use a 100-point scale with 100 meaning "yes" and = 0

meaning "any = resemblance these values may have to actual fact is = purely

coincidental", = then let's consider renaming it "percent" in = 5070-bis.

 

Best regards,

 

Brian (as contributor)

 

 

On Feb 12, 2013, at 9:56 PM, "Moriarty, = Kathleen"

 

Please see section 3.10.4 of RFC5070 as a starting = point.  We can

change it if it needs to be changed.  The = value is for a confidence

rating on the indicators shared.  The = definitions may be helpful for

anyone who wants to work on this = discussion.  IODEF has various = markers

that can be used = in a complimentary way without conflating the = markers

meaning.

 

I = think some people using IODEF find the numerical values = more

helpful, and it would = be good to understand what people have = learned

from using the = current structure (what works/does not = work).  The

scales I have seen are 0-100.  There is of = course a subjective element

to assigning a numerical value to the confidence and = it may vary from

entity to = entity.  With this type of rating you may need to = consider

who it came from = and how they scored the confidence rating to map = to

your own = rating.  It would be good to hear more thoughts on = this.

 

Thanks,

Kathleen

 

From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com]

<= div>

Sent: Tuesday, February 12, 2013 2:46 = PM

To: MILE = IETF

Cc: Moriarty, = Kathleen; 'Takeshi Takahashi'; Stoecker, = Paul

Subject: Re: [mile] = IOCs

 

 

Regarding the IOCs or Indicators of Compromise, Chris = made a vital

point.  Different Confidence levels will = cause confusion.  It appears

that there maybe a need for some type of simplified = standardization to

be = established between all Sharing Groups in this = regard.

 

Perhaps numerical scoring set at lower values should = express levels of

urgency.

( i.e.  1 =3D Less Likely,   2 =3D = Probable,  3 =3D A Concern,  4 = =3D  Urgent,

5 = =3D Imminent )

 

Thanks,

C. Henry Adams

 

 

 

I = see some confusion coming down the pike if we start using = Confidence

the

way = it is supported. If I am using low/med/high and someone sends = me

an = IoC

with a score of 70, = what does that mean to me? What if I am using = a

scale = of

1 to 4 and someone else = is on a scale of 1 to 5? We lose the ability

to

describe something with a consistent language. It = really gets ugly

when = we

store IoC from multiple = sources. I have confidence values that are

numeric

as well as text.  Makes searching / sorting = very problematic.

 

At this point we have to roll with what we have. I = would strongly

recommend

that we revisit this at some = point.

 

Thanks,

 

--Chris

 

-----Original Message-----

From: Moriarty, Kathleen

Sent: Tuesday, February 12, 2013 9:59 = AM

To: Harrington, = Christopher; 'Takeshi Takahashi'; Stoecker, = Paul;

'MILE

IETF'

Subject: RE: [mile] IOCs

 

Hi Chris & Take,

 

I'll just focus on the confidence = scoring.  Right now, the schema

allows for

you to either use a numerical score OR the ratings of = low, medium, and

high.

Different sharing groups can decide how they want to = share the data.

If

people were to use the numerical values, I agree it = would be helpful

to = have

guidance.  This could go in the IODE = guidance document.

 

I = have seen examples of current users that use each of the = approaches,

so

we'll = need to keep the option for backwards compatibility and it = is

nice = to

keep in flexible = options where we can.

 

Thank you,

Kathleen

 

-----Original Message-----

From: Harrington, = Christopher

Sent: Tuesday, = February 12, 2013 9:22 AM

To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, = Paul; 'MILE

IETF'

Subject: RE: [mile] IOCs

 

The number of indicators wouldn't necessarily drive = the use of

indicator_set_id. The purpose is to show relationship. = If I sent 3 IP

addresses = that were used as C2 for 3 different campaigns I would = have

separate = indicator_set_ids, each with one of the 3 C2 = IPs

 

My suggestion would be a simple low, medium, high. I = think if we break

it

down = to more levels than that we would need to provide guidance = on

scoring,

rating, etc. I think most people should be able to = understand

low/med/high

without having to have a mathematical method for = arriving at the

level.

 

Low - I am not sure

Medium - I am reasonably = sure

High - I am very = sure

 

 

Thanks,

 

--Chris

 

-----Original Message-----

From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]

=

Sent: Tuesday, February 12, 2013 4:21 = AM

To: Harrington, = Christopher; Moriarty, Kathleen; Stoecker, Paul; = 'MILE

IETF'

Subject: RE: [mile] IOCs

 

Regarding the indicator_set_id, I agree, it is useful = when we need to

deal

with large sets of = indicators.

Since = indicator_set_id attribute is optional (right?), it could = be

omitted

if we need to deal with only small number of = indicators.

 

Regarding the use case, I like the idea of using the = confidence

attribute

for the reason Chris kindly = described.

I would like to = hear a bit more on this: is it going to be = numerical?

For

instance, 1 means "no confidence" while 5 = means "strong confidence",

etc?

 

Thank you.

Take

 

 

-----Original Message-----

From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]

Sent: Friday, February 08, 2013 4:11 = AM

To: Moriarty, Kathleen; = Takeshi Takahashi; Stoecker, Paul; 'MILE

IETF'

Subject: RE: [mile] IOCs

 

With respect to tying things back to threat actors, = from what I have

seen and = use this is a generally accepted grouping:

 

Indicator --> Indictor Set --> Campaign --> = Threat Actor

 

Campaign and Threat Actor are where having a = "Confidence" attribute

would be beneficial as making those associations is = not a perfect

science by = any means.

 

Thanks,

 

--Chris

 

 

-----Original Message-----

From: Moriarty, Kathleen

Sent: Thursday, February 07, 2013 2:00 = PM

To: Takeshi Takahashi; = Harrington, Christopher; Stoecker, Paul; = 'MILE

IETF'

Subject: RE: [mile] IOCs

 

Hi Take & others,

 

Thanks for chiming in, I've been talking about this = with Chris and a

few = others on their use cases and would like more = opinions.  I'll

provide an option below from what we have discussed = from a CIRC view

point.  We are also wondering how to also = provide logic in IODEF that

could cross over into SCI attached schemas or IODEF = extensions (the

solutions = may all tie together with this discussion - or there may = be

better/more elegant = solutions others would like to propose).

 

-----Original Message-----

From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]

=

Sent: Tuesday, February 05, 2013 12:04 = PM

To: Harrington, = Christopher; Stoecker, Paul; Moriarty, = Kathleen;

'MILE

IETF'

Subject: RE: [mile] IOCs

 

I like this discussion.

I agree, it would be good idea to have indicator = identifiers inside

the = IOC-related classes.

 

KMM: At the class level, we may have several = indicators listed that

should be viewed as a set and may have another = instance of that same

class that is a related issue, but a separate = set.  We could as you

say, list the indicator IDs connected through the = reference class.

The set = IDs might give us other ways to group the values when we = get

into logic and = relationships between sets or indicators.  This = could

also be a way to = connect indicators or sets across XML documents = that

could have been = shared previously.  If there are a large number = of

indicators in the set, = then this becomes useful, for smaller sets, = I

agree it doesn't make as = much sense.

 

What do others think?

 

Then for indicators not included in the base schema = that may not

fit into a = category in the SCI draft, do we create a place = for

these off of SCI or = right off of the IODE schema in EventData?

(more = details

on

this in my first = message).

 

If we could see any indicator of compromise as = computer event

record, we = could use SCI:EventReport class as the place for = the

XML-based IOCs that = couldn't fit anywhere else.

 

KMM: That sounds like a good idea to = me.  This should go into

guidance

in the SCI draft.  Does anyone else want to = weigh in?

 

 

For the non-XML IOCs, we could use RecordData class, = as suggested.

KMM: Sounds good, thanks!

 

I agree to have indicator_uid, but I am not sure about = the needs of

the = indicator_set_id.

I = understand we could do some grouping of individual = indicator_uids

and its = usability, but I am not sure whether we do not have = any

other way to express = these groupings.

For = instance,  a Reference class refers to several = indicadtor_uids.

In

this case, they could be, in a sense, grouped. Isn't = it enough?

 

KMM: It may be, what do you think about large sets of = indicators or

subsequent = messages that add indicators to existing sets?  Would = this

happen?  Would it be easier to express = relationships with sets of

indicators in addition to individual = indicators?  By using this, it

could give us a unique way to also provide the logic = and

relationships

in a new class of IODEF so we don't have to worry = about adding it

into

the = current

structure.

If there are better ways to handle that, and others = can provide some

options, = that would be appreciated!

 

Thank you,

Kathleen

 

I would appreciate if anybody could share expertise on = this. Though

I

think I have read all the emails in the list, I might = have

mis-understood some = points.

 

By the way, I think the indicator_uids should be added = to the SCI

classes'

attributes so that they can be correlated with another = information

as

well.

 

Thanks

Take

 

 

 

Of Harrington, = Christopher

Sent: Tuesday, = February 05, 2013 4:25 AM

To: Stoecker, Paul; Moriarty, Kathleen; MILE = IETF

Subject: Re: [mile] = IOCs

 

I = think some sort of group ID would do the trick. We also need = a

logical and / or = somewhere to show relationship between = indicators.

If

I = give you

2

registry keys do they both have to be present to be an = indication of

compromise = or is either one by themselves an indicator? Both = would

have the same group = ID since they are related.

 

Thanks,

--Chris

 

From: Stoecker, Paul

Sent: Sunday, February 03, 2013 8:26 = PM

To: Moriarty, Kathleen; = Harrington, Christopher; MILE IETF

Subject: Re: [mile] IOCs

 

What if we added indicator group ID along with the = indicator_uid?

This would = allow you to group indicators that are related into = the

same group = ID.

Would this resolve the = issue?

 

It is either that or going back to adding a Detection = (or Indicators)

class that = will should be used to take all of the indicators put = them

into one place and = have the ability to group the ones that go

together.  I don't mean a place to put = indicators that are missing

from IODEF.I mean a place in the IODEF document where = you put the

indicators = that are used for detection and prevention of the = shared

Incident.  I don't know the answer here, but = there has got to be a

good = way for indicators to be identified and being able to group = them

as Chris has = suggested without basically recreating = something

complicated like = STIX.

 

Paul

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

 

From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>

<= div>

Date: Sunday, February 3, 2013 5:11 = PM

To: "Harrington, = Christopher" <Christopher.Harrington@emc.com>, = MILE

Subject: Re: [mile] IOCs

 

Hi Chris,

 

I = agree, we have some work to do in the updated IODEF, = RFC5070-bis.

 

The list has already said they would like to see = indicators added to

the = definitions in RFC5070-bis, to be more explicit about = including

indicators and = sets of indicators in IODE documents as opposed = to

'parts of an incident = or the useful information on an incident for

sharing purposes.  It was written before we = used terms like

indicators.  With that in mind, Rosella = proposed a number of changes

back in July, both for guidance and = for

format

updates.  It may help to have the first = draft try to address at least

some of these issues so people can understand the = problems and at

least a = proposed solution.

 

As you point out, we need to be able to show = relationships between

sets = of indicators, where we may have a few sets of indicators = that

could have a = relationship to each other within a document.  In = the

July presentation, one = of the questions was to see if we should add

new category attribute values for the System class = that would connect

the = list of included indicators.  I think we should still keep = the

concept of a Node to a = single node, but perhaps within System, list

multiple sets of Nodes that may be one type of = attack.  Rosella had

suggested pulling forward the "FraudType" = from RFC5901, this would

help solve the issue as NodeRole values would = compliment an

AttackType

(FraudType values could be included in AttackType or = some broader

term).  It may be better to have the = FraudTypes, plus attribute

values

like "C2-server", = "sinkhole",  "MalwareDistribution" for = added

context

so you know what to do with the received set of = indicators.

 

I = am proposing that we change IODEF to include multiple sets = of

indicators,

add an AttackType attribute (or some other name), a = method to connect

indicators and indicator sets within an IODEF using an = attribute of

indicator_uid = (or some other name) with a string value to make = the

connection points, and = add a few indicators that are commonly = shared

into the base = IODEF.

 

Back in July, we talked about adding Registry = Key/Value pairs and

hashes = to the main IODEF document (trying to see if this will = help

Chris = below).  What if we added the Registry Key/Value pairs as = a

class off of RecordData, = using a similar structure to what is in

RFC5901, and also added the ability to include hashes = in RecordData?

I think if = we then had the indicator_uid at the RecordData level, = we

could connect a set = within that structure and repeat the = structure

for

other sets in the same way we would do with Node = inside of the System

class, using the indicator_uid to tie the set = together.  Then at the

more specific level for the hash, registry Key/value, = IP, etc. use an

indicator_uid if we needed them marked at this level = as well?  Maybe

we want indicator_set at the higher = level?  I'd like some opinions on

this approach.  +1 if you agree, suggestions = if you have other ideas

that may work better.

 

We'll also need to worry about marking the indicators = to prevent

forward sharing = when not permitted.  We may want to use these = values

or something = else.

 

Thank you!

Kathleen

 

From: Harrington, = Christopher

Sent: Friday, = February 01, 2013 12:01 PM

To: Moriarty, Kathleen; MILE = IETF

Subject: RE: [mile] = IOCs

 

I = think we have a bigger relationship issue to address. Let use = the

Watchlist Use Case. A = bunch of indicators are sent in one message. = In

that message we could = have groupings of indicators that we need to

show are

related:

 

Two or more indicators of different type that relate = to the same

threat:

       The file hash of = a malicious file and the URL of the C2 that

the file uses. Either or both may be present to = indicate a

compromise.

 

Two or more indicators of the same type that relate to = the same

threat:

       2 different = registry values for the same registry key. = If

either value is present = it is a compromise indicator but both will

not

be

present.

 

The problem compounds itself very quickly. Consider = the scenario

where

both groupings above are part of the same threat. I = need to show that

logical = groupings of Indicators are related as well. We can't = send

multiple IODEF = messages for this from what I remember = reading.

 

The last one I can think of would be when you have 2 = different

indicators that = represent the same indicator. It's not uncommon = to

send both = the

MD5

and = SHA1 hash of a malicious file. The indicator is the file but = the

IOCs are the 2 hash = values. How do we show they are related? If = we

use

a = unique Inidcator ID for each hash value there needs to be a = higher

level

grouping.

 

Thoughts?

 

Thanks,

 

--Chris

 

Christopher Harrington

Consulting Security = Engineer

GSO - Critical = Incident Response Center EMC - Where Information = Lives

174 Middlesex = Turnpike

Bedford, MA = 01730

781-515-5862 = (work)

603-583-1585 = (cell)

 

Of Moriarty, = Kathleen

Sent: Friday, = February 01, 2013 11:28 AM

To: MILE IETF

Subject: Re: [mile] IOCs

 

All -

 

I'd like your input and will refocus the thread to get = opinions from

the list on = options to help solve the problems raised in my = message

and additionally = in Paul's message.

 

Interesting point, C. Henry.  Our objective = here is to have machine

automated exchanges, so we rely on encryption rather = than obfuscation

to = achieve the necessary level of = confidentiality.

 

Paul mentioned the need to distinguish indicators of = compromise from

context = information that may also include IP address or other = data

that could be = indicators.  The question I raised was on how = to

connect

sets of indicators in the same IODEF document, = assuming the ability

to

have = watchlists that could have several sets of indicators = included,

as well as to = connect indicators that may be included in = embedded

schemas.

 

If we add an attribute on all of the relevant = indicators, let's say

'indicator-uid' how do we mark the = indicators?  Do we use this to

mark

who = sent the indicator as well so that we can prevent forward = sharing

when it is not = permitted or handle that separately?

 

Then for indicators not included in the base schema = that may not fit

into a = category in the SCI draft, do we create a place for these = off

of SCI or right off of = the IODE schema in EventData? (more details = on

this in my first = message).

 

Comments and questions encouraged to figure out the = right technical

solution = to have this machine automatable.

 

Thank you,

Kathleen

 

Of = C.

Henry Adams & = BIE

Sent: Monday, January = 28, 2013 11:25 PM

To: MILE = IETF

Subject: Re: [mile] = IOCs

 

Temporal Dependency sounds interesting.  I = remember when I first ran

across this particular craft, an experienced colleague = asked me a

peculiar = question.  He said, " How do you stop someone from = tracking

the IP Address to = your computer?"

 

I = replied, "I don't know, how?"

 

Then he said, "Cut the dog-gone thing = off  and the modem that it is

connected- which is constantly on!"   = LOL

 

Here's my point (Hypothetical Situation) = :  There is a 1st Responder

searching a Neighborhood for Survivors which were hit = by a Disaster

or

let's = just say "Live" Terrorist Situation.  He /or She = needs to

communication = back to other Officials that he /or somehow is = in

Danger.  The = device used to communicate has been captured by = the

great

minds of the enemy.  It's only a matter of = time before they utilize

reverse engineering to figure out how it = functions.  However, their

pride comes before a fall when seeking the location of = other similar

devices to = attack.  Why? Perhaps the less thought of concepts = that

makes the device = function properly, saves the day by disguise = or

cutting it off = (figuratively speaking).

 

Just a visionary thought.

 

C. Henry Adams

<= div>

http://biemediagroup.com

<= p class=3DMsoNormal> 

 

The information contained herein is for the exclusive = use of the

original = recipient. This information is granted for = limited

distribution = within the recipient's place of business for = planning

purposes only. = Further dissemination, whether private or public = is

prohibited.

 

--- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> = wrote:

 

From: Dave Misell <david.misell@bcs.org>

<= p class=3DMsoNormal>Subject: Re: [mile] IOCs

To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>

=

Date: Monday, January 28, 2013, 9:25 PM UID could = be mirrored with

DNS

SEC = a pemanent and temporal key, with a temporal = Id?

 

Yours Faithfully,

 

Dave Misell MSc CISSP

SilentCircle  dsm

07710 380044

 

 

On 29 Jan 2013, at 00:39, C. Henry Adams & = BIE

=

wrote:

 

Serialization of a particular Lists of XML Classes in = a unique way

was

closely related to what I attempted to express when I = stated,

"consider to = a degree what appears to be illogical in brilliant = minds

in some = instances."

 

However, I see Dr. Stoecker's point a little = clearer.  However, it

would

be nice if the UID was in some way disguised from = those who study

this

Security Art Form in a negative = way.

 

C. Henry Adams

<= div>

 

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

 

Re: [mile] IOCs

 

Sunday, January 27, 2013 8:52 = PM

From:

"Stoecker, Paul" <Paul.Stoecker@rsa.com>

=

To:

I would like to look at this from a slightly = different

perspective=C5=A0let's say I get an XML document that = tells me about an

incident.  This document has source IP and = destination IP that is

being shared.  However, what I don't know is = which IP address is my

indicator and which is just a contextual piece of = information.  This

means that my detection product isn't going to know = which one to use

either, = because there is nothing to tell me which IP is the = one,

even

if = the roles are set it still might not be enough to tell my = system

which

one I should use as the = indicator.

 

If we had something like indicator_id as an attribute, = it would

allow

us = to easily identify indicators from contextual data.  I do = admit

to

being = biased as I have spent much of my career working on = the

monitoring and = detection side of these things, so I am just = thinking

of ways to make = it very clear what the indicators are in the = XML

document and the other = data that may be important as I investigate

activity that I have detected off of those = indicators.

 

 

I = did suggest the detection class, but I think we may get = more

flexibility with the = indicator_uid.  One thing that I = haven't

considered is the = UID portion of this=C5=A0how do we use that = UID?  How

is

the = UID created?  Are there standards for = UIDs?

 

Regards,

 

Paul

 

 

 

Paul W. Stoecker, Ph.D.

SMC Lead Content Architect

RSA, The Security Division of = EMC

cell: 302.379.3375 | = e: paul.stoecker@rsa.com

 

--- On Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@yahoo.com>

=

wrote:

 

From: C. Henry Adams & BIE <chatlga2000@yahoo.com>

=

Subject: RE: [mile] = IOCs

To: = "KathleenMoriarty" <kathleen.moriarty@emc.com>

<= div>

Cc: mile@ietf.org

Date: Saturday, January 26, 2013, 6:17 = PM

 

Greetings Kathleen,

 

Your logic stimulates my visionary brain because I'm = amazed at the

many

avenues you review with this approach at = once.  However,  could = you

share

a

few = advantages and disadvantages to the latter?

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

--------

----------------------------------------------

"we could continue to group items in logical = places as is done now

in

IODEF and then have the extension point for combined = indicators via

SCI."

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

--------

---------------------------------------------

 

You pointed out what you consider to be logical = places, but if I

wanted = to

protect = information from parties capable of ascertaining it from = your

logical places, = perhaps we should also consider to a degree = what

appears

to

be = illogical in brilliant minds in some = instances.

 

 

 

C. Henry Adams

chatlga2000@yahoo.com (Direct = Email)

<= div>

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

 

--- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.com>

<= /blockquote>

wrote:

 

From: Moriarty, Kathleen <kathleen.moriarty@emc.com>

<= div>

Subject: RE: [mile] = IOCs

To: "C. Henry = Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org"

Date: Saturday, January 26, 2013, 10:13 = AM

 

Hello C. Henry & = others,

 

Thanks for taking a look at this.  We have a = few considerations in

this

email thread I would like to hear thoughts on (and = there may be more

once

RFC5070-bis is actively = edited).

 

The AdditionalData class and the RecordItem class both = allow for

non-XML

extensions.  Where you place the extensions = should be specific to the

logical grouping of the parent elements so you can = understand more

about

the

included data in most = cases.

 

The Impact class can be used to provide context = information on the

included data of the report and also can include a = confidence rating

on

the

report as a whole.  Extensions related to = impact would be one level

higher

(at the moment) in the Assessment class using the = AdditionalData

extension

point.

 

Take asked about including vulnerability information, = I would think

that

would fit under the Vulnerability extension point of = the SCI draft in

the

Method class.  He did ask about = non-XML.  RecordItem or

AdditionalData

do

allow = for non-XML extension points, we could either have the = SCI

draft

handle these as well or have the extensions that are = non-XML come

directly

off the AdditionalData or RecordItem classes according = to what makes

sense

from a logical = standpoint.

 

As for my question, it was = two-fold.

 

Indicator based schemas have a reference number or a = GUID for the

various

indicators they share.  If we are extending = to embed other schemas

that

include such reference or GUID identifiers, do we want = to add an

attribute

to the various elements in IODEF that could be = indicators?  Is this

enough

to make the connections or is something else else = needed?  We could

add

something like an Indicator_ID in RFC5070-bis which = would then

correlate

to

the = reference or GUID identifiers.

 

Then the other question was on how to include = indicators that are

not

in

the base schema that may be related or have language = with "and" "or"

to

specify the relationships.  In some cases, = you will want to group

these

indictors in one extension point, where they may fit = logically in

multiple

places if the relationships did not need to be shown = in the data

format.  If

we have cases like this where you need more complex = representations,

should

we use one extension point via the SCI draft off of = the EventData

class

AdditionalData extension point?  Opinions = are needed here....

 

A = few people have mentioned wanting to include some commonly = shared

indictors into the base IODEF document.  We = could have a catch-all

class

that does this and has an extension point off of it in = EventData or

we

could

continue to group items in logical places as is done = now in IODEF and

then

have the extension point for combined indicators via = SCI.  I think I

like

the = latter approach.

 

Thank you,

Kathleen

________________________________________

=

Henry

Adams & BIE [chatlga2000@yahoo.com]

Sent: Saturday, January 26, 2013 3:05 = AM

Cc: C. Henry Adams

Subject: Re: [mile] IOCs

 

Greetings Everyone,

 

Take mentioned two types of indicators based on the = :

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

--------

--------------------------

1) If the indicators are something like an XML-based = alert/warning

of

information leakage, it could be an event that are = conveyed in the

SCI's = EventReport class, IMHO.

 

2) If the indicators are something like an non-XML = ones, I guess it

could

be

conveyed without using SCI = draft.

For instance, we = could use Impact class of the base IODEF to = convey

the = indicators.

We could for = instance extend the list of indicators of the = Impact

class,

if

needed.

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

--------

--------------------------

 

In doing so he pointed out the "Impact = Class"

 

Whereas, Kathleen = stated,

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

--------

-------------------------

For the discussion below, I was thinking more of = combined set with

relationships that may be included in a single = extension point, so

that's

why I was thinking about the EventData class, but = there may be better

locations or a specific area within the = EventData.

 

Paul Stoecker had suggested a "Detection" = class as a consideration.

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

--------

------------------------

 

Kathleen thoughts related yet still with other = indicators and the

EventData Class.

 

Is there a possible way to create a new XML class = which encompass

combining the EventData, Detection and base IODEF = classes to simplify

this

issue?

 

 

C. Henry Adams

chatlga2000@yahoo.com (Direct = Email)

<= div>

 

 

The information contained herein is for the exclusive = use of the

original

recipient. This information is granted for limited = distribution

within

the

recipient's place of business for planning purposes = only. Further

dissemination, whether private or public is = prohibited.

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 

 

_______________________________________________

mile mailing = list

 

_______________________________________________

mile mailing = list

 =

------=_NextPart_001_0085_01CE09F3.8A8BBE40-- ------=_NextPart_000_0084_01CE09F3.8A8BBE40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTMx OTA4MDRaMCMGCSqGSIb3DQEJBDEWBBSsRPkreU6wrSvB+sjiXAGUHjDdZTCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAIJk0EShw3NyNV276WR/pAMuJtBhAuFC/beJGnxzf4/O8bYtP4I7xp0xsQ4NveSgX AGHxTLIntEK4sdDaF69JAEa9C2Xhj6FULBYOVS1zAC1HCk5biASHKobzC2oM9a5YwWQxKp063xNe hFgvPiSHulqCEXRVExag7+0BgTVqPd3vNh/2c/c3ty4D0WsTITtlme6AxgykYof2zpidhA3MrRlw 8QlNC3cYQtPOjGrVsYTZnBPySOnPZRhrt66/wP2cNZGjv4wo/TOgC17Vm8TveiYjvQ1hAbkDub9B kjeHE0eYRD/B9AikBbCGFx6cZBASZdjgWfw6vDndAqFcr4AJ/QAAAAAAAA== ------=_NextPart_000_0084_01CE09F3.8A8BBE40-- From johnp.field@emc.com Fri Feb 15 14:59:26 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB921F84E2 for ; Fri, 15 Feb 2013 14:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9RxJlc6j1cL for ; Fri, 15 Feb 2013 14:59:25 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A2AF221F846B for ; Fri, 15 Feb 2013 14:59:25 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1FMxOI5006891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Feb 2013 17:59:24 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 15 Feb 2013 17:59:14 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1FMxC8S009095 for ; Fri, 15 Feb 2013 17:59:12 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 15 Feb 2013 17:59:11 -0500 Received: from mx14a.corp.emc.com ([169.254.1.141]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Fri, 15 Feb 2013 17:59:11 -0500 From: "Field, John" To: "mile@ietf.org" Date: Fri, 15 Feb 2013 17:59:10 -0500 Thread-Topic: New Version Notification for draft-field-mile-rolie-01.txt Thread-Index: Ac4LymFdsjUEBgOtTHyM9ZqkCm3RzwAAfGJA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] FW: New Version Notification for draft-field-mile-rolie-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:59:26 -0000 QWxsLA0KDQpQbGVhc2Ugbm90ZSB0aGF0IEkndmUgcG9zdGVkIGFuIHVwZGF0ZSB0byB0aGlzIGRy YWZ0LCBhbmQgdGhlIG5ldyB2ZXJzaW9uIGlzIG5vdyBhdmFpbGFibGUgaW4gdGhlIHJlcG9zaXRv cnkuICBUaGFuayB5b3UgZm9yIGFsbCB0aGUgcmV2aWV3IGNvbW1lbnRzIEkgaGFkIHJlY2VpdmVk IG9uIHRoZSAtMDAgZHJhZnQuICBJIGJlbGlldmUgdGhhdCBpbnB1dCBoZWxwZWQgdG8gbWFrZSB0 aGlzIHZlcnNpb24gdW5pZm9ybWx5IGJldHRlci4gDQoNCkkndmUgYWRkZWQgYSBuZXcgY2hhbmdl IHRyYWNraW5nIHNlY3Rpb24gaW4gdGhlIGFwcGVuZGl4IHRoYXQgbGlzdHMgdGhlIHNwZWNpZmlj IHVwZGF0ZXMvZGlmZmVyZW5jZXMgdGhhdCBhcHBlYXIgaW4gdGhpcyB2ZXJzaW9uLiAgIEFzIGNh biBiZSBzZWVuIGluIHRoYXQgYXBwZW5kaXgsIHRoaXMgdmVyc2lvbiAtMDEgaXMgYW4gaW5jcmVt ZW50YWwgaW1wcm92ZW1lbnQgb3ZlciB0aGUgLTAwIGRyYWZ0LiAgDQoNCkl0IHNob3VsZCBhbHNv IGJlIG5vdGVkIHRoYXQgYWZ0ZXIgdGhlIGluaXRpYWwgLTAwIGRyYWZ0IHRoZXJlIGhhZCBiZWVu IHNvbWUgY29udmVyc2F0aW9uIG9mIHBvc3NpYmx5IGdlbmVyYWxpemluZyB0aGlzIGZ1cnRoZXIg c28gdGhhdCBpdCB3b3VsZCBub3QgYmUgbGltaXRlZCB0byBmb2N1c2luZyBvbmx5IG9uIE1JTEUg dXNlIGNhc2VzIChpLmUuIGluY2lkZW50cyBhbmQgaW5kaWNhdG9ycywgZXRjLikuICBJdCB3YXMg c3VnZ2VzdGVkIHRoYXQgdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgbWlnaHQg YXBwbHkgdG8gdXNlIGNhc2VzIGJlaW5nIGNvbnNpZGVyZWQgaW4gU0FDTSBhbmQgZWxzZXdoZXJl LiAgSSBkaWQgbm90IHRyeSB0byBhY2NvbW1vZGF0ZSB0aGF0IHN1Z2dlc3Rpb24gaW4gdGhpcyAt MDEsIHNpbXBseSBiZWNhdXNlIEkgZGlkbid0IHRoaW5rIEkgaGFkIHN1ZmZpY2llbnQgdmlzaWJp bGl0eSB0byB0aGUgcmVxdWlyZW1lbnRzIGluIHRob3NlIG90aGVyIGFyZWFzLiAgSG93ZXZlciwg SSByZW1haW4gb3BlbiB0byB0aGF0IHBvc3NpYmlsaXR5IGlmIHRoZXJlIGlzIGEgY29uc2Vuc3Vz IHRvIGRvIHRoYXQsIGFuZCBpZiBvdGhlcnMgY2FuIGhlbHAgY29udHJpYnV0ZSB0aGUgbmVlZGVk IHN1YmplY3QgbWF0dGVyIGV4cGVydGlzZSBmcm9tIHRob3NlIGFyZWFzLiAgT3RoZXJ3aXNlIGl0 IG1heSBtYWtlIHNlbnNlIHRvIGtlZXAgdGhpbmdzIGZvY3VzZWQgb24gb3VyIHNwZWNpZmljIE1J TEUgdXNlIGNhc2VzIGZvciBub3cuDQoNClRoYW5rcywNCkpvaG4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTUsIDIwMTMg NToxNiBQTQ0KVG86IEZpZWxkLCBKb2huDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWZpZWxkLW1pbGUtcm9saWUtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWZpZWxkLW1pbGUtcm9saWUtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEpvaG4gUC4gRmllbGQgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1maWVsZC1taWxlLXJvbGllDQpSZXZpc2lvbjoJ IDAxDQpUaXRsZToJCSBSZXNvdXJjZS1PcmllbnRlZCBMaWdodHdlaWdodCBJbmRpY2F0b3IgRXhj aGFuZ2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTAyLTE1DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNDYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmllbGQtbWlsZS1yb2xpZS0wMS50eHQN ClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aWVsZC1taWxlLXJvbGllDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWZpZWxkLW1pbGUtcm9saWUtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZmllbGQtbWlsZS1yb2xpZS0wMQ0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHJlc291cmNlLW9yaWVudGVkIGFwcHJv YWNoIHRvIGN5YmVyIHNlY3VyaXR5DQogICBpbmZvcm1hdGlvbiBzaGFyaW5nLiAgVXNpbmcgdGhp cyBhcHByb2FjaCwgYSBDU0lSVCBvciBvdGhlcg0KICAgc3Rha2Vob2xkZXIgbWF5IHNoYXJlIGFu ZCBleGNoYW5nZSByZXByZXNlbnRhdGlvbnMgb2YgY3liZXIgc2VjdXJpdHkNCiAgIGluY2lkZW50 cywgaW5kaWNhdG9ycywgYW5kIG90aGVyIHJlbGF0ZWQgaW5mb3JtYXRpb24gYXMgV2ViLQ0KICAg YWRkcmVzc2FibGUgcmVzb3VyY2VzLiAgVGhlIHRyYW5zcG9ydCBwcm90b2NvbCBiaW5kaW5nIGlz IHNwZWNpZmllZA0KICAgYXMgSFRUUChTKSB3aXRoIGEgTUlNRSBtZWRpYSB0eXBlIG9mIEF0b20r WE1MLiAgQW4gYXBwcm9wcmlhdGUgc2V0IG9mDQogICBsaW5rIHJlbGF0aW9uIHR5cGVzIHNwZWNp ZmljIHRvIGN5YmVyIHNlY3VyaXR5IGluZm9ybWF0aW9uIHNoYXJpbmcgaXMNCiAgIGRlZmluZWQu ICBUaGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIGxldmVyYWdlIHRoZSBleGlzdGluZyBJT0RF Rg0KICAgW1JGQzUwNzBdIGFuZCBSSUQgW1JGQzY1NDVdIHNwZWNpZmljYXRpb25zIGFzIGFwcHJv cHJpYXRlLg0KICAgQ29leGlzdGVuY2Ugd2l0aCBkZXBsb3ltZW50cyB0aGF0IGNvbmZvcm0gdG8g ZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMNCiAgIGluY2x1ZGluZyBSSUQgW1JGQzY1NDVdIGFuZCBU cmFuc3BvcnQgb2YgUmVhbC10aW1lIEludGVyLW5ldHdvcmsNCiAgIERlZmVuc2UgKFJJRCkgTWVz c2FnZXMgb3ZlciBIVFRQL1RMUyBbUkZDNjU0Nl0gaXMgc3VwcG9ydGVkIHZpYQ0KICAgYXBwcm9w cmlhdGUgdXNlIG9mIEhUVFAgc3RhdHVzIGNvZGVzLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= From eburger-l@standardstrack.com Sat Feb 16 09:42:45 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4B21F86AF for ; Sat, 16 Feb 2013 09:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.982 X-Spam-Level: X-Spam-Status: No, score=0.982 tagged_above=-999 required=5 tests=[AWL=-3.006, BAYES_50=0.001, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll5xHsP3oNii for ; Sat, 16 Feb 2013 09:42:43 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8121F8678 for ; Sat, 16 Feb 2013 09:42:42 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:59150 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U6lmL-0003KR-3h for mile@ietf.org; Sat, 16 Feb 2013 09:42:25 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Sat, 16 Feb 2013 12:42:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> References: <1360769048.12028.YahooMailClassic@web121606.mail.ne1.yahoo.com> To: MILE IETF X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:42:45 -0000 What is the justification for both numeric and enumerated values = (low/medium/high)? In general such a schema is begging for = interoperability problems. I suppose I can understand both sides of the argument. On the We Need = Numbers side is those that actually calculate a percentage or other = objective measure in the confidence may want to use those real numbers. = As well, on the We Need Numbers side is the argument that three = enumerated values may not prove sufficient in the future. On the We Need = Enumerated Values side is confidence, other than 0% and 100%, tend to be = arbitrary guesses. Putting a number on this value imparts a level of = specificity that does not exist. Also, it is a lot easier to map 'low' = to 'low' than it is to map 0-33 to 'low'. On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" = wrote: > That will work provided I (and everyone else) has a mapping for the = numbers. I would prefer a simple low/med/high scheme. The more we add = the more you have to be able to differentiate between them. However for = potential interoperability I do see the benefit of the 5. > =20 > Thanks, >=20 > --Chris > =20 > From: Moriarty, Kathleen=20 > Sent: Wednesday, February 13, 2013 2:05 PM > To: Harrington, Christopher; MILE IETF > Subject: RE: [mile] IOCs > =20 > =20 > If you think of IODEF just for transport, could you meet your needs = with storing the values differently in a database (IODEF is just meant = for the exchange)? The numbers map to low/med/high =96 for db storage =96= if numbers are used, you could store the equivalent value, adding the 2 = additional ones provided. > =20 > Does it make sense to expand the set of values to match what CIF is = doing if we went forward with the approach of supporting both options? > =20 > Thank you, > Kathleen > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Harrington, Christopher > Sent: Wednesday, February 13, 2013 11:49 AM > To: 'C. Henry Adams & BIE'; MILE IETF > Subject: Re: [mile] IOCs > =20 > =46rom a data processing standpoint it is going to create extra work = for the people who are going to receive this data if we support both = numeric and alpha characters in the same field. I can envision people = wanting to search, sort, store, etc the data in this field. If we allow = both data types then everyone will need to have a mapping of some sort. = I have a field for confidence in my threat tracking database. Having = both a numeric score and alpha characters / words creates issues when = trying to interact with the data. I agree that we need to support both = however I don=92t think both should be in the same field. I would much = rather see 2 different fields for Confidence if we are going to support = 2 different data types. > =20 > This will be a larger issue should Confidence be used elsewhere. = Ideally in future revisions I would like to see attribution expressed as = some form of attribution is almost always shared with an IoC. = Currently there are 5 areas where we (EMC) uses confidence. > =20 > Indicator (how confident are you that this is a valid IoC) > Indicator_Set (how confident are you that all of the indcators in the = set should be in the set) > Campaign (how confident are you that all Indicator_Sets are part of = this campaign) > Threat Actor (how confident are you that the Campaign is attributed to = this Threat Actor) > Threat Actor type (how confident are you that this Theat Actor is APT, = Crimeware, other) > =20 > The threat actor name and the threat actor type are usually the first = 2 things that anyone processing IoCs wants to know as they drive = priority. Knowing how sure the sender is that this IoC is APTis a vital = piece of information for us. Sorry to take us a little off the path but = I wanted to show where Confidence could be used. > =20 > Thanks, >=20 > --Chris > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of C. Henry Adams & BIE > Sent: Wednesday, February 13, 2013 10:24 AM > To: MILE IETF > Subject: Re: [mile] IOCs > =20 > Again, I would concur that both a numeric and subjective analysis of = the Confidence Rating needs to be express, but combined in a simplified = schema as such below: >=20 > 1LL .... etc. >=20 > 2P >=20 > 3AC >=20 > 4U >=20 > 5I >=20 > ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, 5 =3D Imminent ) >=20 > Here's my point, perhaps a set of numeric related or associated = definitions can lower the propagation of error regarding the analysis. =20= >=20 > Thanks, > C. Henry Adams >=20 >=20 > I agree that what we really need is both. In most situations a low, = medium and high may be acceptable but there are times when we will want = to show that confidence in a situation is increasing or decreasing. If = we are only looking at a three levels, we cannot express what is needed = to show confidence is trending up on the data being exchanged about the = event. > =20 > Kathleen included the following in a previous message. > =20 > > =20 > Vs: > =20 > 85 > =20 > I really think we need to include both capabilities as John alluded to = since confidence is not a three tiered item but something that is indeed = subjective and we need a means to show a reasonably accurate confidence = index that the sender is trying to convey. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: , John Banghart > Date: Wednesday, February 13, 2013 7:16 AM > To: "Stoecker, Paul" , Kathleen Moriarty = , Brian Trammell > Cc: "C. Henry Adams & BIE" , MILE IETF = > Subject: Re: [mile] IOCs > =20 > Paul, > =20 > I agree that confidence is subjective, but subjectivity can be reduced > within communities that interact frequently. Prioritization of = indicators > and response between tightly connected sharing partners might require = a > more specific level of detail, particularly during a crisis situation. > =20 > =46rom that perspective, I think the guidance should allow for = additional > granularity, while stressing the "high, medium, low" as preferred for > broad interoperability. > =20 > -John > =20 > On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: > =20 > I may have been too succinct in my response ;-) > =20 > Confidence is a subjective thing, so I think we should use subjective > terms: Low, Medium, High. Having a numeric scale with a map that > essentially would say something like: > =20 > 1-33 =3D Low > 34-67=3D Medium > 68-100=3DHigh > =20 > Is just a more complicated way of saying that something is Low, = Medium, > High...do we really thing that how High something is makes that much = of a > difference? > =20 > This is like when you get your Performance review where it is Does Not > Meet, Meets and Exceeds...your boss tells you that you are a High > Meets...your > bonus tells you that you got the same bonus that all the other Meets = got > ;-) > =20 > Anyway, I digress but trying to prove a point that I would argue that > confidence in this case is going to be basically a gut feeling, so why = use > numeric values when Low, Medium, High would do just fine. > =20 > =20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > =20 > =20 > =20 > =20 > =20 > =20 > On 2/13/13 7:48 AM, "Moriarty, Kathleen" > wrote: > =20 > Hello, > =20 > Both approaches will validate in the current schema. The = representation > looks a little different for each, here is an example: > =20 > > =20 > Vs: > =20 > 85 > =20 > Searching capability is a great point, agreed. I'd like to hear from > more people to make sure we don't lose a capability that others find > extremely useful (need to gauge that). Other options is that the > guidance can also discourage the use of the numeric in addition to > specifying how to select ranges. > =20 > Any other opinions? > =20 > Thanks, > Kathleen > =20 > -----Original Message----- > From: Stoecker, Paul > Sent: Wednesday, February 13, 2013 7:14 AM > To: Brian Trammell > Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF > Subject: Re: [mile] IOCs > =20 > Cant we make Confidence a List that has only 3 values: High, Medium, = and > Low? Any other value means that the Document will mot validate = against > the schema. > =20 > Sent from my iPhone > =20 > On Feb 13, 2013, at 2:14 AM, "Brian Trammell" = > wrote: > =20 > Hi, Kathleen, all, > =20 > I think 3.10.4 in 5070 takes the right approach here: trying to build > interoperable numeric scales for assessment is a very hard problem. > (Were I charged with defining such a scale, the value "70" would mean > "we compared this incident report to N past similar incident reports > according to similarity algorithm S, and 70% of the past reports had > assessed impacts within E% of the actual, measured final impact -- I > think for most applications this is vastly more difficult and rigorous > than it needs to be.) > =20 > Unless a numeric Confidence value is based on some actual, repeatably > measurable aspect of the Assessment report -- which I suspect in > many/most/all cases it's not -- then it just represents a guess, = however > educated. Each team will probably naturally tune its own scales such > that each value generally means the same thing in each report. Across > teams, I don't know. > =20 > On the other hand, Assessments are by their very nature educated > guesses, anyway, so I don't know that I'd find much use in automating = a > response based on the assessment confidence. Chris has a good point, > though -- it makes searching difficult and sorting kind of pointless. > =20 > If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I > agree, we should put that in the guidance document (along with a note > that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, > unless we want to do it non-linearly). If the _vast_majority_ of the > users of this field use a 100-point scale with 100 meaning "yes" and 0 > meaning "any resemblance these values may have to actual fact is = purely > coincidental", then let's consider renaming it "percent" in 5070-bis. > =20 > Best regards, > =20 > Brian (as contributor) > =20 > =20 > On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" > wrote: > =20 > Please see section 3.10.4 of RFC5070 as a starting point. We can > change it if it needs to be changed. The value is for a confidence > rating on the indicators shared. The definitions may be helpful for > anyone who wants to work on this discussion. IODEF has various = markers > that can be used in a complimentary way without conflating the markers > meaning. > =20 > I think some people using IODEF find the numerical values more > helpful, and it would be good to understand what people have learned > from using the current structure (what works/does not work). The > scales I have seen are 0-100. There is of course a subjective element > to assigning a numerical value to the confidence and it may vary from > entity to entity. With this type of rating you may need to consider > who it came from and how they scored the confidence rating to map to > your own rating. It would be good to hear more thoughts on this. > =20 > Thanks, > Kathleen > =20 > From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] > Sent: Tuesday, February 12, 2013 2:46 PM > To: MILE IETF > Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul > Subject: Re: [mile] IOCs > =20 > =20 > Regarding the IOCs or Indicators of Compromise, Chris made a vital > point. Different Confidence levels will cause confusion. It appears > that there maybe a need for some type of simplified standardization to > be established between all Sharing Groups in this regard. > =20 > Perhaps numerical scoring set at lower values should express levels of > urgency. > ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, > 5 =3D Imminent ) > =20 > Thanks, > C. Henry Adams > =20 > =20 > =20 > I see some confusion coming down the pike if we start using Confidence > the > way it is supported. If I am using low/med/high and someone sends me > an IoC > with a score of 70, what does that mean to me? What if I am using a > scale of > 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability > to > describe something with a consistent language. It really gets ugly > when we > store IoC from multiple sources. I have confidence values that are > numeric > as well as text. Makes searching / sorting very problematic. > =20 > At this point we have to roll with what we have. I would strongly > recommend > that we revisit this at some point. > =20 > Thanks, > =20 > --Chris > =20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Tuesday, February 12, 2013 9:59 AM > To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; > 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > Hi Chris & Take, > =20 > I'll just focus on the confidence scoring. Right now, the schema > allows for > you to either use a numerical score OR the ratings of low, medium, and > high. > Different sharing groups can decide how they want to share the data. > If > people were to use the numerical values, I agree it would be helpful > to have > guidance. This could go in the IODE guidance document. > =20 > I have seen examples of current users that use each of the approaches, > so > we'll need to keep the option for backwards compatibility and it is > nice to > keep in flexible options where we can. > =20 > Thank you, > Kathleen > =20 > -----Original Message----- > From: Harrington, Christopher > Sent: Tuesday, February 12, 2013 9:22 AM > To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > The number of indicators wouldn't necessarily drive the use of > indicator_set_id. The purpose is to show relationship. If I sent 3 IP > addresses that were used as C2 for 3 different campaigns I would have > separate indicator_set_ids, each with one of the 3 C2 IPs > =20 > My suggestion would be a simple low, medium, high. I think if we break > it > down to more levels than that we would need to provide guidance on > scoring, > rating, etc. I think most people should be able to understand > low/med/high > without having to have a mathematical method for arriving at the > level. > =20 > Low - I am not sure > Medium - I am reasonably sure > High - I am very sure > =20 > =20 > Thanks, > =20 > --Chris > =20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 12, 2013 4:21 AM > To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > Regarding the indicator_set_id, I agree, it is useful when we need to > deal > with large sets of indicators. > Since indicator_set_id attribute is optional (right?), it could be > omitted > if we need to deal with only small number of indicators. > =20 > Regarding the use case, I like the idea of using the confidence > attribute > for the reason Chris kindly described. > I would like to hear a bit more on this: is it going to be numerical? > For > instance, 1 means "no confidence" while 5 means "strong confidence", > etc? > =20 > Thank you. > Take > =20 > =20 > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Friday, February 08, 2013 4:11 AM > To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > With respect to tying things back to threat actors, from what I have > seen and use this is a generally accepted grouping: > =20 > Indicator --> Indictor Set --> Campaign --> Threat Actor > =20 > Campaign and Threat Actor are where having a "Confidence" attribute > would be beneficial as making those associations is not a perfect > science by any means. > =20 > Thanks, > =20 > --Chris > =20 > =20 > -----Original Message----- > From: Moriarty, Kathleen > Sent: Thursday, February 07, 2013 2:00 PM > To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > Hi Take & others, > =20 > Thanks for chiming in, I've been talking about this with Chris and a > few others on their use cases and would like more opinions. I'll > provide an option below from what we have discussed from a CIRC view > point. We are also wondering how to also provide logic in IODEF that > could cross over into SCI attached schemas or IODEF extensions (the > solutions may all tie together with this discussion - or there may be > better/more elegant solutions others would like to propose). > =20 > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, February 05, 2013 12:04 PM > To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; > 'MILE > IETF' > Subject: RE: [mile] IOCs > =20 > I like this discussion. > I agree, it would be good idea to have indicator identifiers inside > the IOC-related classes. > =20 > KMM: At the class level, we may have several indicators listed that > should be viewed as a set and may have another instance of that same > class that is a related issue, but a separate set. We could as you > say, list the indicator IDs connected through the reference class. > The set IDs might give us other ways to group the values when we get > into logic and relationships between sets or indicators. This could > also be a way to connect indicators or sets across XML documents that > could have been shared previously. If there are a large number of > indicators in the set, then this becomes useful, for smaller sets, I > agree it doesn't make as much sense. > =20 > What do others think? > =20 > Then for indicators not included in the base schema that may not > fit into a category in the SCI draft, do we create a place for > these off of SCI or right off of the IODE schema in EventData? > (more details > on > this in my first message). > =20 > If we could see any indicator of compromise as computer event > record, we could use SCI:EventReport class as the place for the > XML-based IOCs that couldn't fit anywhere else. > =20 > KMM: That sounds like a good idea to me. This should go into > guidance > in the SCI draft. Does anyone else want to weigh in? > =20 > =20 > For the non-XML IOCs, we could use RecordData class, as suggested. > KMM: Sounds good, thanks! > =20 > I agree to have indicator_uid, but I am not sure about the needs of > the indicator_set_id. > I understand we could do some grouping of individual indicator_uids > and its usability, but I am not sure whether we do not have any > other way to express these groupings. > For instance, a Reference class refers to several indicadtor_uids. > In > this case, they could be, in a sense, grouped. Isn't it enough? > =20 > KMM: It may be, what do you think about large sets of indicators or > subsequent messages that add indicators to existing sets? Would this > happen? Would it be easier to express relationships with sets of > indicators in addition to individual indicators? By using this, it > could give us a unique way to also provide the logic and > relationships > in a new class of IODEF so we don't have to worry about adding it > into > the current > structure. > If there are better ways to handle that, and others can provide some > options, that would be appreciated! > =20 > Thank you, > Kathleen > =20 > I would appreciate if anybody could share expertise on this. Though > I > think I have read all the emails in the list, I might have > mis-understood some points. > =20 > By the way, I think the indicator_uids should be added to the SCI > classes' > attributes so that they can be correlated with another information > as > well. > =20 > Thanks > Take > =20 > =20 > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Harrington, Christopher > Sent: Tuesday, February 05, 2013 4:25 AM > To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF > Subject: Re: [mile] IOCs > =20 > I think some sort of group ID would do the trick. We also need a > logical and / or somewhere to show relationship between indicators. > If > I give you > 2 > registry keys do they both have to be present to be an indication of > compromise or is either one by themselves an indicator? Both would > have the same group ID since they are related. > =20 > Thanks, > --Chris > =20 > From: Stoecker, Paul > Sent: Sunday, February 03, 2013 8:26 PM > To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF > Subject: Re: [mile] IOCs > =20 > What if we added indicator group ID along with the indicator_uid? > This would allow you to group indicators that are related into the > same group ID. > Would this resolve the issue? > =20 > It is either that or going back to adding a Detection (or Indicators) > class that will should be used to take all of the indicators put them > into one place and have the ability to group the ones that go > together. I don't mean a place to put indicators that are missing > from IODEF.I mean a place in the IODEF document where you put the > indicators that are used for detection and prevention of the shared > Incident. I don't know the answer here, but there has got to be a > good way for indicators to be identified and being able to group them > as Chris has suggested without basically recreating something > complicated like STIX. > =20 > Paul > =20 > =20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > =20 > =20 > From: , Kathleen > Date: Sunday, February 3, 2013 5:11 PM > To: "Harrington, Christopher" , MILE > IETF > Subject: Re: [mile] IOCs > =20 > Hi Chris, > =20 > I agree, we have some work to do in the updated IODEF, RFC5070-bis. > =20 > The list has already said they would like to see indicators added to > the definitions in RFC5070-bis, to be more explicit about including > indicators and sets of indicators in IODE documents as opposed to > 'parts of an incident or the useful information on an incident for > sharing purposes. It was written before we used terms like > indicators. With that in mind, Rosella proposed a number of changes > back in July, both for guidance and for > format > updates. It may help to have the first draft try to address at least > some of these issues so people can understand the problems and at > least a proposed solution. > =20 > As you point out, we need to be able to show relationships between > sets of indicators, where we may have a few sets of indicators that > could have a relationship to each other within a document. In the > July presentation, one of the questions was to see if we should add > new category attribute values for the System class that would connect > the list of included indicators. I think we should still keep the > concept of a Node to a single node, but perhaps within System, list > multiple sets of Nodes that may be one type of attack. Rosella had > suggested pulling forward the "FraudType" from RFC5901, this would > help solve the issue as NodeRole values would compliment an > AttackType > (FraudType values could be included in AttackType or some broader > term). It may be better to have the FraudTypes, plus attribute > values > like "C2-server", "sinkhole", "MalwareDistribution" for added > context > so you know what to do with the received set of indicators. > =20 > I am proposing that we change IODEF to include multiple sets of > indicators, > add an AttackType attribute (or some other name), a method to connect > indicators and indicator sets within an IODEF using an attribute of > indicator_uid (or some other name) with a string value to make the > connection points, and add a few indicators that are commonly shared > into the base IODEF. > =20 > Back in July, we talked about adding Registry Key/Value pairs and > hashes to the main IODEF document (trying to see if this will help > Chris below). What if we added the Registry Key/Value pairs as a > class off of RecordData, using a similar structure to what is in > RFC5901, and also added the ability to include hashes in RecordData? > I think if we then had the indicator_uid at the RecordData level, we > could connect a set within that structure and repeat the structure > for > other sets in the same way we would do with Node inside of the System > class, using the indicator_uid to tie the set together. Then at the > more specific level for the hash, registry Key/value, IP, etc. use an > indicator_uid if we needed them marked at this level as well? Maybe > we want indicator_set at the higher level? I'd like some opinions on > this approach. +1 if you agree, suggestions if you have other ideas > that may work better. > =20 > We'll also need to worry about marking the indicators to prevent > forward sharing when not permitted. We may want to use these values > or something else. > =20 > Thank you! > Kathleen > =20 > From: Harrington, Christopher > Sent: Friday, February 01, 2013 12:01 PM > To: Moriarty, Kathleen; MILE IETF > Subject: RE: [mile] IOCs > =20 > I think we have a bigger relationship issue to address. Let use the > Watchlist Use Case. A bunch of indicators are sent in one message. In > that message we could have groupings of indicators that we need to > show are > related: > =20 > Two or more indicators of different type that relate to the same > threat: > The file hash of a malicious file and the URL of the C2 that > the file uses. Either or both may be present to indicate a > compromise. > =20 > Two or more indicators of the same type that relate to the same > threat: > 2 different registry values for the same registry key. If > either value is present it is a compromise indicator but both will > not > be > present. > =20 > The problem compounds itself very quickly. Consider the scenario > where > both groupings above are part of the same threat. I need to show that > logical groupings of Indicators are related as well. We can't send > multiple IODEF messages for this from what I remember reading. > =20 > The last one I can think of would be when you have 2 different > indicators that represent the same indicator. It's not uncommon to > send both the > MD5 > and SHA1 hash of a malicious file. The indicator is the file but the > IOCs are the 2 hash values. How do we show they are related? If we > use > a unique Inidcator ID for each hash value there needs to be a higher > level > grouping. > =20 > Thoughts? > =20 > Thanks, > =20 > --Chris > =20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Moriarty, Kathleen > Sent: Friday, February 01, 2013 11:28 AM > To: MILE IETF > Subject: Re: [mile] IOCs > =20 > All - > =20 > I'd like your input and will refocus the thread to get opinions from > the list on options to help solve the problems raised in my message > and additionally in Paul's message. > =20 > Interesting point, C. Henry. Our objective here is to have machine > automated exchanges, so we rely on encryption rather than obfuscation > to achieve the necessary level of confidentiality. > =20 > Paul mentioned the need to distinguish indicators of compromise from > context information that may also include IP address or other data > that could be indicators. The question I raised was on how to > connect > sets of indicators in the same IODEF document, assuming the ability > to > have watchlists that could have several sets of indicators included, > as well as to connect indicators that may be included in embedded > schemas. > =20 > If we add an attribute on all of the relevant indicators, let's say > 'indicator-uid' how do we mark the indicators? Do we use this to > mark > who sent the indicator as well so that we can prevent forward sharing > when it is not permitted or handle that separately? > =20 > Then for indicators not included in the base schema that may not fit > into a category in the SCI draft, do we create a place for these off > of SCI or right off of the IODE schema in EventData? (more details on > this in my first message). > =20 > Comments and questions encouraged to figure out the right technical > solution to have this machine automatable. > =20 > Thank you, > Kathleen > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of C. > Henry Adams & BIE > Sent: Monday, January 28, 2013 11:25 PM > To: MILE IETF > Subject: Re: [mile] IOCs > =20 > Temporal Dependency sounds interesting. I remember when I first ran > across this particular craft, an experienced colleague asked me a > peculiar question. He said, " How do you stop someone from tracking > the IP Address to your computer?" > =20 > I replied, "I don't know, how?" > =20 > Then he said, "Cut the dog-gone thing off and the modem that it is > connected- which is constantly on!" LOL > =20 > Here's my point (Hypothetical Situation) : There is a 1st Responder > searching a Neighborhood for Survivors which were hit by a Disaster > or > let's just say "Live" Terrorist Situation. He /or She needs to > communication back to other Officials that he /or somehow is in > Danger. The device used to communicate has been captured by the > great > minds of the enemy. It's only a matter of time before they utilize > reverse engineering to figure out how it functions. However, their > pride comes before a fall when seeking the location of other similar > devices to attack. Why? Perhaps the less thought of concepts that > makes the device function properly, saves the day by disguise or > cutting it off (figuratively speaking). > =20 > Just a visionary thought. > =20 > C. Henry Adams > chenryadams@biemediagroup.com > http://biemediagroup.com > =20 > =20 > The information contained herein is for the exclusive use of the > original recipient. This information is granted for limited > distribution within the recipient's place of business for planning > purposes only. Further dissemination, whether private or public is > prohibited. > =20 > --- On Mon, 1/28/13, Dave Misell wrote: > =20 > From: Dave Misell > Subject: Re: [mile] IOCs > To: "C. Henry Adams & BIE" > Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with > DNS > SEC a pemanent and temporal key, with a temporal Id? > =20 > Yours Faithfully, > =20 > Dave Misell MSc CISSP > SilentCircle dsm > 07710 380044 > david.misell@bcs.org > =20 > =20 > On 29 Jan 2013, at 00:39, C. Henry Adams & BIE > > wrote: > =20 > Serialization of a particular Lists of XML Classes in a unique way > was > closely related to what I attempted to express when I stated, > "consider to a degree what appears to be illogical in brilliant minds > in some instances." > =20 > However, I see Dr. Stoecker's point a little clearer. However, it > would > be nice if the UID was in some way disguised from those who study > this > Security Art Form in a negative way. > =20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com > =20 > =20 > The information contained herein is for the exclusive use of the > original > recipient. This information is granted for limited distribution > within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > =20 > Re: [mile] IOCs > =20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different > perspective=8Alet's say I get an XML document that tells me about an > incident. This document has source IP and destination IP that is > being shared. However, what I don't know is which IP address is my > indicator and which is just a contextual piece of information. This > means that my detection product isn't going to know which one to use > either, because there is nothing to tell me which IP is the one, > even > if the roles are set it still might not be enough to tell my system > which > one I should use as the indicator. > =20 > If we had something like indicator_id as an attribute, it would > allow > us to easily identify indicators from contextual data. I do admit > to > being biased as I have spent much of my career working on the > monitoring and detection side of these things, so I am just thinking > of ways to make it very clear what the indicators are in the XML > document and the other data that may be important as I investigate > activity that I have detected off of those indicators. > =20 > =20 > I did suggest the detection class, but I think we may get more > flexibility with the indicator_uid. One thing that I haven't > considered is the UID portion of this=8Ahow do we use that UID? How > is > the UID created? Are there standards for UIDs? > =20 > Regards, > =20 > Paul > =20 > =20 > =20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com > =20 > --- On Sat, 1/26/13, C. Henry Adams & BIE > wrote: > =20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM > =20 > Greetings Kathleen, > =20 > Your logic stimulates my visionary brain because I'm amazed at the > many > avenues you review with this approach at once. However, could you > share > a > few advantages and disadvantages to the latter? > -------------------------------------------------------------------- > -------- > ---------------------------------------------- > "we could continue to group items in logical places as is done now > in > IODEF and then have the extension point for combined indicators via > SCI." > -------------------------------------------------------------------- > -------- > --------------------------------------------- > =20 > You pointed out what you consider to be logical places, but if I > wanted to > protect information from parties capable of ascertaining it from your > logical places, perhaps we should also consider to a degree what > appears > to > be illogical in brilliant minds in some instances. > =20 > =20 > =20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com > =20 > The information contained herein is for the exclusive use of the > original > recipient. This information is granted for limited distribution > within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > =20 > --- On Sat, 1/26/13, Moriarty, Kathleen > wrote: > =20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > > Date: Saturday, January 26, 2013, 10:13 AM > =20 > Hello C. Henry & others, > =20 > Thanks for taking a look at this. We have a few considerations in > this > email thread I would like to hear thoughts on (and there may be more > once > RFC5070-bis is actively edited). > =20 > The AdditionalData class and the RecordItem class both allow for > non-XML > extensions. Where you place the extensions should be specific to the > logical grouping of the parent elements so you can understand more > about > the > included data in most cases. > =20 > The Impact class can be used to provide context information on the > included data of the report and also can include a confidence rating > on > the > report as a whole. Extensions related to impact would be one level > higher > (at the moment) in the Assessment class using the AdditionalData > extension > point. > =20 > Take asked about including vulnerability information, I would think > that > would fit under the Vulnerability extension point of the SCI draft in > the > Method class. He did ask about non-XML. RecordItem or > AdditionalData > do > allow for non-XML extension points, we could either have the SCI > draft > handle these as well or have the extensions that are non-XML come > directly > off the AdditionalData or RecordItem classes according to what makes > sense > from a logical standpoint. > =20 > As for my question, it was two-fold. > =20 > Indicator based schemas have a reference number or a GUID for the > various > indicators they share. If we are extending to embed other schemas > that > include such reference or GUID identifiers, do we want to add an > attribute > to the various elements in IODEF that could be indicators? Is this > enough > to make the connections or is something else else needed? We could > add > something like an Indicator_ID in RFC5070-bis which would then > correlate > to > the reference or GUID identifiers. > =20 > Then the other question was on how to include indicators that are > not > in > the base schema that may be related or have language with "and" "or" > to > specify the relationships. In some cases, you will want to group > these > indictors in one extension point, where they may fit logically in > multiple > places if the relationships did not need to be shown in the data > format. If > we have cases like this where you need more complex representations, > should > we use one extension point via the SCI draft off of the EventData > class > AdditionalData extension point? Opinions are needed here.... > =20 > A few people have mentioned wanting to include some commonly shared > indictors into the base IODEF document. We could have a catch-all > class > that does this and has an extension point off of it in EventData or > we > could > continue to group items in logical places as is done now in IODEF and > then > have the extension point for combined indicators via SCI. I think I > like > the latter approach. > =20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. > Henry > Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs > =20 > Greetings Everyone, > =20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------- > -------- > -------------------------- > 1) If the indicators are something like an XML-based alert/warning > of > information leakage, it could be an event that are conveyed in the > SCI's EventReport class, IMHO. > =20 > 2) If the indicators are something like an non-XML ones, I guess it > could > be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey > the indicators. > We could for instance extend the list of indicators of the Impact > class, > if > needed. > -------------------------------------------------------------------- > -------- > -------------------------- > =20 > In doing so he pointed out the "Impact Class" > =20 > Whereas, Kathleen stated, > -------------------------------------------------------------------- > -------- > ------------------------- > For the discussion below, I was thinking more of combined set with > relationships that may be included in a single extension point, so > that's > why I was thinking about the EventData class, but there may be better > locations or a specific area within the EventData. > =20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------- > -------- > ------------------------ > =20 > Kathleen thoughts related yet still with other indicators and the > EventData Class. > =20 > Is there a possible way to create a new XML class which encompass > combining the EventData, Detection and base IODEF classes to simplify > this > issue? > =20 > =20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com > =20 > =20 > The information contained herein is for the exclusive use of the > original > recipient. This information is granted for limited distribution > within > the > recipient's place of business for planning purposes only. Further > dissemination, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > =20 > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > =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 Paul.Stoecker@rsa.com Sat Feb 16 15:33:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9550921F88A3 for ; Sat, 16 Feb 2013 15:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDXQXXnPdB-H for ; Sat, 16 Feb 2013 15:33:08 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 004DC21F8A79 for ; Sat, 16 Feb 2013 15:33:07 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1GNX6bH018141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Feb 2013 18:33:07 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sat, 16 Feb 2013 18:32:52 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1GNWopj015322 for ; Sat, 16 Feb 2013 18:32:52 -0500 Received: from mx33a.corp.emc.com ([169.254.1.215]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Sat, 16 Feb 2013 18:32:50 -0500 From: "Stoecker, Paul" To: "mile@ietf.org" Date: Sat, 16 Feb 2013 18:32:48 -0500 Thread-Topic: New Version Notification for draft-stoecker-danyliw-rfc5070bis-00.txt Thread-Index: Ac4Mne9YlXrBCvoDQxm7v3VaxtvTIQ== Message-ID: In-Reply-To: <20130216232321.8609.72485.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] FW: New Version Notification for draft-stoecker-danyliw-rfc5070bis-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:33:08 -0000 FYI. I finally finished the edits, I think. This is my first time submitting an RFC draft, so be gentle. I am sure I have many mistakes. ;-) There are questions that I left in the schema that need to be answered. I also left in the CHANGE comments that Kathleen put into the schema, so that you can see the changes and check it against the UML. Enjoy!! Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/16/13 6:23 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-stoecker-danyliw-rfc5070bis-00.txt >has been successfully submitted by Paul Stoecker and posted to the >IETF repository. > >Filename: draft-stoecker-danyliw-rfc5070bis >Revision: 00 >Title: The Incident Object Description Exchange Format >Creation date: 2013-02-17 >Group: Individual Submission >Number of pages: 98 >URL: =20 >http://www.ietf.org/internet-drafts/draft-stoecker-danyliw-rfc5070bis-00.t >xt >Status: =20 >http://datatracker.ietf.org/doc/draft-stoecker-danyliw-rfc5070bis >Htmlized: =20 >http://tools.ietf.org/html/draft-stoecker-danyliw-rfc5070bis-00 > > >Abstract: > The Incident Object Description Exchange Format (IODEF) defines a > data representation that provides a framework for sharing information > commonly exchanged by Computer Security Incident Response Teams > (CSIRTs) about computer security incidents. This document describes > the information model for the IODEF and provides an associated data > model specified with XML Schema. > > =20 > =20 > > >The IETF Secretariat > > From john.banghart@nist.gov Mon Feb 18 04:41:55 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852CE21F887F for ; Mon, 18 Feb 2013 04:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc1OY5P0aLQe for ; Mon, 18 Feb 2013 04:41:52 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4A321F8835 for ; Mon, 18 Feb 2013 04:41:51 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 18 Feb 2013 07:41:49 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 18 Feb 2013 07:41:50 -0500 From: "Banghart, John" To: Eric Burger , MILE IETF Date: Mon, 18 Feb 2013 07:41:44 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4N1VI1PKfnY0u8SQKQksjIDh9ofg== Message-ID: In-Reply-To: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 12:41:55 -0000 Eric, Well, I think you answered your own initial question, but I'm going to jump in anyway. :) Generally speaking, I think we want to strike a balance between standardization and flexibility. We are unlikely to arrive at any sort of one-size-fits-all scheme, no matter how long we talk about it. Instead, we should be focusing on solidifying the areas we can all agree on, and allow flexibility for those that we don't. It's an age old clich=E9, but let's not let perfect be the enemy of the good. -John On 2/16/13 12:42 PM, "Eric Burger" wrote: >What is the justification for both numeric and enumerated values >(low/medium/high)? In general such a schema is begging for >interoperability problems. > >I suppose I can understand both sides of the argument. On the We Need >Numbers side is those that actually calculate a percentage or other >objective measure in the confidence may want to use those real numbers. >As well, on the We Need Numbers side is the argument that three >enumerated values may not prove sufficient in the future. On the We Need >Enumerated Values side is confidence, other than 0% and 100%, tend to be >arbitrary guesses. Putting a number on this value imparts a level of >specificity that does not exist. Also, it is a lot easier to map 'low' to >'low' than it is to map 0-33 to 'low'. > >On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" > wrote: > >> That will work provided I (and everyone else) has a mapping for the >>numbers. I would prefer a simple low/med/high scheme. The more we add >>the more you have to be able to differentiate between them. However for >>potential interoperability I do see the benefit of the 5. >> >> Thanks, >> >> --Chris >> >> From: Moriarty, Kathleen >> Sent: Wednesday, February 13, 2013 2:05 PM >> To: Harrington, Christopher; MILE IETF >> Subject: RE: [mile] IOCs >> >> >> If you think of IODEF just for transport, could you meet your needs >>with storing the values differently in a database (IODEF is just meant >>for the exchange)? The numbers map to low/med/high - for db storage - >>if numbers are used, you could store the equivalent value, adding the 2 >>additional ones provided. >> >> Does it make sense to expand the set of values to match what CIF is >>doing if we went forward with the approach of supporting both options? >> >> Thank you, >> Kathleen >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>Harrington, Christopher >> Sent: Wednesday, February 13, 2013 11:49 AM >> To: 'C. Henry Adams & BIE'; MILE IETF >> Subject: Re: [mile] IOCs >> >> From a data processing standpoint it is going to create extra work for >>the people who are going to receive this data if we support both numeric >>and alpha characters in the same field. I can envision people wanting to >>search, sort, store, etc the data in this field. If we allow both data >>types then everyone will need to have a mapping of some sort. I have a >>field for confidence in my threat tracking database. Having both a >>numeric score and alpha characters / words creates issues when trying to >>interact with the data. I agree that we need to support both however I >>don't think both should be in the same field. I would much rather see 2 >>different fields for Confidence if we are going to support 2 different >>data types. >> >> This will be a larger issue should Confidence be used elsewhere. >>Ideally in future revisions I would like to see attribution expressed as >> some form of attribution is almost always shared with an IoC. >>Currently there are 5 areas where we (EMC) uses confidence. >> >> Indicator (how confident are you that this is a valid IoC) >> Indicator_Set (how confident are you that all of the indcators in the >>set should be in the set) >> Campaign (how confident are you that all Indicator_Sets are part of >>this campaign) >> Threat Actor (how confident are you that the Campaign is attributed to >>this Threat Actor) >> Threat Actor type (how confident are you that this Theat Actor is APT, >>Crimeware, other) >> >> The threat actor name and the threat actor type are usually the first 2 >>things that anyone processing IoCs wants to know as they drive priority. >> Knowing how sure the sender is that this IoC is APTis a vital piece of >>information for us. Sorry to take us a little off the path but I wanted >>to show where Confidence could be used. >> >> Thanks, >> >> --Chris >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>C. Henry Adams & BIE >> Sent: Wednesday, February 13, 2013 10:24 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> Again, I would concur that both a numeric and subjective analysis of >>the Confidence Rating needs to be express, but combined in a simplified >>schema as such below: >> >> 1LL .... etc. >> >> 2P >> >> 3AC >> >> 4U >> >> 5I >> >> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D U= rgent, >>5 =3D Imminent ) >> >> Here's my point, perhaps a set of numeric related or associated >>definitions can lower the propagation of error regarding the analysis. >> >> Thanks, >> C. Henry Adams >> >> >> I agree that what we really need is both. In most situations a low, >>medium and high may be acceptable but there are times when we will want >>to show that confidence in a situation is increasing or decreasing. If >>we are only looking at a three levels, we cannot express what is needed >>to show confidence is trending up on the data being exchanged about the >>event. >> >> Kathleen included the following in a previous message. >> >> >> >> Vs: >> >> 85 >> >> I really think we need to include both capabilities as John alluded to >>since confidence is not a three tiered item but something that is indeed >>subjective and we need a means to show a reasonably accurate confidence >>index that the sender is trying to convey. >> >> Kent Landfield >> >> McAfee | An Intel Company >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >> >> From: , John Banghart >> Date: Wednesday, February 13, 2013 7:16 AM >> To: "Stoecker, Paul" , Kathleen Moriarty >>, Brian Trammell >> Cc: "C. Henry Adams & BIE" , MILE IETF >> >> Subject: Re: [mile] IOCs >> >> Paul, >> >> I agree that confidence is subjective, but subjectivity can be reduced >> within communities that interact frequently. Prioritization of >>indicators >> and response between tightly connected sharing partners might require a >> more specific level of detail, particularly during a crisis situation. >> >> From that perspective, I think the guidance should allow for additional >> granularity, while stressing the "high, medium, low" as preferred for >> broad interoperability. >> >> -John >> >> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >> >> I may have been too succinct in my response ;-) >> >> Confidence is a subjective thing, so I think we should use subjective >> terms: Low, Medium, High. Having a numeric scale with a map that >> essentially would say something like: >> >> 1-33 =3D Low >> 34-67=3D Medium >> 68-100=3DHigh >> >> Is just a more complicated way of saying that something is Low, Medium, >> High...do we really thing that how High something is makes that much of >>a >> difference? >> >> This is like when you get your Performance review where it is Does Not >> Meet, Meets and Exceeds...your boss tells you that you are a High >> Meets...your >> bonus tells you that you got the same bonus that all the other Meets got >> ;-) >> >> Anyway, I digress but trying to prove a point that I would argue that >> confidence in this case is going to be basically a gut feeling, so why >>use >> numeric values when Low, Medium, High would do just fine. >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> >> >> >> >> >> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >> wrote: >> >> Hello, >> >> Both approaches will validate in the current schema. The representation >> looks a little different for each, here is an example: >> >> >> >> Vs: >> >> 85 >> >> Searching capability is a great point, agreed. I'd like to hear from >> more people to make sure we don't lose a capability that others find >> extremely useful (need to gauge that). Other options is that the >> guidance can also discourage the use of the numeric in addition to >> specifying how to select ranges. >> >> Any other opinions? >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: Stoecker, Paul >> Sent: Wednesday, February 13, 2013 7:14 AM >> To: Brian Trammell >> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >> Subject: Re: [mile] IOCs >> >> Cant we make Confidence a List that has only 3 values: High, Medium, >>and >> Low? Any other value means that the Document will mot validate against >> the schema. >> >> Sent from my iPhone >> >> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >> wrote: >> >> Hi, Kathleen, all, >> >> I think 3.10.4 in 5070 takes the right approach here: trying to build >> interoperable numeric scales for assessment is a very hard problem. >> (Were I charged with defining such a scale, the value "70" would mean >> "we compared this incident report to N past similar incident reports >> according to similarity algorithm S, and 70% of the past reports had >> assessed impacts within E% of the actual, measured final impact -- I >> think for most applications this is vastly more difficult and rigorous >> than it needs to be.) >> >> Unless a numeric Confidence value is based on some actual, repeatably >> measurable aspect of the Assessment report -- which I suspect in >> many/most/all cases it's not -- then it just represents a guess, however >> educated. Each team will probably naturally tune its own scales such >> that each value generally means the same thing in each report. Across >> teams, I don't know. >> >> On the other hand, Assessments are by their very nature educated >> guesses, anyway, so I don't know that I'd find much use in automating a >> response based on the assessment confidence. Chris has a good point, >> though -- it makes searching difficult and sorting kind of pointless. >> >> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >> agree, we should put that in the guidance document (along with a note >> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to high, >> unless we want to do it non-linearly). If the _vast_majority_ of the >> users of this field use a 100-point scale with 100 meaning "yes" and 0 >> meaning "any resemblance these values may have to actual fact is purely >> coincidental", then let's consider renaming it "percent" in 5070-bis. >> >> Best regards, >> >> Brian (as contributor) >> >> >> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >> wrote: >> >> Please see section 3.10.4 of RFC5070 as a starting point. We can >> change it if it needs to be changed. The value is for a confidence >> rating on the indicators shared. The definitions may be helpful for >> anyone who wants to work on this discussion. IODEF has various markers >> that can be used in a complimentary way without conflating the markers >> meaning. >> >> I think some people using IODEF find the numerical values more >> helpful, and it would be good to understand what people have learned >> from using the current structure (what works/does not work). The >> scales I have seen are 0-100. There is of course a subjective element >> to assigning a numerical value to the confidence and it may vary from >> entity to entity. With this type of rating you may need to consider >> who it came from and how they scored the confidence rating to map to >> your own rating. It would be good to hear more thoughts on this. >> >> Thanks, >> Kathleen >> >> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >> Sent: Tuesday, February 12, 2013 2:46 PM >> To: MILE IETF >> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >> Subject: Re: [mile] IOCs >> >> >> Regarding the IOCs or Indicators of Compromise, Chris made a vital >> point. Different Confidence levels will cause confusion. It appears >> that there maybe a need for some type of simplified standardization to >> be established between all Sharing Groups in this regard. >> >> Perhaps numerical scoring set at lower values should express levels of >> urgency. >> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D U= rgent, >> 5 =3D Imminent ) >> >> Thanks, >> C. Henry Adams >> >> >> >> I see some confusion coming down the pike if we start using Confidence >> the >> way it is supported. If I am using low/med/high and someone sends me >> an IoC >> with a score of 70, what does that mean to me? What if I am using a >> scale of >> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >> to >> describe something with a consistent language. It really gets ugly >> when we >> store IoC from multiple sources. I have confidence values that are >> numeric >> as well as text. Makes searching / sorting very problematic. >> >> At this point we have to roll with what we have. I would strongly >> recommend >> that we revisit this at some point. >> >> Thanks, >> >> --Chris >> >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Tuesday, February 12, 2013 9:59 AM >> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >> 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> Hi Chris & Take, >> >> I'll just focus on the confidence scoring. Right now, the schema >> allows for >> you to either use a numerical score OR the ratings of low, medium, and >> high. >> Different sharing groups can decide how they want to share the data. >> If >> people were to use the numerical values, I agree it would be helpful >> to have >> guidance. This could go in the IODE guidance document. >> >> I have seen examples of current users that use each of the approaches, >> so >> we'll need to keep the option for backwards compatibility and it is >> nice to >> keep in flexible options where we can. >> >> Thank you, >> Kathleen >> >> -----Original Message----- >> From: Harrington, Christopher >> Sent: Tuesday, February 12, 2013 9:22 AM >> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> The number of indicators wouldn't necessarily drive the use of >> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >> addresses that were used as C2 for 3 different campaigns I would have >> separate indicator_set_ids, each with one of the 3 C2 IPs >> >> My suggestion would be a simple low, medium, high. I think if we break >> it >> down to more levels than that we would need to provide guidance on >> scoring, >> rating, etc. I think most people should be able to understand >> low/med/high >> without having to have a mathematical method for arriving at the >> level. >> >> Low - I am not sure >> Medium - I am reasonably sure >> High - I am very sure >> >> >> Thanks, >> >> --Chris >> >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Tuesday, February 12, 2013 4:21 AM >> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> Regarding the indicator_set_id, I agree, it is useful when we need to >> deal >> with large sets of indicators. >> Since indicator_set_id attribute is optional (right?), it could be >> omitted >> if we need to deal with only small number of indicators. >> >> Regarding the use case, I like the idea of using the confidence >> attribute >> for the reason Chris kindly described. >> I would like to hear a bit more on this: is it going to be numerical? >> For >> instance, 1 means "no confidence" while 5 means "strong confidence", >> etc? >> >> Thank you. >> Take >> >> >> -----Original Message----- >> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >> Sent: Friday, February 08, 2013 4:11 AM >> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> With respect to tying things back to threat actors, from what I have >> seen and use this is a generally accepted grouping: >> >> Indicator --> Indictor Set --> Campaign --> Threat Actor >> >> Campaign and Threat Actor are where having a "Confidence" attribute >> would be beneficial as making those associations is not a perfect >> science by any means. >> >> Thanks, >> >> --Chris >> >> >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Thursday, February 07, 2013 2:00 PM >> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> Hi Take & others, >> >> Thanks for chiming in, I've been talking about this with Chris and a >> few others on their use cases and would like more opinions. I'll >> provide an option below from what we have discussed from a CIRC view >> point. We are also wondering how to also provide logic in IODEF that >> could cross over into SCI attached schemas or IODEF extensions (the >> solutions may all tie together with this discussion - or there may be >> better/more elegant solutions others would like to propose). >> >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Tuesday, February 05, 2013 12:04 PM >> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >> 'MILE >> IETF' >> Subject: RE: [mile] IOCs >> >> I like this discussion. >> I agree, it would be good idea to have indicator identifiers inside >> the IOC-related classes. >> >> KMM: At the class level, we may have several indicators listed that >> should be viewed as a set and may have another instance of that same >> class that is a related issue, but a separate set. We could as you >> say, list the indicator IDs connected through the reference class. >> The set IDs might give us other ways to group the values when we get >> into logic and relationships between sets or indicators. This could >> also be a way to connect indicators or sets across XML documents that >> could have been shared previously. If there are a large number of >> indicators in the set, then this becomes useful, for smaller sets, I >> agree it doesn't make as much sense. >> >> What do others think? >> >> Then for indicators not included in the base schema that may not >> fit into a category in the SCI draft, do we create a place for >> these off of SCI or right off of the IODE schema in EventData? >> (more details >> on >> this in my first message). >> >> If we could see any indicator of compromise as computer event >> record, we could use SCI:EventReport class as the place for the >> XML-based IOCs that couldn't fit anywhere else. >> >> KMM: That sounds like a good idea to me. This should go into >> guidance >> in the SCI draft. Does anyone else want to weigh in? >> >> >> For the non-XML IOCs, we could use RecordData class, as suggested. >> KMM: Sounds good, thanks! >> >> I agree to have indicator_uid, but I am not sure about the needs of >> the indicator_set_id. >> I understand we could do some grouping of individual indicator_uids >> and its usability, but I am not sure whether we do not have any >> other way to express these groupings. >> For instance, a Reference class refers to several indicadtor_uids. >> In >> this case, they could be, in a sense, grouped. Isn't it enough? >> >> KMM: It may be, what do you think about large sets of indicators or >> subsequent messages that add indicators to existing sets? Would this >> happen? Would it be easier to express relationships with sets of >> indicators in addition to individual indicators? By using this, it >> could give us a unique way to also provide the logic and >> relationships >> in a new class of IODEF so we don't have to worry about adding it >> into >> the current >> structure. >> If there are better ways to handle that, and others can provide some >> options, that would be appreciated! >> >> Thank you, >> Kathleen >> >> I would appreciate if anybody could share expertise on this. Though >> I >> think I have read all the emails in the list, I might have >> mis-understood some points. >> >> By the way, I think the indicator_uids should be added to the SCI >> classes' >> attributes so that they can be correlated with another information >> as >> well. >> >> Thanks >> Take >> >> >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> Of Harrington, Christopher >> Sent: Tuesday, February 05, 2013 4:25 AM >> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >> Subject: Re: [mile] IOCs >> >> I think some sort of group ID would do the trick. We also need a >> logical and / or somewhere to show relationship between indicators. >> If >> I give you >> 2 >> registry keys do they both have to be present to be an indication of >> compromise or is either one by themselves an indicator? Both would >> have the same group ID since they are related. >> >> Thanks, >> --Chris >> >> From: Stoecker, Paul >> Sent: Sunday, February 03, 2013 8:26 PM >> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >> Subject: Re: [mile] IOCs >> >> What if we added indicator group ID along with the indicator_uid? >> This would allow you to group indicators that are related into the >> same group ID. >> Would this resolve the issue? >> >> It is either that or going back to adding a Detection (or Indicators) >> class that will should be used to take all of the indicators put them >> into one place and have the ability to group the ones that go >> together. I don't mean a place to put indicators that are missing >> from IODEF.I mean a place in the IODEF document where you put the >> indicators that are used for detection and prevention of the shared >> Incident. I don't know the answer here, but there has got to be a >> good way for indicators to be identified and being able to group them >> as Chris has suggested without basically recreating something >> complicated like STIX. >> >> Paul >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> >> From: , Kathleen >> Date: Sunday, February 3, 2013 5:11 PM >> To: "Harrington, Christopher" , MILE >> IETF >> Subject: Re: [mile] IOCs >> >> Hi Chris, >> >> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >> >> The list has already said they would like to see indicators added to >> the definitions in RFC5070-bis, to be more explicit about including >> indicators and sets of indicators in IODE documents as opposed to >> 'parts of an incident or the useful information on an incident for >> sharing purposes. It was written before we used terms like >> indicators. With that in mind, Rosella proposed a number of changes >> back in July, both for guidance and for >> format >> updates. It may help to have the first draft try to address at least >> some of these issues so people can understand the problems and at >> least a proposed solution. >> >> As you point out, we need to be able to show relationships between >> sets of indicators, where we may have a few sets of indicators that >> could have a relationship to each other within a document. In the >> July presentation, one of the questions was to see if we should add >> new category attribute values for the System class that would connect >> the list of included indicators. I think we should still keep the >> concept of a Node to a single node, but perhaps within System, list >> multiple sets of Nodes that may be one type of attack. Rosella had >> suggested pulling forward the "FraudType" from RFC5901, this would >> help solve the issue as NodeRole values would compliment an >> AttackType >> (FraudType values could be included in AttackType or some broader >> term). It may be better to have the FraudTypes, plus attribute >> values >> like "C2-server", "sinkhole", "MalwareDistribution" for added >> context >> so you know what to do with the received set of indicators. >> >> I am proposing that we change IODEF to include multiple sets of >> indicators, >> add an AttackType attribute (or some other name), a method to connect >> indicators and indicator sets within an IODEF using an attribute of >> indicator_uid (or some other name) with a string value to make the >> connection points, and add a few indicators that are commonly shared >> into the base IODEF. >> >> Back in July, we talked about adding Registry Key/Value pairs and >> hashes to the main IODEF document (trying to see if this will help >> Chris below). What if we added the Registry Key/Value pairs as a >> class off of RecordData, using a similar structure to what is in >> RFC5901, and also added the ability to include hashes in RecordData? >> I think if we then had the indicator_uid at the RecordData level, we >> could connect a set within that structure and repeat the structure >> for >> other sets in the same way we would do with Node inside of the System >> class, using the indicator_uid to tie the set together. Then at the >> more specific level for the hash, registry Key/value, IP, etc. use an >> indicator_uid if we needed them marked at this level as well? Maybe >> we want indicator_set at the higher level? I'd like some opinions on >> this approach. +1 if you agree, suggestions if you have other ideas >> that may work better. >> >> We'll also need to worry about marking the indicators to prevent >> forward sharing when not permitted. We may want to use these values >> or something else. >> >> Thank you! >> Kathleen >> >> From: Harrington, Christopher >> Sent: Friday, February 01, 2013 12:01 PM >> To: Moriarty, Kathleen; MILE IETF >> Subject: RE: [mile] IOCs >> >> I think we have a bigger relationship issue to address. Let use the >> Watchlist Use Case. A bunch of indicators are sent in one message. In >> that message we could have groupings of indicators that we need to >> show are >> related: >> >> Two or more indicators of different type that relate to the same >> threat: >> The file hash of a malicious file and the URL of the C2 that >> the file uses. Either or both may be present to indicate a >> compromise. >> >> Two or more indicators of the same type that relate to the same >> threat: >> 2 different registry values for the same registry key. If >> either value is present it is a compromise indicator but both will >> not >> be >> present. >> >> The problem compounds itself very quickly. Consider the scenario >> where >> both groupings above are part of the same threat. I need to show that >> logical groupings of Indicators are related as well. We can't send >> multiple IODEF messages for this from what I remember reading. >> >> The last one I can think of would be when you have 2 different >> indicators that represent the same indicator. It's not uncommon to >> send both the >> MD5 >> and SHA1 hash of a malicious file. The indicator is the file but the >> IOCs are the 2 hash values. How do we show they are related? If we >> use >> a unique Inidcator ID for each hash value there needs to be a higher >> level >> grouping. >> >> Thoughts? >> >> Thanks, >> >> --Chris >> >> Christopher Harrington >> Consulting Security Engineer >> GSO - Critical Incident Response Center EMC - Where Information Lives >> 174 Middlesex Turnpike >> Bedford, MA 01730 >> 781-515-5862 (work) >> 603-583-1585 (cell) >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> Of Moriarty, Kathleen >> Sent: Friday, February 01, 2013 11:28 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> All - >> >> I'd like your input and will refocus the thread to get opinions from >> the list on options to help solve the problems raised in my message >> and additionally in Paul's message. >> >> Interesting point, C. Henry. Our objective here is to have machine >> automated exchanges, so we rely on encryption rather than obfuscation >> to achieve the necessary level of confidentiality. >> >> Paul mentioned the need to distinguish indicators of compromise from >> context information that may also include IP address or other data >> that could be indicators. The question I raised was on how to >> connect >> sets of indicators in the same IODEF document, assuming the ability >> to >> have watchlists that could have several sets of indicators included, >> as well as to connect indicators that may be included in embedded >> schemas. >> >> If we add an attribute on all of the relevant indicators, let's say >> 'indicator-uid' how do we mark the indicators? Do we use this to >> mark >> who sent the indicator as well so that we can prevent forward sharing >> when it is not permitted or handle that separately? >> >> Then for indicators not included in the base schema that may not fit >> into a category in the SCI draft, do we create a place for these off >> of SCI or right off of the IODE schema in EventData? (more details on >> this in my first message). >> >> Comments and questions encouraged to figure out the right technical >> solution to have this machine automatable. >> >> Thank you, >> Kathleen >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> Of C. >> Henry Adams & BIE >> Sent: Monday, January 28, 2013 11:25 PM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> Temporal Dependency sounds interesting. I remember when I first ran >> across this particular craft, an experienced colleague asked me a >> peculiar question. He said, " How do you stop someone from tracking >> the IP Address to your computer?" >> >> I replied, "I don't know, how?" >> >> Then he said, "Cut the dog-gone thing off and the modem that it is >> connected- which is constantly on!" LOL >> >> Here's my point (Hypothetical Situation) : There is a 1st Responder >> searching a Neighborhood for Survivors which were hit by a Disaster >> or >> let's just say "Live" Terrorist Situation. He /or She needs to >> communication back to other Officials that he /or somehow is in >> Danger. The device used to communicate has been captured by the >> great >> minds of the enemy. It's only a matter of time before they utilize >> reverse engineering to figure out how it functions. However, their >> pride comes before a fall when seeking the location of other similar >> devices to attack. Why? Perhaps the less thought of concepts that >> makes the device function properly, saves the day by disguise or >> cutting it off (figuratively speaking). >> >> Just a visionary thought. >> >> C. Henry Adams >> chenryadams@biemediagroup.com >> http://biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the >> original recipient. This information is granted for limited >> distribution within the recipient's place of business for planning >> purposes only. Further dissemination, whether private or public is >> prohibited. >> >> --- On Mon, 1/28/13, Dave Misell wrote: >> >> From: Dave Misell >> Subject: Re: [mile] IOCs >> To: "C. Henry Adams & BIE" >> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >> DNS >> SEC a pemanent and temporal key, with a temporal Id? >> >> Yours Faithfully, >> >> Dave Misell MSc CISSP >> SilentCircle dsm >> 07710 380044 >> david.misell@bcs.org >> >> >> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >> >> wrote: >> >> Serialization of a particular Lists of XML Classes in a unique way >> was >> closely related to what I attempted to express when I stated, >> "consider to a degree what appears to be illogical in brilliant minds >> in some instances." >> >> However, I see Dr. Stoecker's point a little clearer. However, it >> would >> be nice if the UID was in some way disguised from those who study >> this >> Security Art Form in a negative way. >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the >> original >> recipient. This information is granted for limited distribution >> within >> the >> recipient's place of business for planning purposes only. Further >> dissemination, whether private or public is prohibited. >> >> Re: [mile] IOCs >> >> Sunday, January 27, 2013 8:52 PM >> From: >> "Stoecker, Paul" >> To: >> "mile@ietf.org" >> I would like to look at this from a slightly different >> perspective=A9let's say I get an XML document that tells me about an >> incident. This document has source IP and destination IP that is >> being shared. However, what I don't know is which IP address is my >> indicator and which is just a contextual piece of information. This >> means that my detection product isn't going to know which one to use >> either, because there is nothing to tell me which IP is the one, >> even >> if the roles are set it still might not be enough to tell my system >> which >> one I should use as the indicator. >> >> If we had something like indicator_id as an attribute, it would >> allow >> us to easily identify indicators from contextual data. I do admit >> to >> being biased as I have spent much of my career working on the >> monitoring and detection side of these things, so I am just thinking >> of ways to make it very clear what the indicators are in the XML >> document and the other data that may be important as I investigate >> activity that I have detected off of those indicators. >> >> >> I did suggest the detection class, but I think we may get more >> flexibility with the indicator_uid. One thing that I haven't >> considered is the UID portion of this=A9how do we use that UID? How >> is >> the UID created? Are there standards for UIDs? >> >> Regards, >> >> Paul >> >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> --- On Sat, 1/26/13, C. Henry Adams & BIE >> wrote: >> >> From: C. Henry Adams & BIE >> Subject: RE: [mile] IOCs >> To: "KathleenMoriarty" >> Cc: mile@ietf.org >> Date: Saturday, January 26, 2013, 6:17 PM >> >> Greetings Kathleen, >> >> Your logic stimulates my visionary brain because I'm amazed at the >> many >> avenues you review with this approach at once. However, could you >> share >> a >> few advantages and disadvantages to the latter? >> -------------------------------------------------------------------- >> -------- >> ---------------------------------------------- >> "we could continue to group items in logical places as is done now >> in >> IODEF and then have the extension point for combined indicators via >> SCI." >> -------------------------------------------------------------------- >> -------- >> --------------------------------------------- >> >> You pointed out what you consider to be logical places, but if I >> wanted to >> protect information from parties capable of ascertaining it from your >> logical places, perhaps we should also consider to a degree what >> appears >> to >> be illogical in brilliant minds in some instances. >> >> >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) >> chenryadams@biemediagroup.com >> >> The information contained herein is for the exclusive use of the >> original >> recipient. This information is granted for limited distribution >> within >> the >> recipient's place of business for planning purposes only. Further >> dissemination, whether private or public is prohibited. >> >> --- On Sat, 1/26/13, Moriarty, Kathleen >> wrote: >> >> From: Moriarty, Kathleen >> Subject: RE: [mile] IOCs >> To: "C. Henry Adams & BIE" , "mile@ietf.org" >> >> Date: Saturday, January 26, 2013, 10:13 AM >> >> Hello C. Henry & others, >> >> Thanks for taking a look at this. We have a few considerations in >> this >> email thread I would like to hear thoughts on (and there may be more >> once >> RFC5070-bis is actively edited). >> >> The AdditionalData class and the RecordItem class both allow for >> non-XML >> extensions. Where you place the extensions should be specific to the >> logical grouping of the parent elements so you can understand more >> about >> the >> included data in most cases. >> >> The Impact class can be used to provide context information on the >> included data of the report and also can include a confidence rating >> on >> the >> report as a whole. Extensions related to impact would be one level >> higher >> (at the moment) in the Assessment class using the AdditionalData >> extension >> point. >> >> Take asked about including vulnerability information, I would think >> that >> would fit under the Vulnerability extension point of the SCI draft in >> the >> Method class. He did ask about non-XML. RecordItem or >> AdditionalData >> do >> allow for non-XML extension points, we could either have the SCI >> draft >> handle these as well or have the extensions that are non-XML come >> directly >> off the AdditionalData or RecordItem classes according to what makes >> sense >> from a logical standpoint. >> >> As for my question, it was two-fold. >> >> Indicator based schemas have a reference number or a GUID for the >> various >> indicators they share. If we are extending to embed other schemas >> that >> include such reference or GUID identifiers, do we want to add an >> attribute >> to the various elements in IODEF that could be indicators? Is this >> enough >> to make the connections or is something else else needed? We could >> add >> something like an Indicator_ID in RFC5070-bis which would then >> correlate >> to >> the reference or GUID identifiers. >> >> Then the other question was on how to include indicators that are >> not >> in >> the base schema that may be related or have language with "and" "or" >> to >> specify the relationships. In some cases, you will want to group >> these >> indictors in one extension point, where they may fit logically in >> multiple >> places if the relationships did not need to be shown in the data >> format. If >> we have cases like this where you need more complex representations, >> should >> we use one extension point via the SCI draft off of the EventData >> class >> AdditionalData extension point? Opinions are needed here.... >> >> A few people have mentioned wanting to include some commonly shared >> indictors into the base IODEF document. We could have a catch-all >> class >> that does this and has an extension point off of it in EventData or >> we >> could >> continue to group items in logical places as is done now in IODEF and >> then >> have the extension point for combined indicators via SCI. I think I >> like >> the latter approach. >> >> Thank you, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >> Henry >> Adams & BIE [chatlga2000@yahoo.com] >> Sent: Saturday, January 26, 2013 3:05 AM >> To: mile@ietf.org >> Cc: C. Henry Adams >> Subject: Re: [mile] IOCs >> >> Greetings Everyone, >> >> Take mentioned two types of indicators based on the : >> -------------------------------------------------------------------- >> -------- >> -------------------------- >> 1) If the indicators are something like an XML-based alert/warning >> of >> information leakage, it could be an event that are conveyed in the >> SCI's EventReport class, IMHO. >> >> 2) If the indicators are something like an non-XML ones, I guess it >> could >> be >> conveyed without using SCI draft. >> For instance, we could use Impact class of the base IODEF to convey >> the indicators. >> We could for instance extend the list of indicators of the Impact >> class, >> if >> needed. >> -------------------------------------------------------------------- >> -------- >> -------------------------- >> >> In doing so he pointed out the "Impact Class" >> >> Whereas, Kathleen stated, >> -------------------------------------------------------------------- >> -------- >> ------------------------- >> For the discussion below, I was thinking more of combined set with >> relationships that may be included in a single extension point, so >> that's >> why I was thinking about the EventData class, but there may be better >> locations or a specific area within the EventData. >> >> Paul Stoecker had suggested a "Detection" class as a consideration. >> -------------------------------------------------------------------- >> -------- >> ------------------------ >> >> Kathleen thoughts related yet still with other indicators and the >> EventData Class. >> >> Is there a possible way to create a new XML class which encompass >> combining the EventData, Detection and base IODEF classes to simplify >> this >> issue? >> >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) >> chenryadams@biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the >> original >> recipient. This information is granted for limited distribution >> within >> the >> recipient's place of business for planning purposes only. Further >> dissemination, whether private or public is prohibited. >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From Christopher.Harrington@emc.com Tue Feb 19 04:24:19 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D29D21F8C31 for ; Tue, 19 Feb 2013 04:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D1ZtiqwbHux for ; Tue, 19 Feb 2013 04:24:16 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7562F21F8C17 for ; Tue, 19 Feb 2013 04:24:16 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JCODfi003088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 07:24:14 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 19 Feb 2013 07:24:03 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JCO2VF024185; Tue, 19 Feb 2013 07:24:02 -0500 Received: from mx36a.corp.emc.com ([169.254.1.8]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Tue, 19 Feb 2013 07:24:01 -0500 From: "Harrington, Christopher" To: "'Banghart, John'" , Eric Burger , MILE IETF Date: Tue, 19 Feb 2013 07:24:01 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4N1VI1PKfnY0u8SQKQksjIDh9ofgAxRQ1A Message-ID: References: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008A_01CE0E72.16AD4D80" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 12:24:19 -0000 ------=_NextPart_000_008A_01CE0E72.16AD4D80 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I would agree that flexibility is something to strive for. However there isn't enough in the RFC to make the numeric confidence value understood = by the recipient and therefore actionable. From the spec: "numeric. The element content contains a number that conveys the = confidence of the data. The semantics of this number outside the scope of this specification" Based on that I can score my confidence with 1 being most confident and = 100 being least. Perfectly legitimate but would probably mess everybody up. = What if my scale is 1000 and yours is 100. I send you something with a score = of 100 you will think I am absolutely certain when I am only 10% so. = Knowing how sure the sender is about a piece of data shared is critical. If the sender puts an arbitrary number in the field I have no point of = reference. It's meaningless to me.=20 We spell out what the relative value is for low/med/high. I know those = are self-explanatory but they are still spelled out. I would urge that we do = the same for a numeric value. If not there needs to be something added so = that in addition to the numeric value I have a point of reference for how = certain you are based on the number you put there.=20 Thanks, --Chris -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, John Sent: Monday, February 18, 2013 7:42 AM To: Eric Burger; MILE IETF Subject: Re: [mile] IOCs Eric, Well, I think you answered your own initial question, but I'm going to = jump in anyway. :) Generally speaking, I think we want to strike a balance between standardization and flexibility. We are unlikely to arrive at any sort = of one-size-fits-all scheme, no matter how long we talk about it. Instead, = we should be focusing on solidifying the areas we can all agree on, and = allow flexibility for those that we don't. It's an age old clich=E9, but = let's not let perfect be the enemy of the good. -John On 2/16/13 12:42 PM, "Eric Burger" wrote: >What is the justification for both numeric and enumerated values=20 >(low/medium/high)? In general such a schema is begging for=20 >interoperability problems. > >I suppose I can understand both sides of the argument. On the We Need=20 >Numbers side is those that actually calculate a percentage or other=20 >objective measure in the confidence may want to use those real numbers. >As well, on the We Need Numbers side is the argument that three=20 >enumerated values may not prove sufficient in the future. On the We=20 >Need Enumerated Values side is confidence, other than 0% and 100%, tend = >to be arbitrary guesses. Putting a number on this value imparts a level = >of specificity that does not exist. Also, it is a lot easier to map=20 >'low' to 'low' than it is to map 0-33 to 'low'. > >On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" > wrote: > >> That will work provided I (and everyone else) has a mapping for the=20 >>numbers. I would prefer a simple low/med/high scheme. The more we add = >>the more you have to be able to differentiate between them. However=20 >>for potential interoperability I do see the benefit of the 5. >> >> Thanks, >> >> --Chris >> >> From: Moriarty, Kathleen >> Sent: Wednesday, February 13, 2013 2:05 PM >> To: Harrington, Christopher; MILE IETF >> Subject: RE: [mile] IOCs >> >> >> If you think of IODEF just for transport, could you meet your needs=20 >>with storing the values differently in a database (IODEF is just meant = >>for the exchange)? The numbers map to low/med/high - for db storage - = >>if numbers are used, you could store the equivalent value, adding the=20 >>2 additional ones provided. >> >> Does it make sense to expand the set of values to match what CIF is=20 >>doing if we went forward with the approach of supporting both options? >> >> Thank you, >> Kathleen >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 >>Of Harrington, Christopher >> Sent: Wednesday, February 13, 2013 11:49 AM >> To: 'C. Henry Adams & BIE'; MILE IETF >> Subject: Re: [mile] IOCs >> >> From a data processing standpoint it is going to create extra work=20 >>for the people who are going to receive this data if we support both=20 >>numeric and alpha characters in the same field. I can envision people=20 >>wanting to search, sort, store, etc the data in this field. If we=20 >>allow both data types then everyone will need to have a mapping of=20 >>some sort. I have a field for confidence in my threat tracking=20 >>database. Having both a numeric score and alpha characters / words=20 >>creates issues when trying to interact with the data. I agree that we=20 >>need to support both however I don't think both should be in the same=20 >>field. I would much rather see 2 different fields for Confidence if we = >>are going to support 2 different data types. >> >> This will be a larger issue should Confidence be used elsewhere. >>Ideally in future revisions I would like to see attribution expressed=20 >>as some form of attribution is almost always shared with an IoC. >>Currently there are 5 areas where we (EMC) uses confidence. >> >> Indicator (how confident are you that this is a valid IoC) =20 >>Indicator_Set (how confident are you that all of the indcators in the=20 >>set should be in the set) Campaign (how confident are you that all=20 >>Indicator_Sets are part of this campaign) Threat Actor (how confident = >>are you that the Campaign is attributed to this Threat Actor) Threat=20 >>Actor type (how confident are you that this Theat Actor is APT,=20 >>Crimeware, other) >> >> The threat actor name and the threat actor type are usually the first = >>2 things that anyone processing IoCs wants to know as they drive = priority. >> Knowing how sure the sender is that this IoC is APTis a vital piece=20 >>of information for us. Sorry to take us a little off the path but I=20 >>wanted to show where Confidence could be used. >> >> Thanks, >> >> --Chris >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 >>Of C. Henry Adams & BIE >> Sent: Wednesday, February 13, 2013 10:24 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> Again, I would concur that both a numeric and subjective analysis of=20 >>the Confidence Rating needs to be express, but combined in a=20 >>simplified schema as such below: >> >> 1LL .... etc. >> >> 2P >> >> 3AC >> >> 4U >> >> 5I >> >> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>5 =3D Imminent ) >> >> Here's my point, perhaps a set of numeric related or associated=20 >>definitions can lower the propagation of error regarding the analysis. >> >> Thanks, >> C. Henry Adams >> >> >> I agree that what we really need is both. In most situations a low,=20 >>medium and high may be acceptable but there are times when we will=20 >>want to show that confidence in a situation is increasing or=20 >>decreasing. If we are only looking at a three levels, we cannot=20 >>express what is needed to show confidence is trending up on the data=20 >>being exchanged about the event. >> >> Kathleen included the following in a previous message. >> >> >> >> Vs: >> >> 85 >> >> I really think we need to include both capabilities as John alluded=20 >>to since confidence is not a three tiered item but something that is=20 >>indeed subjective and we need a means to show a reasonably accurate=20 >>confidence index that the sender is trying to convey. >> >> Kent Landfield >> >> McAfee | An Intel Company >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >> >> From: , John Banghart >> Date: Wednesday, February 13, 2013 7:16 AM >> To: "Stoecker, Paul" , Kathleen Moriarty=20 >>, Brian Trammell >> Cc: "C. Henry Adams & BIE" , MILE IETF=20 >> >> Subject: Re: [mile] IOCs >> >> Paul, >> >> I agree that confidence is subjective, but subjectivity can be=20 >>reduced within communities that interact frequently. Prioritization=20 >>of indicators and response between tightly connected sharing partners = >>might require a more specific level of detail, particularly during a=20 >>crisis situation. >> >> From that perspective, I think the guidance should allow for=20 >> additional granularity, while stressing the "high, medium, low" as=20 >> preferred for broad interoperability. >> >> -John >> >> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >> >> I may have been too succinct in my response ;-) >> >> Confidence is a subjective thing, so I think we should use subjective >> terms: Low, Medium, High. Having a numeric scale with a map that=20 >> essentially would say something like: >> >> 1-33 =3D Low >> 34-67=3D Medium >> 68-100=3DHigh >> >> Is just a more complicated way of saying that something is Low,=20 >>Medium, High...do we really thing that how High something is makes=20 >>that much of a difference? >> >> This is like when you get your Performance review where it is Does=20 >> Not Meet, Meets and Exceeds...your boss tells you that you are a High = >> Meets...your bonus tells you that you got the same bonus that all the = >> other Meets got >> ;-) >> >> Anyway, I digress but trying to prove a point that I would argue that = =20 >>confidence in this case is going to be basically a gut feeling, so why = >>use numeric values when Low, Medium, High would do just fine. >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> >> >> >> >> >> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >> wrote: >> >> Hello, >> >> Both approaches will validate in the current schema. The=20 >> representation looks a little different for each, here is an example: >> >> >> >> Vs: >> >> 85 >> >> Searching capability is a great point, agreed. I'd like to hear from = >> more people to make sure we don't lose a capability that others find=20 >> extremely useful (need to gauge that). Other options is that the=20 >> guidance can also discourage the use of the numeric in addition to=20 >> specifying how to select ranges. >> >> Any other opinions? >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: Stoecker, Paul >> Sent: Wednesday, February 13, 2013 7:14 AM >> To: Brian Trammell >> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >> Subject: Re: [mile] IOCs >> >> Cant we make Confidence a List that has only 3 values: High, Medium, = >>and Low? Any other value means that the Document will mot validate=20 >>against the schema. >> >> Sent from my iPhone >> >> On Feb 13, 2013, at 2:14 AM, "Brian Trammell"=20 >> >> wrote: >> >> Hi, Kathleen, all, >> >> I think 3.10.4 in 5070 takes the right approach here: trying to build = >> interoperable numeric scales for assessment is a very hard problem. >> (Were I charged with defining such a scale, the value "70" would mean = >> "we compared this incident report to N past similar incident reports=20 >> according to similarity algorithm S, and 70% of the past reports had=20 >> assessed impacts within E% of the actual, measured final impact -- I=20 >> think for most applications this is vastly more difficult and=20 >> rigorous than it needs to be.) >> >> Unless a numeric Confidence value is based on some actual, repeatably = >> measurable aspect of the Assessment report -- which I suspect in=20 >> many/most/all cases it's not -- then it just represents a guess,=20 >> however educated. Each team will probably naturally tune its own=20 >> scales such that each value generally means the same thing in each=20 >> report. Across teams, I don't know. >> >> On the other hand, Assessments are by their very nature educated=20 >> guesses, anyway, so I don't know that I'd find much use in automating = >> a response based on the assessment confidence. Chris has a good=20 >> point, though -- it makes searching difficult and sorting kind of pointless. >> >> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I = >> agree, we should put that in the guidance document (along with a note = >> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to=20 >> high, unless we want to do it non-linearly). If the _vast_majority_=20 >> of the users of this field use a 100-point scale with 100 meaning=20 >> "yes" and 0 meaning "any resemblance these values may have to actual=20 >> fact is purely coincidental", then let's consider renaming it = "percent" in 5070-bis. >> >> Best regards, >> >> Brian (as contributor) >> >> >> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >> wrote: >> >> Please see section 3.10.4 of RFC5070 as a starting point. We can=20 >> change it if it needs to be changed. The value is for a confidence=20 >> rating on the indicators shared. The definitions may be helpful for=20 >> anyone who wants to work on this discussion. IODEF has various=20 >> markers that can be used in a complimentary way without conflating=20 >> the markers meaning. >> >> I think some people using IODEF find the numerical values more=20 >> helpful, and it would be good to understand what people have learned=20 >> from using the current structure (what works/does not work). The=20 >> scales I have seen are 0-100. There is of course a subjective=20 >> element to assigning a numerical value to the confidence and it may=20 >> vary from entity to entity. With this type of rating you may need to = >> consider who it came from and how they scored the confidence rating=20 >> to map to your own rating. It would be good to hear more thoughts on this. >> >> Thanks, >> Kathleen >> >> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >> Sent: Tuesday, February 12, 2013 2:46 PM >> To: MILE IETF >> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >> Subject: Re: [mile] IOCs >> >> >> Regarding the IOCs or Indicators of Compromise, Chris made a vital=20 >> point. Different Confidence levels will cause confusion. It appears = >> that there maybe a need for some type of simplified standardization=20 >> to be established between all Sharing Groups in this regard. >> >> Perhaps numerical scoring set at lower values should express levels=20 >> of urgency. >> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >> 5 =3D Imminent ) >> >> Thanks, >> C. Henry Adams >> >> >> >> I see some confusion coming down the pike if we start using=20 >> Confidence the way it is supported. If I am using low/med/high and=20 >> someone sends me an IoC with a score of 70, what does that mean to=20 >> me? What if I am using a scale of >> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability=20 >> to describe something with a consistent language. It really gets ugly = >> when we store IoC from multiple sources. I have confidence values=20 >> that are numeric as well as text. Makes searching / sorting very=20 >> problematic. >> >> At this point we have to roll with what we have. I would strongly=20 >> recommend that we revisit this at some point. >> >> Thanks, >> >> --Chris >> >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Tuesday, February 12, 2013 9:59 AM >> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;=20 >> 'MILE IETF' >> Subject: RE: [mile] IOCs >> >> Hi Chris & Take, >> >> I'll just focus on the confidence scoring. Right now, the schema=20 >> allows for you to either use a numerical score OR the ratings of low, = >> medium, and high. >> Different sharing groups can decide how they want to share the data. >> If >> people were to use the numerical values, I agree it would be helpful=20 >> to have guidance. This could go in the IODE guidance document. >> >> I have seen examples of current users that use each of the=20 >> approaches, so we'll need to keep the option for backwards=20 >> compatibility and it is nice to keep in flexible options where we=20 >> can. >> >> Thank you, >> Kathleen >> >> -----Original Message----- >> From: Harrington, Christopher >> Sent: Tuesday, February 12, 2013 9:22 AM >> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE=20 >> IETF' >> Subject: RE: [mile] IOCs >> >> The number of indicators wouldn't necessarily drive the use of=20 >> indicator_set_id. The purpose is to show relationship. If I sent 3 IP = >> addresses that were used as C2 for 3 different campaigns I would have = >> separate indicator_set_ids, each with one of the 3 C2 IPs >> >> My suggestion would be a simple low, medium, high. I think if we=20 >> break it down to more levels than that we would need to provide=20 >> guidance on scoring, rating, etc. I think most people should be able=20 >> to understand low/med/high without having to have a mathematical=20 >> method for arriving at the level. >> >> Low - I am not sure >> Medium - I am reasonably sure >> High - I am very sure >> >> >> Thanks, >> >> --Chris >> >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Tuesday, February 12, 2013 4:21 AM >> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul;=20 >> 'MILE IETF' >> Subject: RE: [mile] IOCs >> >> Regarding the indicator_set_id, I agree, it is useful when we need to = >> deal with large sets of indicators. >> Since indicator_set_id attribute is optional (right?), it could be=20 >> omitted if we need to deal with only small number of indicators. >> >> Regarding the use case, I like the idea of using the confidence=20 >> attribute for the reason Chris kindly described. >> I would like to hear a bit more on this: is it going to be numerical? >> For >> instance, 1 means "no confidence" while 5 means "strong confidence",=20 >> etc? >> >> Thank you. >> Take >> >> >> -----Original Message----- >> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >> Sent: Friday, February 08, 2013 4:11 AM >> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE=20 >> IETF' >> Subject: RE: [mile] IOCs >> >> With respect to tying things back to threat actors, from what I have=20 >> seen and use this is a generally accepted grouping: >> >> Indicator --> Indictor Set --> Campaign --> Threat Actor >> >> Campaign and Threat Actor are where having a "Confidence" attribute=20 >> would be beneficial as making those associations is not a perfect=20 >> science by any means. >> >> Thanks, >> >> --Chris >> >> >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Thursday, February 07, 2013 2:00 PM >> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE = >> IETF' >> Subject: RE: [mile] IOCs >> >> Hi Take & others, >> >> Thanks for chiming in, I've been talking about this with Chris and a=20 >> few others on their use cases and would like more opinions. I'll=20 >> provide an option below from what we have discussed from a CIRC view=20 >> point. We are also wondering how to also provide logic in IODEF that = >> could cross over into SCI attached schemas or IODEF extensions (the=20 >> solutions may all tie together with this discussion - or there may be = >> better/more elegant solutions others would like to propose). >> >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Tuesday, February 05, 2013 12:04 PM >> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;=20 >> 'MILE IETF' >> Subject: RE: [mile] IOCs >> >> I like this discussion. >> I agree, it would be good idea to have indicator identifiers inside=20 >> the IOC-related classes. >> >> KMM: At the class level, we may have several indicators listed that=20 >> should be viewed as a set and may have another instance of that same=20 >> class that is a related issue, but a separate set. We could as you=20 >> say, list the indicator IDs connected through the reference class. >> The set IDs might give us other ways to group the values when we get=20 >> into logic and relationships between sets or indicators. This could=20 >> also be a way to connect indicators or sets across XML documents that = >> could have been shared previously. If there are a large number of=20 >> indicators in the set, then this becomes useful, for smaller sets, I=20 >> agree it doesn't make as much sense. >> >> What do others think? >> >> Then for indicators not included in the base schema that may not fit=20 >> into a category in the SCI draft, do we create a place for these off=20 >> of SCI or right off of the IODE schema in EventData? >> (more details >> on >> this in my first message). >> >> If we could see any indicator of compromise as computer event record, = >> we could use SCI:EventReport class as the place for the XML-based=20 >> IOCs that couldn't fit anywhere else. >> >> KMM: That sounds like a good idea to me. This should go into=20 >> guidance in the SCI draft. Does anyone else want to weigh in? >> >> >> For the non-XML IOCs, we could use RecordData class, as suggested. >> KMM: Sounds good, thanks! >> >> I agree to have indicator_uid, but I am not sure about the needs of=20 >> the indicator_set_id. >> I understand we could do some grouping of individual indicator_uids=20 >> and its usability, but I am not sure whether we do not have any other = >> way to express these groupings. >> For instance, a Reference class refers to several indicadtor_uids. >> In >> this case, they could be, in a sense, grouped. Isn't it enough? >> >> KMM: It may be, what do you think about large sets of indicators or=20 >> subsequent messages that add indicators to existing sets? Would this = >> happen? Would it be easier to express relationships with sets of=20 >> indicators in addition to individual indicators? By using this, it=20 >> could give us a unique way to also provide the logic and=20 >> relationships in a new class of IODEF so we don't have to worry about = >> adding it into the current structure. >> If there are better ways to handle that, and others can provide some=20 >> options, that would be appreciated! >> >> Thank you, >> Kathleen >> >> I would appreciate if anybody could share expertise on this. Though I = >> think I have read all the emails in the list, I might have=20 >> mis-understood some points. >> >> By the way, I think the indicator_uids should be added to the SCI=20 >> classes' >> attributes so that they can be correlated with another information as = >> well. >> >> Thanks >> Take >> >> >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 >> Of Harrington, Christopher >> Sent: Tuesday, February 05, 2013 4:25 AM >> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >> Subject: Re: [mile] IOCs >> >> I think some sort of group ID would do the trick. We also need a=20 >> logical and / or somewhere to show relationship between indicators. >> If >> I give you >> 2 >> registry keys do they both have to be present to be an indication of=20 >> compromise or is either one by themselves an indicator? Both would=20 >> have the same group ID since they are related. >> >> Thanks, >> --Chris >> >> From: Stoecker, Paul >> Sent: Sunday, February 03, 2013 8:26 PM >> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >> Subject: Re: [mile] IOCs >> >> What if we added indicator group ID along with the indicator_uid? >> This would allow you to group indicators that are related into the=20 >> same group ID. >> Would this resolve the issue? >> >> It is either that or going back to adding a Detection (or Indicators) = >> class that will should be used to take all of the indicators put them = >> into one place and have the ability to group the ones that go=20 >> together. I don't mean a place to put indicators that are missing=20 >> from IODEF.I mean a place in the IODEF document where you put the=20 >> indicators that are used for detection and prevention of the shared=20 >> Incident. I don't know the answer here, but there has got to be a=20 >> good way for indicators to be identified and being able to group them = >> as Chris has suggested without basically recreating something=20 >> complicated like STIX. >> >> Paul >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> >> From: , Kathleen >> Date: Sunday, February 3, 2013 5:11 PM >> To: "Harrington, Christopher" , MILE=20 >> IETF >> Subject: Re: [mile] IOCs >> >> Hi Chris, >> >> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >> >> The list has already said they would like to see indicators added to=20 >> the definitions in RFC5070-bis, to be more explicit about including=20 >> indicators and sets of indicators in IODE documents as opposed to=20 >> 'parts of an incident or the useful information on an incident for=20 >> sharing purposes. It was written before we used terms like=20 >> indicators. With that in mind, Rosella proposed a number of changes=20 >> back in July, both for guidance and for format updates. It may help=20 >> to have the first draft try to address at least some of these issues=20 >> so people can understand the problems and at least a proposed=20 >> solution. >> >> As you point out, we need to be able to show relationships between=20 >> sets of indicators, where we may have a few sets of indicators that=20 >> could have a relationship to each other within a document. In the=20 >> July presentation, one of the questions was to see if we should add=20 >> new category attribute values for the System class that would connect = >> the list of included indicators. I think we should still keep the=20 >> concept of a Node to a single node, but perhaps within System, list=20 >> multiple sets of Nodes that may be one type of attack. Rosella had=20 >> suggested pulling forward the "FraudType" from RFC5901, this would=20 >> help solve the issue as NodeRole values would compliment an=20 >> AttackType (FraudType values could be included in AttackType or some=20 >> broader term). It may be better to have the FraudTypes, plus=20 >> attribute values like "C2-server", "sinkhole", "MalwareDistribution" = >> for added context so you know what to do with the received set of=20 >> indicators. >> >> I am proposing that we change IODEF to include multiple sets of=20 >> indicators, add an AttackType attribute (or some other name), a=20 >> method to connect indicators and indicator sets within an IODEF using = >> an attribute of indicator_uid (or some other name) with a string=20 >> value to make the connection points, and add a few indicators that=20 >> are commonly shared into the base IODEF. >> >> Back in July, we talked about adding Registry Key/Value pairs and=20 >> hashes to the main IODEF document (trying to see if this will help=20 >> Chris below). What if we added the Registry Key/Value pairs as a=20 >> class off of RecordData, using a similar structure to what is in=20 >> RFC5901, and also added the ability to include hashes in RecordData? >> I think if we then had the indicator_uid at the RecordData level, we=20 >> could connect a set within that structure and repeat the structure=20 >> for other sets in the same way we would do with Node inside of the=20 >> System class, using the indicator_uid to tie the set together. Then=20 >> at the more specific level for the hash, registry Key/value, IP, etc. = >> use an indicator_uid if we needed them marked at this level as well? = >> Maybe we want indicator_set at the higher level? I'd like some=20 >> opinions on this approach. +1 if you agree, suggestions if you have=20 >> other ideas that may work better. >> >> We'll also need to worry about marking the indicators to prevent=20 >> forward sharing when not permitted. We may want to use these values=20 >> or something else. >> >> Thank you! >> Kathleen >> >> From: Harrington, Christopher >> Sent: Friday, February 01, 2013 12:01 PM >> To: Moriarty, Kathleen; MILE IETF >> Subject: RE: [mile] IOCs >> >> I think we have a bigger relationship issue to address. Let use the=20 >> Watchlist Use Case. A bunch of indicators are sent in one message. In = >> that message we could have groupings of indicators that we need to=20 >> show are >> related: >> >> Two or more indicators of different type that relate to the same >> threat: >> The file hash of a malicious file and the URL of the C2 that=20 >> the file uses. Either or both may be present to indicate a=20 >> compromise. >> >> Two or more indicators of the same type that relate to the same >> threat: >> 2 different registry values for the same registry key. If=20 >> either value is present it is a compromise indicator but both will=20 >> not be present. >> >> The problem compounds itself very quickly. Consider the scenario=20 >> where both groupings above are part of the same threat. I need to=20 >> show that logical groupings of Indicators are related as well. We=20 >> can't send multiple IODEF messages for this from what I remember=20 >> reading. >> >> The last one I can think of would be when you have 2 different=20 >> indicators that represent the same indicator. It's not uncommon to=20 >> send both the >> MD5 >> and SHA1 hash of a malicious file. The indicator is the file but the=20 >> IOCs are the 2 hash values. How do we show they are related? If we=20 >> use a unique Inidcator ID for each hash value there needs to be a=20 >> higher level grouping. >> >> Thoughts? >> >> Thanks, >> >> --Chris >> >> Christopher Harrington >> Consulting Security Engineer >> GSO - Critical Incident Response Center EMC - Where Information Lives >> 174 Middlesex Turnpike >> Bedford, MA 01730 >> 781-515-5862 (work) >> 603-583-1585 (cell) >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 >> Of Moriarty, Kathleen >> Sent: Friday, February 01, 2013 11:28 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> All - >> >> I'd like your input and will refocus the thread to get opinions from=20 >> the list on options to help solve the problems raised in my message=20 >> and additionally in Paul's message. >> >> Interesting point, C. Henry. Our objective here is to have machine=20 >> automated exchanges, so we rely on encryption rather than obfuscation = >> to achieve the necessary level of confidentiality. >> >> Paul mentioned the need to distinguish indicators of compromise from=20 >> context information that may also include IP address or other data=20 >> that could be indicators. The question I raised was on how to=20 >> connect sets of indicators in the same IODEF document, assuming the=20 >> ability to have watchlists that could have several sets of indicators = >> included, as well as to connect indicators that may be included in=20 >> embedded schemas. >> >> If we add an attribute on all of the relevant indicators, let's say=20 >> 'indicator-uid' how do we mark the indicators? Do we use this to=20 >> mark who sent the indicator as well so that we can prevent forward=20 >> sharing when it is not permitted or handle that separately? >> >> Then for indicators not included in the base schema that may not fit=20 >> into a category in the SCI draft, do we create a place for these off=20 >> of SCI or right off of the IODE schema in EventData? (more details on = >> this in my first message). >> >> Comments and questions encouraged to figure out the right technical=20 >> solution to have this machine automatable. >> >> Thank you, >> Kathleen >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 >> Of C. >> Henry Adams & BIE >> Sent: Monday, January 28, 2013 11:25 PM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> Temporal Dependency sounds interesting. I remember when I first ran=20 >> across this particular craft, an experienced colleague asked me a=20 >> peculiar question. He said, " How do you stop someone from tracking=20 >> the IP Address to your computer?" >> >> I replied, "I don't know, how?" >> >> Then he said, "Cut the dog-gone thing off and the modem that it is >> connected- which is constantly on!" LOL >> >> Here's my point (Hypothetical Situation) : There is a 1st Responder=20 >> searching a Neighborhood for Survivors which were hit by a Disaster=20 >> or let's just say "Live" Terrorist Situation. He /or She needs to=20 >> communication back to other Officials that he /or somehow is in=20 >> Danger. The device used to communicate has been captured by the=20 >> great minds of the enemy. It's only a matter of time before they=20 >> utilize reverse engineering to figure out how it functions. However, = >> their pride comes before a fall when seeking the location of other=20 >> similar devices to attack. Why? Perhaps the less thought of concepts = >> that makes the device function properly, saves the day by disguise or = >> cutting it off (figuratively speaking). >> >> Just a visionary thought. >> >> C. Henry Adams >> chenryadams@biemediagroup.com >> http://biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the=20 >> original recipient. This information is granted for limited=20 >> distribution within the recipient's place of business for planning=20 >> purposes only. Further dissemination, whether private or public is=20 >> prohibited. >> >> --- On Mon, 1/28/13, Dave Misell wrote: >> >> From: Dave Misell >> Subject: Re: [mile] IOCs >> To: "C. Henry Adams & BIE" >> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with=20 >> DNS SEC a pemanent and temporal key, with a temporal Id? >> >> Yours Faithfully, >> >> Dave Misell MSc CISSP >> SilentCircle dsm >> 07710 380044 >> david.misell@bcs.org >> >> >> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE=20 >> >> wrote: >> >> Serialization of a particular Lists of XML Classes in a unique way=20 >> was closely related to what I attempted to express when I stated,=20 >> "consider to a degree what appears to be illogical in brilliant minds = >> in some instances." >> >> However, I see Dr. Stoecker's point a little clearer. However, it=20 >> would be nice if the UID was in some way disguised from those who=20 >> study this Security Art Form in a negative way. >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the=20 >> original recipient. This information is granted for limited=20 >> distribution within the recipient's place of business for planning=20 >> purposes only. Further dissemination, whether private or public is=20 >> prohibited. >> >> Re: [mile] IOCs >> >> Sunday, January 27, 2013 8:52 PM >> From: >> "Stoecker, Paul" >> To: >> "mile@ietf.org" >> I would like to look at this from a slightly different=20 >> perspective=A9let's say I get an XML document that tells me about an=20 >> incident. This document has source IP and destination IP that is=20 >> being shared. However, what I don't know is which IP address is my=20 >> indicator and which is just a contextual piece of information. This=20 >> means that my detection product isn't going to know which one to use=20 >> either, because there is nothing to tell me which IP is the one, even = >> if the roles are set it still might not be enough to tell my system=20 >> which one I should use as the indicator. >> >> If we had something like indicator_id as an attribute, it would allow = >> us to easily identify indicators from contextual data. I do admit to = >> being biased as I have spent much of my career working on the=20 >> monitoring and detection side of these things, so I am just thinking=20 >> of ways to make it very clear what the indicators are in the XML=20 >> document and the other data that may be important as I investigate=20 >> activity that I have detected off of those indicators. >> >> >> I did suggest the detection class, but I think we may get more=20 >> flexibility with the indicator_uid. One thing that I haven't=20 >> considered is the UID portion of this=A9how do we use that UID? How = is=20 >> the UID created? Are there standards for UIDs? >> >> Regards, >> >> Paul >> >> >> >> Paul W. Stoecker, Ph.D. >> SMC Lead Content Architect >> RSA, The Security Division of EMC >> cell: 302.379.3375 | e: paul.stoecker@rsa.com >> >> --- On Sat, 1/26/13, C. Henry Adams & BIE >> wrote: >> >> From: C. Henry Adams & BIE >> Subject: RE: [mile] IOCs >> To: "KathleenMoriarty" >> Cc: mile@ietf.org >> Date: Saturday, January 26, 2013, 6:17 PM >> >> Greetings Kathleen, >> >> Your logic stimulates my visionary brain because I'm amazed at the=20 >> many avenues you review with this approach at once. However, could=20 >> you share a few advantages and disadvantages to the latter? >> -------------------------------------------------------------------- >> -------- >> ---------------------------------------------- >> "we could continue to group items in logical places as is done now in = >> IODEF and then have the extension point for combined indicators via=20 >> SCI." >> -------------------------------------------------------------------- >> -------- >> --------------------------------------------- >> >> You pointed out what you consider to be logical places, but if I=20 >> wanted to protect information from parties capable of ascertaining it = >> from your logical places, perhaps we should also consider to a degree = >> what appears to be illogical in brilliant minds in some instances. >> >> >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) >> chenryadams@biemediagroup.com >> >> The information contained herein is for the exclusive use of the=20 >> original recipient. This information is granted for limited=20 >> distribution within the recipient's place of business for planning=20 >> purposes only. Further dissemination, whether private or public is=20 >> prohibited. >> >> --- On Sat, 1/26/13, Moriarty, Kathleen >> wrote: >> >> From: Moriarty, Kathleen >> Subject: RE: [mile] IOCs >> To: "C. Henry Adams & BIE" , "mile@ietf.org" >> >> Date: Saturday, January 26, 2013, 10:13 AM >> >> Hello C. Henry & others, >> >> Thanks for taking a look at this. We have a few considerations in=20 >> this email thread I would like to hear thoughts on (and there may be=20 >> more once RFC5070-bis is actively edited). >> >> The AdditionalData class and the RecordItem class both allow for=20 >> non-XML extensions. Where you place the extensions should be=20 >> specific to the logical grouping of the parent elements so you can=20 >> understand more about the included data in most cases. >> >> The Impact class can be used to provide context information on the=20 >> included data of the report and also can include a confidence rating=20 >> on the report as a whole. Extensions related to impact would be one=20 >> level higher (at the moment) in the Assessment class using the=20 >> AdditionalData extension point. >> >> Take asked about including vulnerability information, I would think=20 >> that would fit under the Vulnerability extension point of the SCI=20 >> draft in the Method class. He did ask about non-XML. RecordItem or=20 >> AdditionalData do allow for non-XML extension points, we could either = >> have the SCI draft handle these as well or have the extensions that=20 >> are non-XML come directly off the AdditionalData or RecordItem=20 >> classes according to what makes sense from a logical standpoint. >> >> As for my question, it was two-fold. >> >> Indicator based schemas have a reference number or a GUID for the=20 >> various indicators they share. If we are extending to embed other=20 >> schemas that include such reference or GUID identifiers, do we want=20 >> to add an attribute to the various elements in IODEF that could be=20 >> indicators? Is this enough to make the connections or is something=20 >> else else needed? We could add something like an Indicator_ID in=20 >> RFC5070-bis which would then correlate to the reference or GUID=20 >> identifiers. >> >> Then the other question was on how to include indicators that are not = >> in the base schema that may be related or have language with "and"=20 >> "or" >> to >> specify the relationships. In some cases, you will want to group=20 >> these indictors in one extension point, where they may fit logically=20 >> in multiple places if the relationships did not need to be shown in=20 >> the data format. If we have cases like this where you need more=20 >> complex representations, should we use one extension point via the=20 >> SCI draft off of the EventData class AdditionalData extension point? = >> Opinions are needed here.... >> >> A few people have mentioned wanting to include some commonly shared=20 >> indictors into the base IODEF document. We could have a catch-all=20 >> class that does this and has an extension point off of it in=20 >> EventData or we could continue to group items in logical places as is = >> done now in IODEF and then have the extension point for combined=20 >> indicators via SCI. I think I like the latter approach. >> >> Thank you, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >> Henry >> Adams & BIE [chatlga2000@yahoo.com] >> Sent: Saturday, January 26, 2013 3:05 AM >> To: mile@ietf.org >> Cc: C. Henry Adams >> Subject: Re: [mile] IOCs >> >> Greetings Everyone, >> >> Take mentioned two types of indicators based on the : >> -------------------------------------------------------------------- >> -------- >> -------------------------- >> 1) If the indicators are something like an XML-based alert/warning of = >> information leakage, it could be an event that are conveyed in the=20 >> SCI's EventReport class, IMHO. >> >> 2) If the indicators are something like an non-XML ones, I guess it=20 >> could be conveyed without using SCI draft. >> For instance, we could use Impact class of the base IODEF to convey=20 >> the indicators. >> We could for instance extend the list of indicators of the Impact=20 >> class, if needed. >> -------------------------------------------------------------------- >> -------- >> -------------------------- >> >> In doing so he pointed out the "Impact Class" >> >> Whereas, Kathleen stated, >> -------------------------------------------------------------------- >> -------- >> ------------------------- >> For the discussion below, I was thinking more of combined set with=20 >> relationships that may be included in a single extension point, so=20 >> that's why I was thinking about the EventData class, but there may be = >> better locations or a specific area within the EventData. >> >> Paul Stoecker had suggested a "Detection" class as a consideration. >> -------------------------------------------------------------------- >> -------- >> ------------------------ >> >> Kathleen thoughts related yet still with other indicators and the=20 >> EventData Class. >> >> Is there a possible way to create a new XML class which encompass=20 >> combining the EventData, Detection and base IODEF classes to simplify = >> this issue? >> >> >> C. Henry Adams >> chatlga2000@yahoo.com (Direct Email) >> chenryadams@biemediagroup.com >> >> >> The information contained herein is for the exclusive use of the=20 >> original recipient. This information is granted for limited=20 >> distribution within the recipient's place of business for planning=20 >> purposes only. Further dissemination, whether private or public is=20 >> prohibited. >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_008A_01CE0E72.16AD4D80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTkx MjI0MDBaMCMGCSqGSIb3DQEJBDEWBBSpQHV9cW7lk5YbtfZnLP68JqLpgzCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAjPT6NUz6/zAkXKpWg2OqFSFc82/6N08f1FUpHuIOXPmOkuoy76okOzUVp9n3dlzU nf+JDEJ5djKRv6mMGhXkSDahDaJpfeivvUv6RNKm/ZItlNimxn0mCwtobvn2JrAHaMMFZfnwg6r6 gWA3j7rUwxXzRdvlB952+R9VQW4CViDmlQdCllj/cJ4vJsbz2zD0TYn9Wx7H4kVhifSeMlS0JvWP K6sJ4/p9agbkGY0fcFr/GUHfyPaDshcR4XgtALDzVfcuNr02CLqsKm8N+h2FTKmPEq/ZfrNqqjI1 /V1lyZmZFAS22GLl7ZTa0/y0uLUeC5Z3jvFLaJepGKzr5WRA+wAAAAAAAA== ------=_NextPart_000_008A_01CE0E72.16AD4D80-- From eburger-l@standardstrack.com Tue Feb 19 04:38:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93A321F89EF for ; Tue, 19 Feb 2013 04:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnBkzddzhuYL for ; Tue, 19 Feb 2013 04:38:37 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id D461C21F89E1 for ; Tue, 19 Feb 2013 04:38:36 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:51584 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7mSs-0008HB-8L for mile@ietf.org; Tue, 19 Feb 2013 04:38:30 -0800 Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Tue, 19 Feb 2013 07:38:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7AF2C8-0529-475A-9125-BAF40F2D5F67@standardstrack.com> References: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> To: MILE IETF X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 12:38:40 -0000 If there really is no value to a value, do not let people hurt = themselves. If there is a proprietary reason for a value, we should say what we mean = and call it such. For example: This is XML so put your = NON-INTEROPERABLE mumble you want here or 42 or balderdash On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" = wrote: > I would agree that flexibility is something to strive for. However = there > isn't enough in the RFC to make the numeric confidence value = understood by > the recipient and therefore actionable. =46rom the spec: >=20 > "numeric. The element content contains a number that conveys the = confidence > of the data. The semantics of this number outside the scope of this > specification" >=20 > Based on that I can score my confidence with 1 being most confident = and 100 > being least. Perfectly legitimate but would probably mess everybody = up. What > if my scale is 1000 and yours is 100. I send you something with a = score of > 100 you will think I am absolutely certain when I am only 10% so. = Knowing > how sure the sender is about a piece of data shared is critical. If = the > sender puts an arbitrary number in the field I have no point of = reference. > It's meaningless to me.=20 >=20 > We spell out what the relative value is for low/med/high. I know those = are > self-explanatory but they are still spelled out. I would urge that we = do the > same for a numeric value. If not there needs to be something added so = that > in addition to the numeric value I have a point of reference for how = certain > you are based on the number you put there.=20 >=20 > Thanks, >=20 > --Chris >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Banghart, John > Sent: Monday, February 18, 2013 7:42 AM > To: Eric Burger; MILE IETF > Subject: Re: [mile] IOCs >=20 > Eric, >=20 > Well, I think you answered your own initial question, but I'm going to = jump > in anyway. :) >=20 > Generally speaking, I think we want to strike a balance between > standardization and flexibility. We are unlikely to arrive at any = sort of > one-size-fits-all scheme, no matter how long we talk about it. = Instead, we > should be focusing on solidifying the areas we can all agree on, and = allow > flexibility for those that we don't. It's an age old clich=E9, but = let's not > let perfect be the enemy of the good. >=20 > -John >=20 > On 2/16/13 12:42 PM, "Eric Burger" = wrote: >=20 >> What is the justification for both numeric and enumerated values=20 >> (low/medium/high)? In general such a schema is begging for=20 >> interoperability problems. >>=20 >> I suppose I can understand both sides of the argument. On the We = Need=20 >> Numbers side is those that actually calculate a percentage or other=20= >> objective measure in the confidence may want to use those real = numbers. >> As well, on the We Need Numbers side is the argument that three=20 >> enumerated values may not prove sufficient in the future. On the We=20= >> Need Enumerated Values side is confidence, other than 0% and 100%, = tend=20 >> to be arbitrary guesses. Putting a number on this value imparts a = level=20 >> of specificity that does not exist. Also, it is a lot easier to map=20= >> 'low' to 'low' than it is to map 0-33 to 'low'. >>=20 >> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >> wrote: >>=20 >>> That will work provided I (and everyone else) has a mapping for the=20= >>> numbers. I would prefer a simple low/med/high scheme. The more we = add=20 >>> the more you have to be able to differentiate between them. However=20= >>> for potential interoperability I do see the benefit of the 5. >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>> From: Moriarty, Kathleen >>> Sent: Wednesday, February 13, 2013 2:05 PM >>> To: Harrington, Christopher; MILE IETF >>> Subject: RE: [mile] IOCs >>>=20 >>>=20 >>> If you think of IODEF just for transport, could you meet your needs=20= >>> with storing the values differently in a database (IODEF is just = meant=20 >>> for the exchange)? The numbers map to low/med/high - for db storage = -=20 >>> if numbers are used, you could store the equivalent value, adding = the=20 >>> 2 additional ones provided. >>>=20 >>> Does it make sense to expand the set of values to match what CIF is=20= >>> doing if we went forward with the approach of supporting both = options? >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of Harrington, Christopher >>> Sent: Wednesday, February 13, 2013 11:49 AM >>> To: 'C. Henry Adams & BIE'; MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> =46rom a data processing standpoint it is going to create extra work=20= >>> for the people who are going to receive this data if we support both=20= >>> numeric and alpha characters in the same field. I can envision = people=20 >>> wanting to search, sort, store, etc the data in this field. If we=20 >>> allow both data types then everyone will need to have a mapping of=20= >>> some sort. I have a field for confidence in my threat tracking=20 >>> database. Having both a numeric score and alpha characters / words=20= >>> creates issues when trying to interact with the data. I agree that = we=20 >>> need to support both however I don't think both should be in the = same=20 >>> field. I would much rather see 2 different fields for Confidence if = we=20 >>> are going to support 2 different data types. >>>=20 >>> This will be a larger issue should Confidence be used elsewhere. >>> Ideally in future revisions I would like to see attribution = expressed=20 >>> as some form of attribution is almost always shared with an IoC. >>> Currently there are 5 areas where we (EMC) uses confidence. >>>=20 >>> Indicator (how confident are you that this is a valid IoC) =20 >>> Indicator_Set (how confident are you that all of the indcators in = the=20 >>> set should be in the set) Campaign (how confident are you that all=20= >>> Indicator_Sets are part of this campaign) Threat Actor (how = confident=20 >>> are you that the Campaign is attributed to this Threat Actor) = Threat=20 >>> Actor type (how confident are you that this Theat Actor is APT,=20 >>> Crimeware, other) >>>=20 >>> The threat actor name and the threat actor type are usually the = first=20 >>> 2 things that anyone processing IoCs wants to know as they drive = priority. >>> Knowing how sure the sender is that this IoC is APTis a vital piece=20= >>> of information for us. Sorry to take us a little off the path but I=20= >>> wanted to show where Confidence could be used. >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of C. Henry Adams & BIE >>> Sent: Wednesday, February 13, 2013 10:24 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> Again, I would concur that both a numeric and subjective analysis of=20= >>> the Confidence Rating needs to be express, but combined in a=20 >>> simplified schema as such below: >>>=20 >>> 1LL .... etc. >>>=20 >>> 2P >>>=20 >>> 3AC >>>=20 >>> 4U >>>=20 >>> 5I >>>=20 >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>>=20 >>> Here's my point, perhaps a set of numeric related or associated=20 >>> definitions can lower the propagation of error regarding the = analysis. >>>=20 >>> Thanks, >>> C. Henry Adams >>>=20 >>>=20 >>> I agree that what we really need is both. In most situations a low,=20= >>> medium and high may be acceptable but there are times when we will=20= >>> want to show that confidence in a situation is increasing or=20 >>> decreasing. If we are only looking at a three levels, we cannot=20 >>> express what is needed to show confidence is trending up on the data=20= >>> being exchanged about the event. >>>=20 >>> Kathleen included the following in a previous message. >>>=20 >>> >>>=20 >>> Vs: >>>=20 >>> 85 >>>=20 >>> I really think we need to include both capabilities as John alluded=20= >>> to since confidence is not a three tiered item but something that is=20= >>> indeed subjective and we need a means to show a reasonably accurate=20= >>> confidence index that the sender is trying to convey. >>>=20 >>> Kent Landfield >>>=20 >>> McAfee | An Intel Company >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>>=20 >>> From: , John Banghart >>> Date: Wednesday, February 13, 2013 7:16 AM >>> To: "Stoecker, Paul" , Kathleen Moriarty=20 >>> , Brian Trammell = >>> Cc: "C. Henry Adams & BIE" , MILE IETF=20 >>> >>> Subject: Re: [mile] IOCs >>>=20 >>> Paul, >>>=20 >>> I agree that confidence is subjective, but subjectivity can be=20 >>> reduced within communities that interact frequently. = Prioritization=20 >>> of indicators and response between tightly connected sharing = partners=20 >>> might require a more specific level of detail, particularly during = a=20 >>> crisis situation. >>>=20 >>> =46rom that perspective, I think the guidance should allow for=20 >>> additional granularity, while stressing the "high, medium, low" as=20= >>> preferred for broad interoperability. >>>=20 >>> -John >>>=20 >>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>=20 >>> I may have been too succinct in my response ;-) >>>=20 >>> Confidence is a subjective thing, so I think we should use = subjective >>> terms: Low, Medium, High. Having a numeric scale with a map that=20= >>> essentially would say something like: >>>=20 >>> 1-33 =3D Low >>> 34-67=3D Medium >>> 68-100=3DHigh >>>=20 >>> Is just a more complicated way of saying that something is Low,=20 >>> Medium, High...do we really thing that how High something is makes=20= >>> that much of a difference? >>>=20 >>> This is like when you get your Performance review where it is Does=20= >>> Not Meet, Meets and Exceeds...your boss tells you that you are a = High=20 >>> Meets...your bonus tells you that you got the same bonus that all = the=20 >>> other Meets got >>> ;-) >>>=20 >>> Anyway, I digress but trying to prove a point that I would argue = that =20 >>> confidence in this case is going to be basically a gut feeling, so = why=20 >>> use numeric values when Low, Medium, High would do just fine. >>>=20 >>>=20 >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>> wrote: >>>=20 >>> Hello, >>>=20 >>> Both approaches will validate in the current schema. The=20 >>> representation looks a little different for each, here is an = example: >>>=20 >>> >>>=20 >>> Vs: >>>=20 >>> 85 >>>=20 >>> Searching capability is a great point, agreed. I'd like to hear = from=20 >>> more people to make sure we don't lose a capability that others find=20= >>> extremely useful (need to gauge that). Other options is that the=20 >>> guidance can also discourage the use of the numeric in addition to=20= >>> specifying how to select ranges. >>>=20 >>> Any other opinions? >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> -----Original Message----- >>> From: Stoecker, Paul >>> Sent: Wednesday, February 13, 2013 7:14 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> Cant we make Confidence a List that has only 3 values: High, = Medium,=20 >>> and Low? Any other value means that the Document will mot validate=20= >>> against the schema. >>>=20 >>> Sent from my iPhone >>>=20 >>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell"=20 >>> >>> wrote: >>>=20 >>> Hi, Kathleen, all, >>>=20 >>> I think 3.10.4 in 5070 takes the right approach here: trying to = build=20 >>> interoperable numeric scales for assessment is a very hard problem. >>> (Were I charged with defining such a scale, the value "70" would = mean=20 >>> "we compared this incident report to N past similar incident reports=20= >>> according to similarity algorithm S, and 70% of the past reports had=20= >>> assessed impacts within E% of the actual, measured final impact -- I=20= >>> think for most applications this is vastly more difficult and=20 >>> rigorous than it needs to be.) >>>=20 >>> Unless a numeric Confidence value is based on some actual, = repeatably=20 >>> measurable aspect of the Assessment report -- which I suspect in=20 >>> many/most/all cases it's not -- then it just represents a guess,=20 >>> however educated. Each team will probably naturally tune its own=20 >>> scales such that each value generally means the same thing in each=20= >>> report. Across teams, I don't know. >>>=20 >>> On the other hand, Assessments are by their very nature educated=20 >>> guesses, anyway, so I don't know that I'd find much use in = automating=20 >>> a response based on the assessment confidence. Chris has a good=20 >>> point, though -- it makes searching difficult and sorting kind of > pointless. >>>=20 >>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then = I=20 >>> agree, we should put that in the guidance document (along with a = note=20 >>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to=20 >>> high, unless we want to do it non-linearly). If the _vast_majority_=20= >>> of the users of this field use a 100-point scale with 100 meaning=20 >>> "yes" and 0 meaning "any resemblance these values may have to actual=20= >>> fact is purely coincidental", then let's consider renaming it = "percent" > in 5070-bis. >>>=20 >>> Best regards, >>>=20 >>> Brian (as contributor) >>>=20 >>>=20 >>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>> wrote: >>>=20 >>> Please see section 3.10.4 of RFC5070 as a starting point. We can=20 >>> change it if it needs to be changed. The value is for a confidence=20= >>> rating on the indicators shared. The definitions may be helpful for=20= >>> anyone who wants to work on this discussion. IODEF has various=20 >>> markers that can be used in a complimentary way without conflating=20= >>> the markers meaning. >>>=20 >>> I think some people using IODEF find the numerical values more=20 >>> helpful, and it would be good to understand what people have learned=20= >>> from using the current structure (what works/does not work). The=20 >>> scales I have seen are 0-100. There is of course a subjective=20 >>> element to assigning a numerical value to the confidence and it may=20= >>> vary from entity to entity. With this type of rating you may need = to=20 >>> consider who it came from and how they scored the confidence rating=20= >>> to map to your own rating. It would be good to hear more thoughts = on > this. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>> Sent: Tuesday, February 12, 2013 2:46 PM >>> To: MILE IETF >>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>> Subject: Re: [mile] IOCs >>>=20 >>>=20 >>> Regarding the IOCs or Indicators of Compromise, Chris made a vital=20= >>> point. Different Confidence levels will cause confusion. It = appears=20 >>> that there maybe a need for some type of simplified standardization=20= >>> to be established between all Sharing Groups in this regard. >>>=20 >>> Perhaps numerical scoring set at lower values should express levels=20= >>> of urgency. >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>>=20 >>> Thanks, >>> C. Henry Adams >>>=20 >>>=20 >>>=20 >>> I see some confusion coming down the pike if we start using=20 >>> Confidence the way it is supported. If I am using low/med/high and=20= >>> someone sends me an IoC with a score of 70, what does that mean to=20= >>> me? What if I am using a scale of >>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability=20= >>> to describe something with a consistent language. It really gets = ugly=20 >>> when we store IoC from multiple sources. I have confidence values=20 >>> that are numeric as well as text. Makes searching / sorting very=20 >>> problematic. >>>=20 >>> At this point we have to roll with what we have. I would strongly=20 >>> recommend that we revisit this at some point. >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Tuesday, February 12, 2013 9:59 AM >>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;=20 >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> Hi Chris & Take, >>>=20 >>> I'll just focus on the confidence scoring. Right now, the schema=20 >>> allows for you to either use a numerical score OR the ratings of = low,=20 >>> medium, and high. >>> Different sharing groups can decide how they want to share the data. >>> If >>> people were to use the numerical values, I agree it would be helpful=20= >>> to have guidance. This could go in the IODE guidance document. >>>=20 >>> I have seen examples of current users that use each of the=20 >>> approaches, so we'll need to keep the option for backwards=20 >>> compatibility and it is nice to keep in flexible options where we=20 >>> can. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> -----Original Message----- >>> From: Harrington, Christopher >>> Sent: Tuesday, February 12, 2013 9:22 AM >>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE=20= >>> IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> The number of indicators wouldn't necessarily drive the use of=20 >>> indicator_set_id. The purpose is to show relationship. If I sent 3 = IP=20 >>> addresses that were used as C2 for 3 different campaigns I would = have=20 >>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>=20 >>> My suggestion would be a simple low, medium, high. I think if we=20 >>> break it down to more levels than that we would need to provide=20 >>> guidance on scoring, rating, etc. I think most people should be able=20= >>> to understand low/med/high without having to have a mathematical=20 >>> method for arriving at the level. >>>=20 >>> Low - I am not sure >>> Medium - I am reasonably sure >>> High - I am very sure >>>=20 >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 12, 2013 4:21 AM >>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul;=20 >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> Regarding the indicator_set_id, I agree, it is useful when we need = to=20 >>> deal with large sets of indicators. >>> Since indicator_set_id attribute is optional (right?), it could be=20= >>> omitted if we need to deal with only small number of indicators. >>>=20 >>> Regarding the use case, I like the idea of using the confidence=20 >>> attribute for the reason Chris kindly described. >>> I would like to hear a bit more on this: is it going to be = numerical? >>> For >>> instance, 1 means "no confidence" while 5 means "strong confidence",=20= >>> etc? >>>=20 >>> Thank you. >>> Take >>>=20 >>>=20 >>> -----Original Message----- >>> From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] >>> Sent: Friday, February 08, 2013 4:11 AM >>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE=20 >>> IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> With respect to tying things back to threat actors, from what I have=20= >>> seen and use this is a generally accepted grouping: >>>=20 >>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>=20 >>> Campaign and Threat Actor are where having a "Confidence" attribute=20= >>> would be beneficial as making those associations is not a perfect=20 >>> science by any means. >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>>=20 >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Thursday, February 07, 2013 2:00 PM >>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; = 'MILE=20 >>> IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> Hi Take & others, >>>=20 >>> Thanks for chiming in, I've been talking about this with Chris and a=20= >>> few others on their use cases and would like more opinions. I'll=20 >>> provide an option below from what we have discussed from a CIRC view=20= >>> point. We are also wondering how to also provide logic in IODEF = that=20 >>> could cross over into SCI attached schemas or IODEF extensions (the=20= >>> solutions may all tie together with this discussion - or there may = be=20 >>> better/more elegant solutions others would like to propose). >>>=20 >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 05, 2013 12:04 PM >>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;=20 >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>>=20 >>> I like this discussion. >>> I agree, it would be good idea to have indicator identifiers inside=20= >>> the IOC-related classes. >>>=20 >>> KMM: At the class level, we may have several indicators listed that=20= >>> should be viewed as a set and may have another instance of that same=20= >>> class that is a related issue, but a separate set. We could as you=20= >>> say, list the indicator IDs connected through the reference class. >>> The set IDs might give us other ways to group the values when we get=20= >>> into logic and relationships between sets or indicators. This could=20= >>> also be a way to connect indicators or sets across XML documents = that=20 >>> could have been shared previously. If there are a large number of=20= >>> indicators in the set, then this becomes useful, for smaller sets, I=20= >>> agree it doesn't make as much sense. >>>=20 >>> What do others think? >>>=20 >>> Then for indicators not included in the base schema that may not fit=20= >>> into a category in the SCI draft, do we create a place for these off=20= >>> of SCI or right off of the IODE schema in EventData? >>> (more details >>> on >>> this in my first message). >>>=20 >>> If we could see any indicator of compromise as computer event = record,=20 >>> we could use SCI:EventReport class as the place for the XML-based=20 >>> IOCs that couldn't fit anywhere else. >>>=20 >>> KMM: That sounds like a good idea to me. This should go into=20 >>> guidance in the SCI draft. Does anyone else want to weigh in? >>>=20 >>>=20 >>> For the non-XML IOCs, we could use RecordData class, as suggested. >>> KMM: Sounds good, thanks! >>>=20 >>> I agree to have indicator_uid, but I am not sure about the needs of=20= >>> the indicator_set_id. >>> I understand we could do some grouping of individual indicator_uids=20= >>> and its usability, but I am not sure whether we do not have any = other=20 >>> way to express these groupings. >>> For instance, a Reference class refers to several indicadtor_uids. >>> In >>> this case, they could be, in a sense, grouped. Isn't it enough? >>>=20 >>> KMM: It may be, what do you think about large sets of indicators or=20= >>> subsequent messages that add indicators to existing sets? Would = this=20 >>> happen? Would it be easier to express relationships with sets of=20 >>> indicators in addition to individual indicators? By using this, it=20= >>> could give us a unique way to also provide the logic and=20 >>> relationships in a new class of IODEF so we don't have to worry = about=20 >>> adding it into the current structure. >>> If there are better ways to handle that, and others can provide some=20= >>> options, that would be appreciated! >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> I would appreciate if anybody could share expertise on this. Though = I=20 >>> think I have read all the emails in the list, I might have=20 >>> mis-understood some points. >>>=20 >>> By the way, I think the indicator_uids should be added to the SCI=20 >>> classes' >>> attributes so that they can be correlated with another information = as=20 >>> well. >>>=20 >>> Thanks >>> Take >>>=20 >>>=20 >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of Harrington, Christopher >>> Sent: Tuesday, February 05, 2013 4:25 AM >>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> I think some sort of group ID would do the trick. We also need a=20 >>> logical and / or somewhere to show relationship between indicators. >>> If >>> I give you >>> 2 >>> registry keys do they both have to be present to be an indication of=20= >>> compromise or is either one by themselves an indicator? Both would=20= >>> have the same group ID since they are related. >>>=20 >>> Thanks, >>> --Chris >>>=20 >>> From: Stoecker, Paul >>> Sent: Sunday, February 03, 2013 8:26 PM >>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> What if we added indicator group ID along with the indicator_uid? >>> This would allow you to group indicators that are related into the=20= >>> same group ID. >>> Would this resolve the issue? >>>=20 >>> It is either that or going back to adding a Detection (or = Indicators)=20 >>> class that will should be used to take all of the indicators put = them=20 >>> into one place and have the ability to group the ones that go=20 >>> together. I don't mean a place to put indicators that are missing=20= >>> from IODEF.I mean a place in the IODEF document where you put the=20 >>> indicators that are used for detection and prevention of the shared=20= >>> Incident. I don't know the answer here, but there has got to be a=20= >>> good way for indicators to be identified and being able to group = them=20 >>> as Chris has suggested without basically recreating something=20 >>> complicated like STIX. >>>=20 >>> Paul >>>=20 >>>=20 >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>=20 >>>=20 >>> From: , Kathleen >>> Date: Sunday, February 3, 2013 5:11 PM >>> To: "Harrington, Christopher" , MILE=20= >>> IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> Hi Chris, >>>=20 >>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>=20 >>> The list has already said they would like to see indicators added to=20= >>> the definitions in RFC5070-bis, to be more explicit about including=20= >>> indicators and sets of indicators in IODE documents as opposed to=20 >>> 'parts of an incident or the useful information on an incident for=20= >>> sharing purposes. It was written before we used terms like=20 >>> indicators. With that in mind, Rosella proposed a number of changes=20= >>> back in July, both for guidance and for format updates. It may help=20= >>> to have the first draft try to address at least some of these issues=20= >>> so people can understand the problems and at least a proposed=20 >>> solution. >>>=20 >>> As you point out, we need to be able to show relationships between=20= >>> sets of indicators, where we may have a few sets of indicators that=20= >>> could have a relationship to each other within a document. In the=20= >>> July presentation, one of the questions was to see if we should add=20= >>> new category attribute values for the System class that would = connect=20 >>> the list of included indicators. I think we should still keep the=20= >>> concept of a Node to a single node, but perhaps within System, list=20= >>> multiple sets of Nodes that may be one type of attack. Rosella had=20= >>> suggested pulling forward the "FraudType" from RFC5901, this would=20= >>> help solve the issue as NodeRole values would compliment an=20 >>> AttackType (FraudType values could be included in AttackType or some=20= >>> broader term). It may be better to have the FraudTypes, plus=20 >>> attribute values like "C2-server", "sinkhole", = "MalwareDistribution"=20 >>> for added context so you know what to do with the received set of=20 >>> indicators. >>>=20 >>> I am proposing that we change IODEF to include multiple sets of=20 >>> indicators, add an AttackType attribute (or some other name), a=20 >>> method to connect indicators and indicator sets within an IODEF = using=20 >>> an attribute of indicator_uid (or some other name) with a string=20 >>> value to make the connection points, and add a few indicators that=20= >>> are commonly shared into the base IODEF. >>>=20 >>> Back in July, we talked about adding Registry Key/Value pairs and=20 >>> hashes to the main IODEF document (trying to see if this will help=20= >>> Chris below). What if we added the Registry Key/Value pairs as a=20 >>> class off of RecordData, using a similar structure to what is in=20 >>> RFC5901, and also added the ability to include hashes in RecordData? >>> I think if we then had the indicator_uid at the RecordData level, we=20= >>> could connect a set within that structure and repeat the structure=20= >>> for other sets in the same way we would do with Node inside of the=20= >>> System class, using the indicator_uid to tie the set together. Then=20= >>> at the more specific level for the hash, registry Key/value, IP, = etc.=20 >>> use an indicator_uid if we needed them marked at this level as well? = =20 >>> Maybe we want indicator_set at the higher level? I'd like some=20 >>> opinions on this approach. +1 if you agree, suggestions if you have=20= >>> other ideas that may work better. >>>=20 >>> We'll also need to worry about marking the indicators to prevent=20 >>> forward sharing when not permitted. We may want to use these values=20= >>> or something else. >>>=20 >>> Thank you! >>> Kathleen >>>=20 >>> From: Harrington, Christopher >>> Sent: Friday, February 01, 2013 12:01 PM >>> To: Moriarty, Kathleen; MILE IETF >>> Subject: RE: [mile] IOCs >>>=20 >>> I think we have a bigger relationship issue to address. Let use the=20= >>> Watchlist Use Case. A bunch of indicators are sent in one message. = In=20 >>> that message we could have groupings of indicators that we need to=20= >>> show are >>> related: >>>=20 >>> Two or more indicators of different type that relate to the same >>> threat: >>> The file hash of a malicious file and the URL of the C2 that=20= >>> the file uses. Either or both may be present to indicate a=20 >>> compromise. >>>=20 >>> Two or more indicators of the same type that relate to the same >>> threat: >>> 2 different registry values for the same registry key. If=20 >>> either value is present it is a compromise indicator but both will=20= >>> not be present. >>>=20 >>> The problem compounds itself very quickly. Consider the scenario=20 >>> where both groupings above are part of the same threat. I need to=20 >>> show that logical groupings of Indicators are related as well. We=20 >>> can't send multiple IODEF messages for this from what I remember=20 >>> reading. >>>=20 >>> The last one I can think of would be when you have 2 different=20 >>> indicators that represent the same indicator. It's not uncommon to=20= >>> send both the >>> MD5 >>> and SHA1 hash of a malicious file. The indicator is the file but the=20= >>> IOCs are the 2 hash values. How do we show they are related? If we=20= >>> use a unique Inidcator ID for each hash value there needs to be a=20 >>> higher level grouping. >>>=20 >>> Thoughts? >>>=20 >>> Thanks, >>>=20 >>> --Chris >>>=20 >>> Christopher Harrington >>> Consulting Security Engineer >>> GSO - Critical Incident Response Center EMC - Where Information = Lives >>> 174 Middlesex Turnpike >>> Bedford, MA 01730 >>> 781-515-5862 (work) >>> 603-583-1585 (cell) >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of Moriarty, Kathleen >>> Sent: Friday, February 01, 2013 11:28 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> All - >>>=20 >>> I'd like your input and will refocus the thread to get opinions from=20= >>> the list on options to help solve the problems raised in my message=20= >>> and additionally in Paul's message. >>>=20 >>> Interesting point, C. Henry. Our objective here is to have machine=20= >>> automated exchanges, so we rely on encryption rather than = obfuscation=20 >>> to achieve the necessary level of confidentiality. >>>=20 >>> Paul mentioned the need to distinguish indicators of compromise from=20= >>> context information that may also include IP address or other data=20= >>> that could be indicators. The question I raised was on how to=20 >>> connect sets of indicators in the same IODEF document, assuming the=20= >>> ability to have watchlists that could have several sets of = indicators=20 >>> included, as well as to connect indicators that may be included in=20= >>> embedded schemas. >>>=20 >>> If we add an attribute on all of the relevant indicators, let's say=20= >>> 'indicator-uid' how do we mark the indicators? Do we use this to=20 >>> mark who sent the indicator as well so that we can prevent forward=20= >>> sharing when it is not permitted or handle that separately? >>>=20 >>> Then for indicators not included in the base schema that may not fit=20= >>> into a category in the SCI draft, do we create a place for these off=20= >>> of SCI or right off of the IODE schema in EventData? (more details = on=20 >>> this in my first message). >>>=20 >>> Comments and questions encouraged to figure out the right technical=20= >>> solution to have this machine automatable. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of C. >>> Henry Adams & BIE >>> Sent: Monday, January 28, 2013 11:25 PM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>>=20 >>> Temporal Dependency sounds interesting. I remember when I first ran=20= >>> across this particular craft, an experienced colleague asked me a=20 >>> peculiar question. He said, " How do you stop someone from tracking=20= >>> the IP Address to your computer?" >>>=20 >>> I replied, "I don't know, how?" >>>=20 >>> Then he said, "Cut the dog-gone thing off and the modem that it is >>> connected- which is constantly on!" LOL >>>=20 >>> Here's my point (Hypothetical Situation) : There is a 1st Responder=20= >>> searching a Neighborhood for Survivors which were hit by a Disaster=20= >>> or let's just say "Live" Terrorist Situation. He /or She needs to=20= >>> communication back to other Officials that he /or somehow is in=20 >>> Danger. The device used to communicate has been captured by the=20 >>> great minds of the enemy. It's only a matter of time before they=20 >>> utilize reverse engineering to figure out how it functions. = However,=20 >>> their pride comes before a fall when seeking the location of other=20= >>> similar devices to attack. Why? Perhaps the less thought of = concepts=20 >>> that makes the device function properly, saves the day by disguise = or=20 >>> cutting it off (figuratively speaking). >>>=20 >>> Just a visionary thought. >>>=20 >>> C. Henry Adams >>> chenryadams@biemediagroup.com >>> http://biemediagroup.com >>>=20 >>>=20 >>> The information contained herein is for the exclusive use of the=20 >>> original recipient. This information is granted for limited=20 >>> distribution within the recipient's place of business for planning=20= >>> purposes only. Further dissemination, whether private or public is=20= >>> prohibited. >>>=20 >>> --- On Mon, 1/28/13, Dave Misell wrote: >>>=20 >>> From: Dave Misell >>> Subject: Re: [mile] IOCs >>> To: "C. Henry Adams & BIE" >>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with=20= >>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>=20 >>> Yours Faithfully, >>>=20 >>> Dave Misell MSc CISSP >>> SilentCircle dsm >>> 07710 380044 >>> david.misell@bcs.org >>>=20 >>>=20 >>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE=20 >>> >>> wrote: >>>=20 >>> Serialization of a particular Lists of XML Classes in a unique way=20= >>> was closely related to what I attempted to express when I stated,=20 >>> "consider to a degree what appears to be illogical in brilliant = minds=20 >>> in some instances." >>>=20 >>> However, I see Dr. Stoecker's point a little clearer. However, it=20= >>> would be nice if the UID was in some way disguised from those who=20 >>> study this Security Art Form in a negative way. >>>=20 >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>=20 >>>=20 >>> The information contained herein is for the exclusive use of the=20 >>> original recipient. This information is granted for limited=20 >>> distribution within the recipient's place of business for planning=20= >>> purposes only. Further dissemination, whether private or public is=20= >>> prohibited. >>>=20 >>> Re: [mile] IOCs >>>=20 >>> Sunday, January 27, 2013 8:52 PM >>> From: >>> "Stoecker, Paul" >>> To: >>> "mile@ietf.org" >>> I would like to look at this from a slightly different=20 >>> perspective=A9let's say I get an XML document that tells me about an=20= >>> incident. This document has source IP and destination IP that is=20 >>> being shared. However, what I don't know is which IP address is my=20= >>> indicator and which is just a contextual piece of information. This=20= >>> means that my detection product isn't going to know which one to use=20= >>> either, because there is nothing to tell me which IP is the one, = even=20 >>> if the roles are set it still might not be enough to tell my system=20= >>> which one I should use as the indicator. >>>=20 >>> If we had something like indicator_id as an attribute, it would = allow=20 >>> us to easily identify indicators from contextual data. I do admit = to=20 >>> being biased as I have spent much of my career working on the=20 >>> monitoring and detection side of these things, so I am just thinking=20= >>> of ways to make it very clear what the indicators are in the XML=20 >>> document and the other data that may be important as I investigate=20= >>> activity that I have detected off of those indicators. >>>=20 >>>=20 >>> I did suggest the detection class, but I think we may get more=20 >>> flexibility with the indicator_uid. One thing that I haven't=20 >>> considered is the UID portion of this=A9how do we use that UID? How = is=20 >>> the UID created? Are there standards for UIDs? >>>=20 >>> Regards, >>>=20 >>> Paul >>>=20 >>>=20 >>>=20 >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>=20 >>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>> wrote: >>>=20 >>> From: C. Henry Adams & BIE >>> Subject: RE: [mile] IOCs >>> To: "KathleenMoriarty" >>> Cc: mile@ietf.org >>> Date: Saturday, January 26, 2013, 6:17 PM >>>=20 >>> Greetings Kathleen, >>>=20 >>> Your logic stimulates my visionary brain because I'm amazed at the=20= >>> many avenues you review with this approach at once. However, could=20= >>> you share a few advantages and disadvantages to the latter? >>> -------------------------------------------------------------------- >>> -------- >>> ---------------------------------------------- >>> "we could continue to group items in logical places as is done now = in=20 >>> IODEF and then have the extension point for combined indicators via=20= >>> SCI." >>> -------------------------------------------------------------------- >>> -------- >>> --------------------------------------------- >>>=20 >>> You pointed out what you consider to be logical places, but if I=20 >>> wanted to protect information from parties capable of ascertaining = it=20 >>> from your logical places, perhaps we should also consider to a = degree=20 >>> what appears to be illogical in brilliant minds in some instances. >>>=20 >>>=20 >>>=20 >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>>=20 >>> The information contained herein is for the exclusive use of the=20 >>> original recipient. This information is granted for limited=20 >>> distribution within the recipient's place of business for planning=20= >>> purposes only. Further dissemination, whether private or public is=20= >>> prohibited. >>>=20 >>> --- On Sat, 1/26/13, Moriarty, Kathleen >>> wrote: >>>=20 >>> From: Moriarty, Kathleen >>> Subject: RE: [mile] IOCs >>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>> >>> Date: Saturday, January 26, 2013, 10:13 AM >>>=20 >>> Hello C. Henry & others, >>>=20 >>> Thanks for taking a look at this. We have a few considerations in=20= >>> this email thread I would like to hear thoughts on (and there may be=20= >>> more once RFC5070-bis is actively edited). >>>=20 >>> The AdditionalData class and the RecordItem class both allow for=20 >>> non-XML extensions. Where you place the extensions should be=20 >>> specific to the logical grouping of the parent elements so you can=20= >>> understand more about the included data in most cases. >>>=20 >>> The Impact class can be used to provide context information on the=20= >>> included data of the report and also can include a confidence rating=20= >>> on the report as a whole. Extensions related to impact would be one=20= >>> level higher (at the moment) in the Assessment class using the=20 >>> AdditionalData extension point. >>>=20 >>> Take asked about including vulnerability information, I would think=20= >>> that would fit under the Vulnerability extension point of the SCI=20 >>> draft in the Method class. He did ask about non-XML. RecordItem or=20= >>> AdditionalData do allow for non-XML extension points, we could = either=20 >>> have the SCI draft handle these as well or have the extensions that=20= >>> are non-XML come directly off the AdditionalData or RecordItem=20 >>> classes according to what makes sense from a logical standpoint. >>>=20 >>> As for my question, it was two-fold. >>>=20 >>> Indicator based schemas have a reference number or a GUID for the=20 >>> various indicators they share. If we are extending to embed other=20= >>> schemas that include such reference or GUID identifiers, do we want=20= >>> to add an attribute to the various elements in IODEF that could be=20= >>> indicators? Is this enough to make the connections or is something=20= >>> else else needed? We could add something like an Indicator_ID in=20 >>> RFC5070-bis which would then correlate to the reference or GUID=20 >>> identifiers. >>>=20 >>> Then the other question was on how to include indicators that are = not=20 >>> in the base schema that may be related or have language with "and"=20= >>> "or" >>> to >>> specify the relationships. In some cases, you will want to group=20 >>> these indictors in one extension point, where they may fit logically=20= >>> in multiple places if the relationships did not need to be shown in=20= >>> the data format. If we have cases like this where you need more=20 >>> complex representations, should we use one extension point via the=20= >>> SCI draft off of the EventData class AdditionalData extension point? = =20 >>> Opinions are needed here.... >>>=20 >>> A few people have mentioned wanting to include some commonly shared=20= >>> indictors into the base IODEF document. We could have a catch-all=20= >>> class that does this and has an extension point off of it in=20 >>> EventData or we could continue to group items in logical places as = is=20 >>> done now in IODEF and then have the extension point for combined=20 >>> indicators via SCI. I think I like the latter approach. >>>=20 >>> Thank you, >>> Kathleen >>> ________________________________________ >>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>> Henry >>> Adams & BIE [chatlga2000@yahoo.com] >>> Sent: Saturday, January 26, 2013 3:05 AM >>> To: mile@ietf.org >>> Cc: C. Henry Adams >>> Subject: Re: [mile] IOCs >>>=20 >>> Greetings Everyone, >>>=20 >>> Take mentioned two types of indicators based on the : >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>> 1) If the indicators are something like an XML-based alert/warning = of=20 >>> information leakage, it could be an event that are conveyed in the=20= >>> SCI's EventReport class, IMHO. >>>=20 >>> 2) If the indicators are something like an non-XML ones, I guess it=20= >>> could be conveyed without using SCI draft. >>> For instance, we could use Impact class of the base IODEF to convey=20= >>> the indicators. >>> We could for instance extend the list of indicators of the Impact=20 >>> class, if needed. >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>>=20 >>> In doing so he pointed out the "Impact Class" >>>=20 >>> Whereas, Kathleen stated, >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------- >>> For the discussion below, I was thinking more of combined set with=20= >>> relationships that may be included in a single extension point, so=20= >>> that's why I was thinking about the EventData class, but there may = be=20 >>> better locations or a specific area within the EventData. >>>=20 >>> Paul Stoecker had suggested a "Detection" class as a consideration. >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------ >>>=20 >>> Kathleen thoughts related yet still with other indicators and the=20 >>> EventData Class. >>>=20 >>> Is there a possible way to create a new XML class which encompass=20 >>> combining the EventData, Detection and base IODEF classes to = simplify=20 >>> this issue? >>>=20 >>>=20 >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>>=20 >>>=20 >>> The information contained herein is for the exclusive use of the=20 >>> original recipient. This information is granted for limited=20 >>> distribution within the recipient's place of business for planning=20= >>> purposes only. Further dissemination, whether private or public is=20= >>> prohibited. >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 From kathleen.moriarty@emc.com Tue Feb 19 04:43:00 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF2321F8801 for ; Tue, 19 Feb 2013 04:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysr8Zk6vbwVR for ; Tue, 19 Feb 2013 04:42:57 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3421F87B1 for ; Tue, 19 Feb 2013 04:42:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JCgq6L013309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 07:42:56 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 19 Feb 2013 07:42:35 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JCgZBf006491; Tue, 19 Feb 2013 07:42:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Tue, 19 Feb 2013 07:42:34 -0500 From: "Moriarty, Kathleen" To: Eric Burger , MILE IETF Date: Tue, 19 Feb 2013 07:40:51 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4Onh4tazf4b6iWQnWogtdaR7QJBQAADuFw Message-ID: References: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> , <8D7AF2C8-0529-475A-9125-BAF40F2D5F67@standardstrack.com> In-Reply-To: <8D7AF2C8-0529-475A-9125-BAF40F2D5F67@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 12:43:00 -0000 Should we provide guidance similar or the same as what CIF uses (was posted= to the list previously)? They use direct mapping to 5 levels so that you = can have ranges of numeric values used from 0-100, low to high. This would= be the easiest solution... Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric Burge= r [eburger-l@standardstrack.com] Sent: Tuesday, February 19, 2013 7:38 AM To: MILE IETF Subject: Re: [mile] IOCs If there really is no value to a value, do not let people hurt themselves. If there is a proprietary reason for a value, we should say what we mean an= d call it such. For example: This is XML so put your NON-INTEROPERABL= E mumble you want here or 42 or balderdash<= /mydom:meansSomethingToMe> On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" wrote: > I would agree that flexibility is something to strive for. However there > isn't enough in the RFC to make the numeric confidence value understood b= y > the recipient and therefore actionable. From the spec: > > "numeric. The element content contains a number that conveys the confide= nce > of the data. The semantics of this number outside the scope of this > specification" > > Based on that I can score my confidence with 1 being most confident and 1= 00 > being least. Perfectly legitimate but would probably mess everybody up. W= hat > if my scale is 1000 and yours is 100. I send you something with a score o= f > 100 you will think I am absolutely certain when I am only 10% so. Knowing > how sure the sender is about a piece of data shared is critical. If the > sender puts an arbitrary number in the field I have no point of reference= . > It's meaningless to me. > > We spell out what the relative value is for low/med/high. I know those ar= e > self-explanatory but they are still spelled out. I would urge that we do = the > same for a numeric value. If not there needs to be something added so tha= t > in addition to the numeric value I have a point of reference for how cert= ain > you are based on the number you put there. > > Thanks, > > --Chris > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Banghart, John > Sent: Monday, February 18, 2013 7:42 AM > To: Eric Burger; MILE IETF > Subject: Re: [mile] IOCs > > Eric, > > Well, I think you answered your own initial question, but I'm going to ju= mp > in anyway. :) > > Generally speaking, I think we want to strike a balance between > standardization and flexibility. We are unlikely to arrive at any sort o= f > one-size-fits-all scheme, no matter how long we talk about it. Instead, = we > should be focusing on solidifying the areas we can all agree on, and allo= w > flexibility for those that we don't. It's an age old clich=E9, but let's= not > let perfect be the enemy of the good. > > -John > > On 2/16/13 12:42 PM, "Eric Burger" wrote: > >> What is the justification for both numeric and enumerated values >> (low/medium/high)? In general such a schema is begging for >> interoperability problems. >> >> I suppose I can understand both sides of the argument. On the We Need >> Numbers side is those that actually calculate a percentage or other >> objective measure in the confidence may want to use those real numbers. >> As well, on the We Need Numbers side is the argument that three >> enumerated values may not prove sufficient in the future. On the We >> Need Enumerated Values side is confidence, other than 0% and 100%, tend >> to be arbitrary guesses. Putting a number on this value imparts a level >> of specificity that does not exist. Also, it is a lot easier to map >> 'low' to 'low' than it is to map 0-33 to 'low'. >> >> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >> wrote: >> >>> That will work provided I (and everyone else) has a mapping for the >>> numbers. I would prefer a simple low/med/high scheme. The more we add >>> the more you have to be able to differentiate between them. However >>> for potential interoperability I do see the benefit of the 5. >>> >>> Thanks, >>> >>> --Chris >>> >>> From: Moriarty, Kathleen >>> Sent: Wednesday, February 13, 2013 2:05 PM >>> To: Harrington, Christopher; MILE IETF >>> Subject: RE: [mile] IOCs >>> >>> >>> If you think of IODEF just for transport, could you meet your needs >>> with storing the values differently in a database (IODEF is just meant >>> for the exchange)? The numbers map to low/med/high - for db storage - >>> if numbers are used, you could store the equivalent value, adding the >>> 2 additional ones provided. >>> >>> Does it make sense to expand the set of values to match what CIF is >>> doing if we went forward with the approach of supporting both options? >>> >>> Thank you, >>> Kathleen >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Harrington, Christopher >>> Sent: Wednesday, February 13, 2013 11:49 AM >>> To: 'C. Henry Adams & BIE'; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> From a data processing standpoint it is going to create extra work >>> for the people who are going to receive this data if we support both >>> numeric and alpha characters in the same field. I can envision people >>> wanting to search, sort, store, etc the data in this field. If we >>> allow both data types then everyone will need to have a mapping of >>> some sort. I have a field for confidence in my threat tracking >>> database. Having both a numeric score and alpha characters / words >>> creates issues when trying to interact with the data. I agree that we >>> need to support both however I don't think both should be in the same >>> field. I would much rather see 2 different fields for Confidence if we >>> are going to support 2 different data types. >>> >>> This will be a larger issue should Confidence be used elsewhere. >>> Ideally in future revisions I would like to see attribution expressed >>> as some form of attribution is almost always shared with an IoC. >>> Currently there are 5 areas where we (EMC) uses confidence. >>> >>> Indicator (how confident are you that this is a valid IoC) >>> Indicator_Set (how confident are you that all of the indcators in the >>> set should be in the set) Campaign (how confident are you that all >>> Indicator_Sets are part of this campaign) Threat Actor (how confident >>> are you that the Campaign is attributed to this Threat Actor) Threat >>> Actor type (how confident are you that this Theat Actor is APT, >>> Crimeware, other) >>> >>> The threat actor name and the threat actor type are usually the first >>> 2 things that anyone processing IoCs wants to know as they drive priori= ty. >>> Knowing how sure the sender is that this IoC is APTis a vital piece >>> of information for us. Sorry to take us a little off the path but I >>> wanted to show where Confidence could be used. >>> >>> Thanks, >>> >>> --Chris >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of C. Henry Adams & BIE >>> Sent: Wednesday, February 13, 2013 10:24 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Again, I would concur that both a numeric and subjective analysis of >>> the Confidence Rating needs to be express, but combined in a >>> simplified schema as such below: >>> >>> 1LL .... etc. >>> >>> 2P >>> >>> 3AC >>> >>> 4U >>> >>> 5I >>> >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>> >>> Here's my point, perhaps a set of numeric related or associated >>> definitions can lower the propagation of error regarding the analysis. >>> >>> Thanks, >>> C. Henry Adams >>> >>> >>> I agree that what we really need is both. In most situations a low, >>> medium and high may be acceptable but there are times when we will >>> want to show that confidence in a situation is increasing or >>> decreasing. If we are only looking at a three levels, we cannot >>> express what is needed to show confidence is trending up on the data >>> being exchanged about the event. >>> >>> Kathleen included the following in a previous message. >>> >>> >>> >>> Vs: >>> >>> 85 >>> >>> I really think we need to include both capabilities as John alluded >>> to since confidence is not a three tiered item but something that is >>> indeed subjective and we need a means to show a reasonably accurate >>> confidence index that the sender is trying to convey. >>> >>> Kent Landfield >>> >>> McAfee | An Intel Company >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>> >>> From: , John Banghart >>> Date: Wednesday, February 13, 2013 7:16 AM >>> To: "Stoecker, Paul" , Kathleen Moriarty >>> , Brian Trammell >>> Cc: "C. Henry Adams & BIE" , MILE IETF >>> >>> Subject: Re: [mile] IOCs >>> >>> Paul, >>> >>> I agree that confidence is subjective, but subjectivity can be >>> reduced within communities that interact frequently. Prioritization >>> of indicators and response between tightly connected sharing partners >>> might require a more specific level of detail, particularly during a >>> crisis situation. >>> >>> From that perspective, I think the guidance should allow for >>> additional granularity, while stressing the "high, medium, low" as >>> preferred for broad interoperability. >>> >>> -John >>> >>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>> >>> I may have been too succinct in my response ;-) >>> >>> Confidence is a subjective thing, so I think we should use subjective >>> terms: Low, Medium, High. Having a numeric scale with a map that >>> essentially would say something like: >>> >>> 1-33 =3D Low >>> 34-67=3D Medium >>> 68-100=3DHigh >>> >>> Is just a more complicated way of saying that something is Low, >>> Medium, High...do we really thing that how High something is makes >>> that much of a difference? >>> >>> This is like when you get your Performance review where it is Does >>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>> Meets...your bonus tells you that you got the same bonus that all the >>> other Meets got >>> ;-) >>> >>> Anyway, I digress but trying to prove a point that I would argue that >>> confidence in this case is going to be basically a gut feeling, so why >>> use numeric values when Low, Medium, High would do just fine. >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> >>> >>> >>> >>> >>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>> wrote: >>> >>> Hello, >>> >>> Both approaches will validate in the current schema. The >>> representation looks a little different for each, here is an example: >>> >>> >>> >>> Vs: >>> >>> 85 >>> >>> Searching capability is a great point, agreed. I'd like to hear from >>> more people to make sure we don't lose a capability that others find >>> extremely useful (need to gauge that). Other options is that the >>> guidance can also discourage the use of the numeric in addition to >>> specifying how to select ranges. >>> >>> Any other opinions? >>> >>> Thanks, >>> Kathleen >>> >>> -----Original Message----- >>> From: Stoecker, Paul >>> Sent: Wednesday, February 13, 2013 7:14 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Cant we make Confidence a List that has only 3 values: High, Medium, >>> and Low? Any other value means that the Document will mot validate >>> against the schema. >>> >>> Sent from my iPhone >>> >>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>> >>> wrote: >>> >>> Hi, Kathleen, all, >>> >>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>> interoperable numeric scales for assessment is a very hard problem. >>> (Were I charged with defining such a scale, the value "70" would mean >>> "we compared this incident report to N past similar incident reports >>> according to similarity algorithm S, and 70% of the past reports had >>> assessed impacts within E% of the actual, measured final impact -- I >>> think for most applications this is vastly more difficult and >>> rigorous than it needs to be.) >>> >>> Unless a numeric Confidence value is based on some actual, repeatably >>> measurable aspect of the Assessment report -- which I suspect in >>> many/most/all cases it's not -- then it just represents a guess, >>> however educated. Each team will probably naturally tune its own >>> scales such that each value generally means the same thing in each >>> report. Across teams, I don't know. >>> >>> On the other hand, Assessments are by their very nature educated >>> guesses, anyway, so I don't know that I'd find much use in automating >>> a response based on the assessment confidence. Chris has a good >>> point, though -- it makes searching difficult and sorting kind of > pointless. >>> >>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>> agree, we should put that in the guidance document (along with a note >>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>> high, unless we want to do it non-linearly). If the _vast_majority_ >>> of the users of this field use a 100-point scale with 100 meaning >>> "yes" and 0 meaning "any resemblance these values may have to actual >>> fact is purely coincidental", then let's consider renaming it "percent" > in 5070-bis. >>> >>> Best regards, >>> >>> Brian (as contributor) >>> >>> >>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>> wrote: >>> >>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>> change it if it needs to be changed. The value is for a confidence >>> rating on the indicators shared. The definitions may be helpful for >>> anyone who wants to work on this discussion. IODEF has various >>> markers that can be used in a complimentary way without conflating >>> the markers meaning. >>> >>> I think some people using IODEF find the numerical values more >>> helpful, and it would be good to understand what people have learned >>> from using the current structure (what works/does not work). The >>> scales I have seen are 0-100. There is of course a subjective >>> element to assigning a numerical value to the confidence and it may >>> vary from entity to entity. With this type of rating you may need to >>> consider who it came from and how they scored the confidence rating >>> to map to your own rating. It would be good to hear more thoughts on > this. >>> >>> Thanks, >>> Kathleen >>> >>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>> Sent: Tuesday, February 12, 2013 2:46 PM >>> To: MILE IETF >>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>> Subject: Re: [mile] IOCs >>> >>> >>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>> point. Different Confidence levels will cause confusion. It appears >>> that there maybe a need for some type of simplified standardization >>> to be established between all Sharing Groups in this regard. >>> >>> Perhaps numerical scoring set at lower values should express levels >>> of urgency. >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>> >>> Thanks, >>> C. Henry Adams >>> >>> >>> >>> I see some confusion coming down the pike if we start using >>> Confidence the way it is supported. If I am using low/med/high and >>> someone sends me an IoC with a score of 70, what does that mean to >>> me? What if I am using a scale of >>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>> to describe something with a consistent language. It really gets ugly >>> when we store IoC from multiple sources. I have confidence values >>> that are numeric as well as text. Makes searching / sorting very >>> problematic. >>> >>> At this point we have to roll with what we have. I would strongly >>> recommend that we revisit this at some point. >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Tuesday, February 12, 2013 9:59 AM >>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> Hi Chris & Take, >>> >>> I'll just focus on the confidence scoring. Right now, the schema >>> allows for you to either use a numerical score OR the ratings of low, >>> medium, and high. >>> Different sharing groups can decide how they want to share the data. >>> If >>> people were to use the numerical values, I agree it would be helpful >>> to have guidance. This could go in the IODE guidance document. >>> >>> I have seen examples of current users that use each of the >>> approaches, so we'll need to keep the option for backwards >>> compatibility and it is nice to keep in flexible options where we >>> can. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: Harrington, Christopher >>> Sent: Tuesday, February 12, 2013 9:22 AM >>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> The number of indicators wouldn't necessarily drive the use of >>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>> addresses that were used as C2 for 3 different campaigns I would have >>> separate indicator_set_ids, each with one of the 3 C2 IPs >>> >>> My suggestion would be a simple low, medium, high. I think if we >>> break it down to more levels than that we would need to provide >>> guidance on scoring, rating, etc. I think most people should be able >>> to understand low/med/high without having to have a mathematical >>> method for arriving at the level. >>> >>> Low - I am not sure >>> Medium - I am reasonably sure >>> High - I am very sure >>> >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 12, 2013 4:21 AM >>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> Regarding the indicator_set_id, I agree, it is useful when we need to >>> deal with large sets of indicators. >>> Since indicator_set_id attribute is optional (right?), it could be >>> omitted if we need to deal with only small number of indicators. >>> >>> Regarding the use case, I like the idea of using the confidence >>> attribute for the reason Chris kindly described. >>> I would like to hear a bit more on this: is it going to be numerical? >>> For >>> instance, 1 means "no confidence" while 5 means "strong confidence", >>> etc? >>> >>> Thank you. >>> Take >>> >>> >>> -----Original Message----- >>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>> Sent: Friday, February 08, 2013 4:11 AM >>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> With respect to tying things back to threat actors, from what I have >>> seen and use this is a generally accepted grouping: >>> >>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>> >>> Campaign and Threat Actor are where having a "Confidence" attribute >>> would be beneficial as making those associations is not a perfect >>> science by any means. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Thursday, February 07, 2013 2:00 PM >>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> Hi Take & others, >>> >>> Thanks for chiming in, I've been talking about this with Chris and a >>> few others on their use cases and would like more opinions. I'll >>> provide an option below from what we have discussed from a CIRC view >>> point. We are also wondering how to also provide logic in IODEF that >>> could cross over into SCI attached schemas or IODEF extensions (the >>> solutions may all tie together with this discussion - or there may be >>> better/more elegant solutions others would like to propose). >>> >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 05, 2013 12:04 PM >>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> I like this discussion. >>> I agree, it would be good idea to have indicator identifiers inside >>> the IOC-related classes. >>> >>> KMM: At the class level, we may have several indicators listed that >>> should be viewed as a set and may have another instance of that same >>> class that is a related issue, but a separate set. We could as you >>> say, list the indicator IDs connected through the reference class. >>> The set IDs might give us other ways to group the values when we get >>> into logic and relationships between sets or indicators. This could >>> also be a way to connect indicators or sets across XML documents that >>> could have been shared previously. If there are a large number of >>> indicators in the set, then this becomes useful, for smaller sets, I >>> agree it doesn't make as much sense. >>> >>> What do others think? >>> >>> Then for indicators not included in the base schema that may not fit >>> into a category in the SCI draft, do we create a place for these off >>> of SCI or right off of the IODE schema in EventData? >>> (more details >>> on >>> this in my first message). >>> >>> If we could see any indicator of compromise as computer event record, >>> we could use SCI:EventReport class as the place for the XML-based >>> IOCs that couldn't fit anywhere else. >>> >>> KMM: That sounds like a good idea to me. This should go into >>> guidance in the SCI draft. Does anyone else want to weigh in? >>> >>> >>> For the non-XML IOCs, we could use RecordData class, as suggested. >>> KMM: Sounds good, thanks! >>> >>> I agree to have indicator_uid, but I am not sure about the needs of >>> the indicator_set_id. >>> I understand we could do some grouping of individual indicator_uids >>> and its usability, but I am not sure whether we do not have any other >>> way to express these groupings. >>> For instance, a Reference class refers to several indicadtor_uids. >>> In >>> this case, they could be, in a sense, grouped. Isn't it enough? >>> >>> KMM: It may be, what do you think about large sets of indicators or >>> subsequent messages that add indicators to existing sets? Would this >>> happen? Would it be easier to express relationships with sets of >>> indicators in addition to individual indicators? By using this, it >>> could give us a unique way to also provide the logic and >>> relationships in a new class of IODEF so we don't have to worry about >>> adding it into the current structure. >>> If there are better ways to handle that, and others can provide some >>> options, that would be appreciated! >>> >>> Thank you, >>> Kathleen >>> >>> I would appreciate if anybody could share expertise on this. Though I >>> think I have read all the emails in the list, I might have >>> mis-understood some points. >>> >>> By the way, I think the indicator_uids should be added to the SCI >>> classes' >>> attributes so that they can be correlated with another information as >>> well. >>> >>> Thanks >>> Take >>> >>> >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Harrington, Christopher >>> Sent: Tuesday, February 05, 2013 4:25 AM >>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> I think some sort of group ID would do the trick. We also need a >>> logical and / or somewhere to show relationship between indicators. >>> If >>> I give you >>> 2 >>> registry keys do they both have to be present to be an indication of >>> compromise or is either one by themselves an indicator? Both would >>> have the same group ID since they are related. >>> >>> Thanks, >>> --Chris >>> >>> From: Stoecker, Paul >>> Sent: Sunday, February 03, 2013 8:26 PM >>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> What if we added indicator group ID along with the indicator_uid? >>> This would allow you to group indicators that are related into the >>> same group ID. >>> Would this resolve the issue? >>> >>> It is either that or going back to adding a Detection (or Indicators) >>> class that will should be used to take all of the indicators put them >>> into one place and have the ability to group the ones that go >>> together. I don't mean a place to put indicators that are missing >>> from IODEF.I mean a place in the IODEF document where you put the >>> indicators that are used for detection and prevention of the shared >>> Incident. I don't know the answer here, but there has got to be a >>> good way for indicators to be identified and being able to group them >>> as Chris has suggested without basically recreating something >>> complicated like STIX. >>> >>> Paul >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> >>> From: , Kathleen >>> Date: Sunday, February 3, 2013 5:11 PM >>> To: "Harrington, Christopher" , MILE >>> IETF >>> Subject: Re: [mile] IOCs >>> >>> Hi Chris, >>> >>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>> >>> The list has already said they would like to see indicators added to >>> the definitions in RFC5070-bis, to be more explicit about including >>> indicators and sets of indicators in IODE documents as opposed to >>> 'parts of an incident or the useful information on an incident for >>> sharing purposes. It was written before we used terms like >>> indicators. With that in mind, Rosella proposed a number of changes >>> back in July, both for guidance and for format updates. It may help >>> to have the first draft try to address at least some of these issues >>> so people can understand the problems and at least a proposed >>> solution. >>> >>> As you point out, we need to be able to show relationships between >>> sets of indicators, where we may have a few sets of indicators that >>> could have a relationship to each other within a document. In the >>> July presentation, one of the questions was to see if we should add >>> new category attribute values for the System class that would connect >>> the list of included indicators. I think we should still keep the >>> concept of a Node to a single node, but perhaps within System, list >>> multiple sets of Nodes that may be one type of attack. Rosella had >>> suggested pulling forward the "FraudType" from RFC5901, this would >>> help solve the issue as NodeRole values would compliment an >>> AttackType (FraudType values could be included in AttackType or some >>> broader term). It may be better to have the FraudTypes, plus >>> attribute values like "C2-server", "sinkhole", "MalwareDistribution" >>> for added context so you know what to do with the received set of >>> indicators. >>> >>> I am proposing that we change IODEF to include multiple sets of >>> indicators, add an AttackType attribute (or some other name), a >>> method to connect indicators and indicator sets within an IODEF using >>> an attribute of indicator_uid (or some other name) with a string >>> value to make the connection points, and add a few indicators that >>> are commonly shared into the base IODEF. >>> >>> Back in July, we talked about adding Registry Key/Value pairs and >>> hashes to the main IODEF document (trying to see if this will help >>> Chris below). What if we added the Registry Key/Value pairs as a >>> class off of RecordData, using a similar structure to what is in >>> RFC5901, and also added the ability to include hashes in RecordData? >>> I think if we then had the indicator_uid at the RecordData level, we >>> could connect a set within that structure and repeat the structure >>> for other sets in the same way we would do with Node inside of the >>> System class, using the indicator_uid to tie the set together. Then >>> at the more specific level for the hash, registry Key/value, IP, etc. >>> use an indicator_uid if we needed them marked at this level as well? >>> Maybe we want indicator_set at the higher level? I'd like some >>> opinions on this approach. +1 if you agree, suggestions if you have >>> other ideas that may work better. >>> >>> We'll also need to worry about marking the indicators to prevent >>> forward sharing when not permitted. We may want to use these values >>> or something else. >>> >>> Thank you! >>> Kathleen >>> >>> From: Harrington, Christopher >>> Sent: Friday, February 01, 2013 12:01 PM >>> To: Moriarty, Kathleen; MILE IETF >>> Subject: RE: [mile] IOCs >>> >>> I think we have a bigger relationship issue to address. Let use the >>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>> that message we could have groupings of indicators that we need to >>> show are >>> related: >>> >>> Two or more indicators of different type that relate to the same >>> threat: >>> The file hash of a malicious file and the URL of the C2 that >>> the file uses. Either or both may be present to indicate a >>> compromise. >>> >>> Two or more indicators of the same type that relate to the same >>> threat: >>> 2 different registry values for the same registry key. If >>> either value is present it is a compromise indicator but both will >>> not be present. >>> >>> The problem compounds itself very quickly. Consider the scenario >>> where both groupings above are part of the same threat. I need to >>> show that logical groupings of Indicators are related as well. We >>> can't send multiple IODEF messages for this from what I remember >>> reading. >>> >>> The last one I can think of would be when you have 2 different >>> indicators that represent the same indicator. It's not uncommon to >>> send both the >>> MD5 >>> and SHA1 hash of a malicious file. The indicator is the file but the >>> IOCs are the 2 hash values. How do we show they are related? If we >>> use a unique Inidcator ID for each hash value there needs to be a >>> higher level grouping. >>> >>> Thoughts? >>> >>> Thanks, >>> >>> --Chris >>> >>> Christopher Harrington >>> Consulting Security Engineer >>> GSO - Critical Incident Response Center EMC - Where Information Lives >>> 174 Middlesex Turnpike >>> Bedford, MA 01730 >>> 781-515-5862 (work) >>> 603-583-1585 (cell) >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Moriarty, Kathleen >>> Sent: Friday, February 01, 2013 11:28 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> All - >>> >>> I'd like your input and will refocus the thread to get opinions from >>> the list on options to help solve the problems raised in my message >>> and additionally in Paul's message. >>> >>> Interesting point, C. Henry. Our objective here is to have machine >>> automated exchanges, so we rely on encryption rather than obfuscation >>> to achieve the necessary level of confidentiality. >>> >>> Paul mentioned the need to distinguish indicators of compromise from >>> context information that may also include IP address or other data >>> that could be indicators. The question I raised was on how to >>> connect sets of indicators in the same IODEF document, assuming the >>> ability to have watchlists that could have several sets of indicators >>> included, as well as to connect indicators that may be included in >>> embedded schemas. >>> >>> If we add an attribute on all of the relevant indicators, let's say >>> 'indicator-uid' how do we mark the indicators? Do we use this to >>> mark who sent the indicator as well so that we can prevent forward >>> sharing when it is not permitted or handle that separately? >>> >>> Then for indicators not included in the base schema that may not fit >>> into a category in the SCI draft, do we create a place for these off >>> of SCI or right off of the IODE schema in EventData? (more details on >>> this in my first message). >>> >>> Comments and questions encouraged to figure out the right technical >>> solution to have this machine automatable. >>> >>> Thank you, >>> Kathleen >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of C. >>> Henry Adams & BIE >>> Sent: Monday, January 28, 2013 11:25 PM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Temporal Dependency sounds interesting. I remember when I first ran >>> across this particular craft, an experienced colleague asked me a >>> peculiar question. He said, " How do you stop someone from tracking >>> the IP Address to your computer?" >>> >>> I replied, "I don't know, how?" >>> >>> Then he said, "Cut the dog-gone thing off and the modem that it is >>> connected- which is constantly on!" LOL >>> >>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>> searching a Neighborhood for Survivors which were hit by a Disaster >>> or let's just say "Live" Terrorist Situation. He /or She needs to >>> communication back to other Officials that he /or somehow is in >>> Danger. The device used to communicate has been captured by the >>> great minds of the enemy. It's only a matter of time before they >>> utilize reverse engineering to figure out how it functions. However, >>> their pride comes before a fall when seeking the location of other >>> similar devices to attack. Why? Perhaps the less thought of concepts >>> that makes the device function properly, saves the day by disguise or >>> cutting it off (figuratively speaking). >>> >>> Just a visionary thought. >>> >>> C. Henry Adams >>> chenryadams@biemediagroup.com >>> http://biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> --- On Mon, 1/28/13, Dave Misell wrote: >>> >>> From: Dave Misell >>> Subject: Re: [mile] IOCs >>> To: "C. Henry Adams & BIE" >>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>> DNS SEC a pemanent and temporal key, with a temporal Id? >>> >>> Yours Faithfully, >>> >>> Dave Misell MSc CISSP >>> SilentCircle dsm >>> 07710 380044 >>> david.misell@bcs.org >>> >>> >>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>> >>> wrote: >>> >>> Serialization of a particular Lists of XML Classes in a unique way >>> was closely related to what I attempted to express when I stated, >>> "consider to a degree what appears to be illogical in brilliant minds >>> in some instances." >>> >>> However, I see Dr. Stoecker's point a little clearer. However, it >>> would be nice if the UID was in some way disguised from those who >>> study this Security Art Form in a negative way. >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> Re: [mile] IOCs >>> >>> Sunday, January 27, 2013 8:52 PM >>> From: >>> "Stoecker, Paul" >>> To: >>> "mile@ietf.org" >>> I would like to look at this from a slightly different >>> perspectiveSlet's say I get an XML document that tells me about an >>> incident. This document has source IP and destination IP that is >>> being shared. However, what I don't know is which IP address is my >>> indicator and which is just a contextual piece of information. This >>> means that my detection product isn't going to know which one to use >>> either, because there is nothing to tell me which IP is the one, even >>> if the roles are set it still might not be enough to tell my system >>> which one I should use as the indicator. >>> >>> If we had something like indicator_id as an attribute, it would allow >>> us to easily identify indicators from contextual data. I do admit to >>> being biased as I have spent much of my career working on the >>> monitoring and detection side of these things, so I am just thinking >>> of ways to make it very clear what the indicators are in the XML >>> document and the other data that may be important as I investigate >>> activity that I have detected off of those indicators. >>> >>> >>> I did suggest the detection class, but I think we may get more >>> flexibility with the indicator_uid. One thing that I haven't >>> considered is the UID portion of thisShow do we use that UID? How is >>> the UID created? Are there standards for UIDs? >>> >>> Regards, >>> >>> Paul >>> >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>> wrote: >>> >>> From: C. Henry Adams & BIE >>> Subject: RE: [mile] IOCs >>> To: "KathleenMoriarty" >>> Cc: mile@ietf.org >>> Date: Saturday, January 26, 2013, 6:17 PM >>> >>> Greetings Kathleen, >>> >>> Your logic stimulates my visionary brain because I'm amazed at the >>> many avenues you review with this approach at once. However, could >>> you share a few advantages and disadvantages to the latter? >>> -------------------------------------------------------------------- >>> -------- >>> ---------------------------------------------- >>> "we could continue to group items in logical places as is done now in >>> IODEF and then have the extension point for combined indicators via >>> SCI." >>> -------------------------------------------------------------------- >>> -------- >>> --------------------------------------------- >>> >>> You pointed out what you consider to be logical places, but if I >>> wanted to protect information from parties capable of ascertaining it >>> from your logical places, perhaps we should also consider to a degree >>> what appears to be illogical in brilliant minds in some instances. >>> >>> >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> --- On Sat, 1/26/13, Moriarty, Kathleen >>> wrote: >>> >>> From: Moriarty, Kathleen >>> Subject: RE: [mile] IOCs >>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>> >>> Date: Saturday, January 26, 2013, 10:13 AM >>> >>> Hello C. Henry & others, >>> >>> Thanks for taking a look at this. We have a few considerations in >>> this email thread I would like to hear thoughts on (and there may be >>> more once RFC5070-bis is actively edited). >>> >>> The AdditionalData class and the RecordItem class both allow for >>> non-XML extensions. Where you place the extensions should be >>> specific to the logical grouping of the parent elements so you can >>> understand more about the included data in most cases. >>> >>> The Impact class can be used to provide context information on the >>> included data of the report and also can include a confidence rating >>> on the report as a whole. Extensions related to impact would be one >>> level higher (at the moment) in the Assessment class using the >>> AdditionalData extension point. >>> >>> Take asked about including vulnerability information, I would think >>> that would fit under the Vulnerability extension point of the SCI >>> draft in the Method class. He did ask about non-XML. RecordItem or >>> AdditionalData do allow for non-XML extension points, we could either >>> have the SCI draft handle these as well or have the extensions that >>> are non-XML come directly off the AdditionalData or RecordItem >>> classes according to what makes sense from a logical standpoint. >>> >>> As for my question, it was two-fold. >>> >>> Indicator based schemas have a reference number or a GUID for the >>> various indicators they share. If we are extending to embed other >>> schemas that include such reference or GUID identifiers, do we want >>> to add an attribute to the various elements in IODEF that could be >>> indicators? Is this enough to make the connections or is something >>> else else needed? We could add something like an Indicator_ID in >>> RFC5070-bis which would then correlate to the reference or GUID >>> identifiers. >>> >>> Then the other question was on how to include indicators that are not >>> in the base schema that may be related or have language with "and" >>> "or" >>> to >>> specify the relationships. In some cases, you will want to group >>> these indictors in one extension point, where they may fit logically >>> in multiple places if the relationships did not need to be shown in >>> the data format. If we have cases like this where you need more >>> complex representations, should we use one extension point via the >>> SCI draft off of the EventData class AdditionalData extension point? >>> Opinions are needed here.... >>> >>> A few people have mentioned wanting to include some commonly shared >>> indictors into the base IODEF document. We could have a catch-all >>> class that does this and has an extension point off of it in >>> EventData or we could continue to group items in logical places as is >>> done now in IODEF and then have the extension point for combined >>> indicators via SCI. I think I like the latter approach. >>> >>> Thank you, >>> Kathleen >>> ________________________________________ >>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>> Henry >>> Adams & BIE [chatlga2000@yahoo.com] >>> Sent: Saturday, January 26, 2013 3:05 AM >>> To: mile@ietf.org >>> Cc: C. Henry Adams >>> Subject: Re: [mile] IOCs >>> >>> Greetings Everyone, >>> >>> Take mentioned two types of indicators based on the : >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>> 1) If the indicators are something like an XML-based alert/warning of >>> information leakage, it could be an event that are conveyed in the >>> SCI's EventReport class, IMHO. >>> >>> 2) If the indicators are something like an non-XML ones, I guess it >>> could be conveyed without using SCI draft. >>> For instance, we could use Impact class of the base IODEF to convey >>> the indicators. >>> We could for instance extend the list of indicators of the Impact >>> class, if needed. >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>> >>> In doing so he pointed out the "Impact Class" >>> >>> Whereas, Kathleen stated, >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------- >>> For the discussion below, I was thinking more of combined set with >>> relationships that may be included in a single extension point, so >>> that's why I was thinking about the EventData class, but there may be >>> better locations or a specific area within the EventData. >>> >>> Paul Stoecker had suggested a "Detection" class as a consideration. >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------ >>> >>> Kathleen thoughts related yet still with other indicators and the >>> EventData Class. >>> >>> Is there a possible way to create a new XML class which encompass >>> combining the EventData, Detection and base IODEF classes to simplify >>> this issue? >>> >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > 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 john.banghart@nist.gov Tue Feb 19 06:28:22 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F1321F8D12 for ; Tue, 19 Feb 2013 06:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj3SIQH1vf9Z for ; Tue, 19 Feb 2013 06:28:18 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4A94C21F8CF2 for ; Tue, 19 Feb 2013 06:28:18 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Feb 2013 09:28:14 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 19 Feb 2013 09:28:16 -0500 From: "Banghart, John" To: "Harrington, Christopher" , Eric Burger , MILE IETF Date: Tue, 19 Feb 2013 09:28:10 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4OrVuCLWxzTRhXQZeXeWLdevYcLw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:28:22 -0000 Chris, I guess I'm envisioning a circumstance where the "meaning" of the values is agreed to between sharing partners offline. But you are correct, that the spec should allow for the that meaning to be characterized. -John On 2/19/13 7:24 AM, "Harrington, Christopher" wrote: >I would agree that flexibility is something to strive for. However there >isn't enough in the RFC to make the numeric confidence value understood by >the recipient and therefore actionable. From the spec: > >"numeric. The element content contains a number that conveys the >confidence >of the data. The semantics of this number outside the scope of this >specification" > >Based on that I can score my confidence with 1 being most confident and >100 >being least. Perfectly legitimate but would probably mess everybody up. >What >if my scale is 1000 and yours is 100. I send you something with a score of >100 you will think I am absolutely certain when I am only 10% so. Knowing >how sure the sender is about a piece of data shared is critical. If the >sender puts an arbitrary number in the field I have no point of reference. >It's meaningless to me. > >We spell out what the relative value is for low/med/high. I know those are >self-explanatory but they are still spelled out. I would urge that we do >the >same for a numeric value. If not there needs to be something added so that >in addition to the numeric value I have a point of reference for how >certain >you are based on the number you put there. > >Thanks, > >--Chris > > >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Banghart, John >Sent: Monday, February 18, 2013 7:42 AM >To: Eric Burger; MILE IETF >Subject: Re: [mile] IOCs > >Eric, > >Well, I think you answered your own initial question, but I'm going to >jump >in anyway. :) > >Generally speaking, I think we want to strike a balance between >standardization and flexibility. We are unlikely to arrive at any sort of >one-size-fits-all scheme, no matter how long we talk about it. Instead, >we >should be focusing on solidifying the areas we can all agree on, and allow >flexibility for those that we don't. It's an age old clich=E9, but let's >not >let perfect be the enemy of the good. > >-John > >On 2/16/13 12:42 PM, "Eric Burger" wrote: > >>What is the justification for both numeric and enumerated values >>(low/medium/high)? In general such a schema is begging for >>interoperability problems. >> >>I suppose I can understand both sides of the argument. On the We Need >>Numbers side is those that actually calculate a percentage or other >>objective measure in the confidence may want to use those real numbers. >>As well, on the We Need Numbers side is the argument that three >>enumerated values may not prove sufficient in the future. On the We >>Need Enumerated Values side is confidence, other than 0% and 100%, tend >>to be arbitrary guesses. Putting a number on this value imparts a level >>of specificity that does not exist. Also, it is a lot easier to map >>'low' to 'low' than it is to map 0-33 to 'low'. >> >>On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >> wrote: >> >>> That will work provided I (and everyone else) has a mapping for the >>>numbers. I would prefer a simple low/med/high scheme. The more we add >>>the more you have to be able to differentiate between them. However >>>for potential interoperability I do see the benefit of the 5. >>> >>> Thanks, >>> >>> --Chris >>> >>> From: Moriarty, Kathleen >>> Sent: Wednesday, February 13, 2013 2:05 PM >>> To: Harrington, Christopher; MILE IETF >>> Subject: RE: [mile] IOCs >>> >>> >>> If you think of IODEF just for transport, could you meet your needs >>>with storing the values differently in a database (IODEF is just meant >>>for the exchange)? The numbers map to low/med/high - for db storage - >>>if numbers are used, you could store the equivalent value, adding the >>>2 additional ones provided. >>> >>> Does it make sense to expand the set of values to match what CIF is >>>doing if we went forward with the approach of supporting both options? >>> >>> Thank you, >>> Kathleen >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>Of Harrington, Christopher >>> Sent: Wednesday, February 13, 2013 11:49 AM >>> To: 'C. Henry Adams & BIE'; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> From a data processing standpoint it is going to create extra work >>>for the people who are going to receive this data if we support both >>>numeric and alpha characters in the same field. I can envision people >>>wanting to search, sort, store, etc the data in this field. If we >>>allow both data types then everyone will need to have a mapping of >>>some sort. I have a field for confidence in my threat tracking >>>database. Having both a numeric score and alpha characters / words >>>creates issues when trying to interact with the data. I agree that we >>>need to support both however I don't think both should be in the same >>>field. I would much rather see 2 different fields for Confidence if we >>>are going to support 2 different data types. >>> >>> This will be a larger issue should Confidence be used elsewhere. >>>Ideally in future revisions I would like to see attribution expressed >>>as some form of attribution is almost always shared with an IoC. >>>Currently there are 5 areas where we (EMC) uses confidence. >>> >>> Indicator (how confident are you that this is a valid IoC) >>>Indicator_Set (how confident are you that all of the indcators in the >>>set should be in the set) Campaign (how confident are you that all >>>Indicator_Sets are part of this campaign) Threat Actor (how confident >>>are you that the Campaign is attributed to this Threat Actor) Threat >>>Actor type (how confident are you that this Theat Actor is APT, >>>Crimeware, other) >>> >>> The threat actor name and the threat actor type are usually the first >>>2 things that anyone processing IoCs wants to know as they drive >>>priority. >>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>of information for us. Sorry to take us a little off the path but I >>>wanted to show where Confidence could be used. >>> >>> Thanks, >>> >>> --Chris >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>Of C. Henry Adams & BIE >>> Sent: Wednesday, February 13, 2013 10:24 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Again, I would concur that both a numeric and subjective analysis of >>>the Confidence Rating needs to be express, but combined in a >>>simplified schema as such below: >>> >>> 1LL .... etc. >>> >>> 2P >>> >>> 3AC >>> >>> 4U >>> >>> 5I >>> >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>>5 =3D Imminent ) >>> >>> Here's my point, perhaps a set of numeric related or associated >>>definitions can lower the propagation of error regarding the analysis. >>> >>> Thanks, >>> C. Henry Adams >>> >>> >>> I agree that what we really need is both. In most situations a low, >>>medium and high may be acceptable but there are times when we will >>>want to show that confidence in a situation is increasing or >>>decreasing. If we are only looking at a three levels, we cannot >>>express what is needed to show confidence is trending up on the data >>>being exchanged about the event. >>> >>> Kathleen included the following in a previous message. >>> >>> >>> >>> Vs: >>> >>> 85 >>> >>> I really think we need to include both capabilities as John alluded >>>to since confidence is not a three tiered item but something that is >>>indeed subjective and we need a means to show a reasonably accurate >>>confidence index that the sender is trying to convey. >>> >>> Kent Landfield >>> >>> McAfee | An Intel Company >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>> >>> From: , John Banghart >>> Date: Wednesday, February 13, 2013 7:16 AM >>> To: "Stoecker, Paul" , Kathleen Moriarty >>>, Brian Trammell >>> Cc: "C. Henry Adams & BIE" , MILE IETF >>> >>> Subject: Re: [mile] IOCs >>> >>> Paul, >>> >>> I agree that confidence is subjective, but subjectivity can be >>>reduced within communities that interact frequently. Prioritization >>>of indicators and response between tightly connected sharing partners >>>might require a more specific level of detail, particularly during a >>>crisis situation. >>> >>> From that perspective, I think the guidance should allow for >>> additional granularity, while stressing the "high, medium, low" as >>> preferred for broad interoperability. >>> >>> -John >>> >>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>> >>> I may have been too succinct in my response ;-) >>> >>> Confidence is a subjective thing, so I think we should use subjective >>> terms: Low, Medium, High. Having a numeric scale with a map that >>> essentially would say something like: >>> >>> 1-33 =3D Low >>> 34-67=3D Medium >>> 68-100=3DHigh >>> >>> Is just a more complicated way of saying that something is Low, >>>Medium, High...do we really thing that how High something is makes >>>that much of a difference? >>> >>> This is like when you get your Performance review where it is Does >>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>> Meets...your bonus tells you that you got the same bonus that all the >>> other Meets got >>> ;-) >>> >>> Anyway, I digress but trying to prove a point that I would argue that >>>confidence in this case is going to be basically a gut feeling, so why >>>use numeric values when Low, Medium, High would do just fine. >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> >>> >>> >>> >>> >>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>> wrote: >>> >>> Hello, >>> >>> Both approaches will validate in the current schema. The >>> representation looks a little different for each, here is an example: >>> >>> >>> >>> Vs: >>> >>> 85 >>> >>> Searching capability is a great point, agreed. I'd like to hear from >>> more people to make sure we don't lose a capability that others find >>> extremely useful (need to gauge that). Other options is that the >>> guidance can also discourage the use of the numeric in addition to >>> specifying how to select ranges. >>> >>> Any other opinions? >>> >>> Thanks, >>> Kathleen >>> >>> -----Original Message----- >>> From: Stoecker, Paul >>> Sent: Wednesday, February 13, 2013 7:14 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Cant we make Confidence a List that has only 3 values: High, Medium, >>>and Low? Any other value means that the Document will mot validate >>>against the schema. >>> >>> Sent from my iPhone >>> >>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>> >>> wrote: >>> >>> Hi, Kathleen, all, >>> >>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>> interoperable numeric scales for assessment is a very hard problem. >>> (Were I charged with defining such a scale, the value "70" would mean >>> "we compared this incident report to N past similar incident reports >>> according to similarity algorithm S, and 70% of the past reports had >>> assessed impacts within E% of the actual, measured final impact -- I >>> think for most applications this is vastly more difficult and >>> rigorous than it needs to be.) >>> >>> Unless a numeric Confidence value is based on some actual, repeatably >>> measurable aspect of the Assessment report -- which I suspect in >>> many/most/all cases it's not -- then it just represents a guess, >>> however educated. Each team will probably naturally tune its own >>> scales such that each value generally means the same thing in each >>> report. Across teams, I don't know. >>> >>> On the other hand, Assessments are by their very nature educated >>> guesses, anyway, so I don't know that I'd find much use in automating >>> a response based on the assessment confidence. Chris has a good >>> point, though -- it makes searching difficult and sorting kind of >pointless. >>> >>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>> agree, we should put that in the guidance document (along with a note >>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>> high, unless we want to do it non-linearly). If the _vast_majority_ >>> of the users of this field use a 100-point scale with 100 meaning >>> "yes" and 0 meaning "any resemblance these values may have to actual >>> fact is purely coincidental", then let's consider renaming it "percent" >in 5070-bis. >>> >>> Best regards, >>> >>> Brian (as contributor) >>> >>> >>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>> wrote: >>> >>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>> change it if it needs to be changed. The value is for a confidence >>> rating on the indicators shared. The definitions may be helpful for >>> anyone who wants to work on this discussion. IODEF has various >>> markers that can be used in a complimentary way without conflating >>> the markers meaning. >>> >>> I think some people using IODEF find the numerical values more >>> helpful, and it would be good to understand what people have learned >>> from using the current structure (what works/does not work). The >>> scales I have seen are 0-100. There is of course a subjective >>> element to assigning a numerical value to the confidence and it may >>> vary from entity to entity. With this type of rating you may need to >>> consider who it came from and how they scored the confidence rating >>> to map to your own rating. It would be good to hear more thoughts on >this. >>> >>> Thanks, >>> Kathleen >>> >>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>> Sent: Tuesday, February 12, 2013 2:46 PM >>> To: MILE IETF >>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>> Subject: Re: [mile] IOCs >>> >>> >>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>> point. Different Confidence levels will cause confusion. It appears >>> that there maybe a need for some type of simplified standardization >>> to be established between all Sharing Groups in this regard. >>> >>> Perhaps numerical scoring set at lower values should express levels >>> of urgency. >>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D = Urgent, >>> 5 =3D Imminent ) >>> >>> Thanks, >>> C. Henry Adams >>> >>> >>> >>> I see some confusion coming down the pike if we start using >>> Confidence the way it is supported. If I am using low/med/high and >>> someone sends me an IoC with a score of 70, what does that mean to >>> me? What if I am using a scale of >>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>> to describe something with a consistent language. It really gets ugly >>> when we store IoC from multiple sources. I have confidence values >>> that are numeric as well as text. Makes searching / sorting very >>> problematic. >>> >>> At this point we have to roll with what we have. I would strongly >>> recommend that we revisit this at some point. >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Tuesday, February 12, 2013 9:59 AM >>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> Hi Chris & Take, >>> >>> I'll just focus on the confidence scoring. Right now, the schema >>> allows for you to either use a numerical score OR the ratings of low, >>> medium, and high. >>> Different sharing groups can decide how they want to share the data. >>> If >>> people were to use the numerical values, I agree it would be helpful >>> to have guidance. This could go in the IODE guidance document. >>> >>> I have seen examples of current users that use each of the >>> approaches, so we'll need to keep the option for backwards >>> compatibility and it is nice to keep in flexible options where we >>> can. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: Harrington, Christopher >>> Sent: Tuesday, February 12, 2013 9:22 AM >>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> The number of indicators wouldn't necessarily drive the use of >>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>> addresses that were used as C2 for 3 different campaigns I would have >>> separate indicator_set_ids, each with one of the 3 C2 IPs >>> >>> My suggestion would be a simple low, medium, high. I think if we >>> break it down to more levels than that we would need to provide >>> guidance on scoring, rating, etc. I think most people should be able >>> to understand low/med/high without having to have a mathematical >>> method for arriving at the level. >>> >>> Low - I am not sure >>> Medium - I am reasonably sure >>> High - I am very sure >>> >>> >>> Thanks, >>> >>> --Chris >>> >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 12, 2013 4:21 AM >>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> Regarding the indicator_set_id, I agree, it is useful when we need to >>> deal with large sets of indicators. >>> Since indicator_set_id attribute is optional (right?), it could be >>> omitted if we need to deal with only small number of indicators. >>> >>> Regarding the use case, I like the idea of using the confidence >>> attribute for the reason Chris kindly described. >>> I would like to hear a bit more on this: is it going to be numerical? >>> For >>> instance, 1 means "no confidence" while 5 means "strong confidence", >>> etc? >>> >>> Thank you. >>> Take >>> >>> >>> -----Original Message----- >>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>> Sent: Friday, February 08, 2013 4:11 AM >>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> With respect to tying things back to threat actors, from what I have >>> seen and use this is a generally accepted grouping: >>> >>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>> >>> Campaign and Threat Actor are where having a "Confidence" attribute >>> would be beneficial as making those associations is not a perfect >>> science by any means. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Thursday, February 07, 2013 2:00 PM >>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>> IETF' >>> Subject: RE: [mile] IOCs >>> >>> Hi Take & others, >>> >>> Thanks for chiming in, I've been talking about this with Chris and a >>> few others on their use cases and would like more opinions. I'll >>> provide an option below from what we have discussed from a CIRC view >>> point. We are also wondering how to also provide logic in IODEF that >>> could cross over into SCI attached schemas or IODEF extensions (the >>> solutions may all tie together with this discussion - or there may be >>> better/more elegant solutions others would like to propose). >>> >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Tuesday, February 05, 2013 12:04 PM >>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>> 'MILE IETF' >>> Subject: RE: [mile] IOCs >>> >>> I like this discussion. >>> I agree, it would be good idea to have indicator identifiers inside >>> the IOC-related classes. >>> >>> KMM: At the class level, we may have several indicators listed that >>> should be viewed as a set and may have another instance of that same >>> class that is a related issue, but a separate set. We could as you >>> say, list the indicator IDs connected through the reference class. >>> The set IDs might give us other ways to group the values when we get >>> into logic and relationships between sets or indicators. This could >>> also be a way to connect indicators or sets across XML documents that >>> could have been shared previously. If there are a large number of >>> indicators in the set, then this becomes useful, for smaller sets, I >>> agree it doesn't make as much sense. >>> >>> What do others think? >>> >>> Then for indicators not included in the base schema that may not fit >>> into a category in the SCI draft, do we create a place for these off >>> of SCI or right off of the IODE schema in EventData? >>> (more details >>> on >>> this in my first message). >>> >>> If we could see any indicator of compromise as computer event record, >>> we could use SCI:EventReport class as the place for the XML-based >>> IOCs that couldn't fit anywhere else. >>> >>> KMM: That sounds like a good idea to me. This should go into >>> guidance in the SCI draft. Does anyone else want to weigh in? >>> >>> >>> For the non-XML IOCs, we could use RecordData class, as suggested. >>> KMM: Sounds good, thanks! >>> >>> I agree to have indicator_uid, but I am not sure about the needs of >>> the indicator_set_id. >>> I understand we could do some grouping of individual indicator_uids >>> and its usability, but I am not sure whether we do not have any other >>> way to express these groupings. >>> For instance, a Reference class refers to several indicadtor_uids. >>> In >>> this case, they could be, in a sense, grouped. Isn't it enough? >>> >>> KMM: It may be, what do you think about large sets of indicators or >>> subsequent messages that add indicators to existing sets? Would this >>> happen? Would it be easier to express relationships with sets of >>> indicators in addition to individual indicators? By using this, it >>> could give us a unique way to also provide the logic and >>> relationships in a new class of IODEF so we don't have to worry about >>> adding it into the current structure. >>> If there are better ways to handle that, and others can provide some >>> options, that would be appreciated! >>> >>> Thank you, >>> Kathleen >>> >>> I would appreciate if anybody could share expertise on this. Though I >>> think I have read all the emails in the list, I might have >>> mis-understood some points. >>> >>> By the way, I think the indicator_uids should be added to the SCI >>> classes' >>> attributes so that they can be correlated with another information as >>> well. >>> >>> Thanks >>> Take >>> >>> >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Harrington, Christopher >>> Sent: Tuesday, February 05, 2013 4:25 AM >>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> I think some sort of group ID would do the trick. We also need a >>> logical and / or somewhere to show relationship between indicators. >>> If >>> I give you >>> 2 >>> registry keys do they both have to be present to be an indication of >>> compromise or is either one by themselves an indicator? Both would >>> have the same group ID since they are related. >>> >>> Thanks, >>> --Chris >>> >>> From: Stoecker, Paul >>> Sent: Sunday, February 03, 2013 8:26 PM >>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> What if we added indicator group ID along with the indicator_uid? >>> This would allow you to group indicators that are related into the >>> same group ID. >>> Would this resolve the issue? >>> >>> It is either that or going back to adding a Detection (or Indicators) >>> class that will should be used to take all of the indicators put them >>> into one place and have the ability to group the ones that go >>> together. I don't mean a place to put indicators that are missing >>> from IODEF.I mean a place in the IODEF document where you put the >>> indicators that are used for detection and prevention of the shared >>> Incident. I don't know the answer here, but there has got to be a >>> good way for indicators to be identified and being able to group them >>> as Chris has suggested without basically recreating something >>> complicated like STIX. >>> >>> Paul >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> >>> From: , Kathleen >>> Date: Sunday, February 3, 2013 5:11 PM >>> To: "Harrington, Christopher" , MILE >>> IETF >>> Subject: Re: [mile] IOCs >>> >>> Hi Chris, >>> >>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>> >>> The list has already said they would like to see indicators added to >>> the definitions in RFC5070-bis, to be more explicit about including >>> indicators and sets of indicators in IODE documents as opposed to >>> 'parts of an incident or the useful information on an incident for >>> sharing purposes. It was written before we used terms like >>> indicators. With that in mind, Rosella proposed a number of changes >>> back in July, both for guidance and for format updates. It may help >>> to have the first draft try to address at least some of these issues >>> so people can understand the problems and at least a proposed >>> solution. >>> >>> As you point out, we need to be able to show relationships between >>> sets of indicators, where we may have a few sets of indicators that >>> could have a relationship to each other within a document. In the >>> July presentation, one of the questions was to see if we should add >>> new category attribute values for the System class that would connect >>> the list of included indicators. I think we should still keep the >>> concept of a Node to a single node, but perhaps within System, list >>> multiple sets of Nodes that may be one type of attack. Rosella had >>> suggested pulling forward the "FraudType" from RFC5901, this would >>> help solve the issue as NodeRole values would compliment an >>> AttackType (FraudType values could be included in AttackType or some >>> broader term). It may be better to have the FraudTypes, plus >>> attribute values like "C2-server", "sinkhole", "MalwareDistribution" >>> for added context so you know what to do with the received set of >>> indicators. >>> >>> I am proposing that we change IODEF to include multiple sets of >>> indicators, add an AttackType attribute (or some other name), a >>> method to connect indicators and indicator sets within an IODEF using >>> an attribute of indicator_uid (or some other name) with a string >>> value to make the connection points, and add a few indicators that >>> are commonly shared into the base IODEF. >>> >>> Back in July, we talked about adding Registry Key/Value pairs and >>> hashes to the main IODEF document (trying to see if this will help >>> Chris below). What if we added the Registry Key/Value pairs as a >>> class off of RecordData, using a similar structure to what is in >>> RFC5901, and also added the ability to include hashes in RecordData? >>> I think if we then had the indicator_uid at the RecordData level, we >>> could connect a set within that structure and repeat the structure >>> for other sets in the same way we would do with Node inside of the >>> System class, using the indicator_uid to tie the set together. Then >>> at the more specific level for the hash, registry Key/value, IP, etc. >>> use an indicator_uid if we needed them marked at this level as well? >>> Maybe we want indicator_set at the higher level? I'd like some >>> opinions on this approach. +1 if you agree, suggestions if you have >>> other ideas that may work better. >>> >>> We'll also need to worry about marking the indicators to prevent >>> forward sharing when not permitted. We may want to use these values >>> or something else. >>> >>> Thank you! >>> Kathleen >>> >>> From: Harrington, Christopher >>> Sent: Friday, February 01, 2013 12:01 PM >>> To: Moriarty, Kathleen; MILE IETF >>> Subject: RE: [mile] IOCs >>> >>> I think we have a bigger relationship issue to address. Let use the >>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>> that message we could have groupings of indicators that we need to >>> show are >>> related: >>> >>> Two or more indicators of different type that relate to the same >>> threat: >>> The file hash of a malicious file and the URL of the C2 that >>> the file uses. Either or both may be present to indicate a >>> compromise. >>> >>> Two or more indicators of the same type that relate to the same >>> threat: >>> 2 different registry values for the same registry key. If >>> either value is present it is a compromise indicator but both will >>> not be present. >>> >>> The problem compounds itself very quickly. Consider the scenario >>> where both groupings above are part of the same threat. I need to >>> show that logical groupings of Indicators are related as well. We >>> can't send multiple IODEF messages for this from what I remember >>> reading. >>> >>> The last one I can think of would be when you have 2 different >>> indicators that represent the same indicator. It's not uncommon to >>> send both the >>> MD5 >>> and SHA1 hash of a malicious file. The indicator is the file but the >>> IOCs are the 2 hash values. How do we show they are related? If we >>> use a unique Inidcator ID for each hash value there needs to be a >>> higher level grouping. >>> >>> Thoughts? >>> >>> Thanks, >>> >>> --Chris >>> >>> Christopher Harrington >>> Consulting Security Engineer >>> GSO - Critical Incident Response Center EMC - Where Information Lives >>> 174 Middlesex Turnpike >>> Bedford, MA 01730 >>> 781-515-5862 (work) >>> 603-583-1585 (cell) >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Moriarty, Kathleen >>> Sent: Friday, February 01, 2013 11:28 AM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> All - >>> >>> I'd like your input and will refocus the thread to get opinions from >>> the list on options to help solve the problems raised in my message >>> and additionally in Paul's message. >>> >>> Interesting point, C. Henry. Our objective here is to have machine >>> automated exchanges, so we rely on encryption rather than obfuscation >>> to achieve the necessary level of confidentiality. >>> >>> Paul mentioned the need to distinguish indicators of compromise from >>> context information that may also include IP address or other data >>> that could be indicators. The question I raised was on how to >>> connect sets of indicators in the same IODEF document, assuming the >>> ability to have watchlists that could have several sets of indicators >>> included, as well as to connect indicators that may be included in >>> embedded schemas. >>> >>> If we add an attribute on all of the relevant indicators, let's say >>> 'indicator-uid' how do we mark the indicators? Do we use this to >>> mark who sent the indicator as well so that we can prevent forward >>> sharing when it is not permitted or handle that separately? >>> >>> Then for indicators not included in the base schema that may not fit >>> into a category in the SCI draft, do we create a place for these off >>> of SCI or right off of the IODE schema in EventData? (more details on >>> this in my first message). >>> >>> Comments and questions encouraged to figure out the right technical >>> solution to have this machine automatable. >>> >>> Thank you, >>> Kathleen >>> >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of C. >>> Henry Adams & BIE >>> Sent: Monday, January 28, 2013 11:25 PM >>> To: MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Temporal Dependency sounds interesting. I remember when I first ran >>> across this particular craft, an experienced colleague asked me a >>> peculiar question. He said, " How do you stop someone from tracking >>> the IP Address to your computer?" >>> >>> I replied, "I don't know, how?" >>> >>> Then he said, "Cut the dog-gone thing off and the modem that it is >>> connected- which is constantly on!" LOL >>> >>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>> searching a Neighborhood for Survivors which were hit by a Disaster >>> or let's just say "Live" Terrorist Situation. He /or She needs to >>> communication back to other Officials that he /or somehow is in >>> Danger. The device used to communicate has been captured by the >>> great minds of the enemy. It's only a matter of time before they >>> utilize reverse engineering to figure out how it functions. However, >>> their pride comes before a fall when seeking the location of other >>> similar devices to attack. Why? Perhaps the less thought of concepts >>> that makes the device function properly, saves the day by disguise or >>> cutting it off (figuratively speaking). >>> >>> Just a visionary thought. >>> >>> C. Henry Adams >>> chenryadams@biemediagroup.com >>> http://biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> --- On Mon, 1/28/13, Dave Misell wrote: >>> >>> From: Dave Misell >>> Subject: Re: [mile] IOCs >>> To: "C. Henry Adams & BIE" >>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>> DNS SEC a pemanent and temporal key, with a temporal Id? >>> >>> Yours Faithfully, >>> >>> Dave Misell MSc CISSP >>> SilentCircle dsm >>> 07710 380044 >>> david.misell@bcs.org >>> >>> >>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>> >>> wrote: >>> >>> Serialization of a particular Lists of XML Classes in a unique way >>> was closely related to what I attempted to express when I stated, >>> "consider to a degree what appears to be illogical in brilliant minds >>> in some instances." >>> >>> However, I see Dr. Stoecker's point a little clearer. However, it >>> would be nice if the UID was in some way disguised from those who >>> study this Security Art Form in a negative way. >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> Re: [mile] IOCs >>> >>> Sunday, January 27, 2013 8:52 PM >>> From: >>> "Stoecker, Paul" >>> To: >>> "mile@ietf.org" >>> I would like to look at this from a slightly different >>> perspective=A9let's say I get an XML document that tells me about an >>> incident. This document has source IP and destination IP that is >>> being shared. However, what I don't know is which IP address is my >>> indicator and which is just a contextual piece of information. This >>> means that my detection product isn't going to know which one to use >>> either, because there is nothing to tell me which IP is the one, even >>> if the roles are set it still might not be enough to tell my system >>> which one I should use as the indicator. >>> >>> If we had something like indicator_id as an attribute, it would allow >>> us to easily identify indicators from contextual data. I do admit to >>> being biased as I have spent much of my career working on the >>> monitoring and detection side of these things, so I am just thinking >>> of ways to make it very clear what the indicators are in the XML >>> document and the other data that may be important as I investigate >>> activity that I have detected off of those indicators. >>> >>> >>> I did suggest the detection class, but I think we may get more >>> flexibility with the indicator_uid. One thing that I haven't >>> considered is the UID portion of this=A9how do we use that UID? How is >>> the UID created? Are there standards for UIDs? >>> >>> Regards, >>> >>> Paul >>> >>> >>> >>> Paul W. Stoecker, Ph.D. >>> SMC Lead Content Architect >>> RSA, The Security Division of EMC >>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>> >>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>> wrote: >>> >>> From: C. Henry Adams & BIE >>> Subject: RE: [mile] IOCs >>> To: "KathleenMoriarty" >>> Cc: mile@ietf.org >>> Date: Saturday, January 26, 2013, 6:17 PM >>> >>> Greetings Kathleen, >>> >>> Your logic stimulates my visionary brain because I'm amazed at the >>> many avenues you review with this approach at once. However, could >>> you share a few advantages and disadvantages to the latter? >>> -------------------------------------------------------------------- >>> -------- >>> ---------------------------------------------- >>> "we could continue to group items in logical places as is done now in >>> IODEF and then have the extension point for combined indicators via >>> SCI." >>> -------------------------------------------------------------------- >>> -------- >>> --------------------------------------------- >>> >>> You pointed out what you consider to be logical places, but if I >>> wanted to protect information from parties capable of ascertaining it >>> from your logical places, perhaps we should also consider to a degree >>> what appears to be illogical in brilliant minds in some instances. >>> >>> >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> >>> --- On Sat, 1/26/13, Moriarty, Kathleen >>> wrote: >>> >>> From: Moriarty, Kathleen >>> Subject: RE: [mile] IOCs >>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>> >>> Date: Saturday, January 26, 2013, 10:13 AM >>> >>> Hello C. Henry & others, >>> >>> Thanks for taking a look at this. We have a few considerations in >>> this email thread I would like to hear thoughts on (and there may be >>> more once RFC5070-bis is actively edited). >>> >>> The AdditionalData class and the RecordItem class both allow for >>> non-XML extensions. Where you place the extensions should be >>> specific to the logical grouping of the parent elements so you can >>> understand more about the included data in most cases. >>> >>> The Impact class can be used to provide context information on the >>> included data of the report and also can include a confidence rating >>> on the report as a whole. Extensions related to impact would be one >>> level higher (at the moment) in the Assessment class using the >>> AdditionalData extension point. >>> >>> Take asked about including vulnerability information, I would think >>> that would fit under the Vulnerability extension point of the SCI >>> draft in the Method class. He did ask about non-XML. RecordItem or >>> AdditionalData do allow for non-XML extension points, we could either >>> have the SCI draft handle these as well or have the extensions that >>> are non-XML come directly off the AdditionalData or RecordItem >>> classes according to what makes sense from a logical standpoint. >>> >>> As for my question, it was two-fold. >>> >>> Indicator based schemas have a reference number or a GUID for the >>> various indicators they share. If we are extending to embed other >>> schemas that include such reference or GUID identifiers, do we want >>> to add an attribute to the various elements in IODEF that could be >>> indicators? Is this enough to make the connections or is something >>> else else needed? We could add something like an Indicator_ID in >>> RFC5070-bis which would then correlate to the reference or GUID >>> identifiers. >>> >>> Then the other question was on how to include indicators that are not >>> in the base schema that may be related or have language with "and" >>> "or" >>> to >>> specify the relationships. In some cases, you will want to group >>> these indictors in one extension point, where they may fit logically >>> in multiple places if the relationships did not need to be shown in >>> the data format. If we have cases like this where you need more >>> complex representations, should we use one extension point via the >>> SCI draft off of the EventData class AdditionalData extension point? >>> Opinions are needed here.... >>> >>> A few people have mentioned wanting to include some commonly shared >>> indictors into the base IODEF document. We could have a catch-all >>> class that does this and has an extension point off of it in >>> EventData or we could continue to group items in logical places as is >>> done now in IODEF and then have the extension point for combined >>> indicators via SCI. I think I like the latter approach. >>> >>> Thank you, >>> Kathleen >>> ________________________________________ >>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>> Henry >>> Adams & BIE [chatlga2000@yahoo.com] >>> Sent: Saturday, January 26, 2013 3:05 AM >>> To: mile@ietf.org >>> Cc: C. Henry Adams >>> Subject: Re: [mile] IOCs >>> >>> Greetings Everyone, >>> >>> Take mentioned two types of indicators based on the : >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>> 1) If the indicators are something like an XML-based alert/warning of >>> information leakage, it could be an event that are conveyed in the >>> SCI's EventReport class, IMHO. >>> >>> 2) If the indicators are something like an non-XML ones, I guess it >>> could be conveyed without using SCI draft. >>> For instance, we could use Impact class of the base IODEF to convey >>> the indicators. >>> We could for instance extend the list of indicators of the Impact >>> class, if needed. >>> -------------------------------------------------------------------- >>> -------- >>> -------------------------- >>> >>> In doing so he pointed out the "Impact Class" >>> >>> Whereas, Kathleen stated, >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------- >>> For the discussion below, I was thinking more of combined set with >>> relationships that may be included in a single extension point, so >>> that's why I was thinking about the EventData class, but there may be >>> better locations or a specific area within the EventData. >>> >>> Paul Stoecker had suggested a "Detection" class as a consideration. >>> -------------------------------------------------------------------- >>> -------- >>> ------------------------ >>> >>> Kathleen thoughts related yet still with other indicators and the >>> EventData Class. >>> >>> Is there a possible way to create a new XML class which encompass >>> combining the EventData, Detection and base IODEF classes to simplify >>> this issue? >>> >>> >>> C. Henry Adams >>> chatlga2000@yahoo.com (Direct Email) >>> chenryadams@biemediagroup.com >>> >>> >>> The information contained herein is for the exclusive use of the >>> original recipient. This information is granted for limited >>> distribution within the recipient's place of business for planning >>> purposes only. Further dissemination, whether private or public is >>> prohibited. >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >>_______________________________________________ >>mile mailing list >>mile@ietf.org >>https://www.ietf.org/mailman/listinfo/mile > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From eburger-l@standardstrack.com Tue Feb 19 06:43:46 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400E921F8798 for ; Tue, 19 Feb 2013 06:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFGtG20i+bm8 for ; Tue, 19 Feb 2013 06:43:43 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4840B21F8904 for ; Tue, 19 Feb 2013 06:43:43 -0800 (PST) Received: from [141.161.20.235] (port=51849) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7oPw-00043p-Kp for mile@ietf.org; Tue, 19 Feb 2013 06:43:36 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Tue, 19 Feb 2013 09:43:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <166006A5-E7F4-4F9A-BEA7-468DE9A20CE2@standardstrack.com> , <8D7AF2C8-0529-475A-9125-BAF40F2D5F67@standardstrack.com> To: MILE IETF X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:43:46 -0000 If the proposal is 0-19 =3D low, 20-39 =3D =85, 80-99 =3D high, then why = do we have the numbers, or why do we have the enumerated type? Either it = is a number or it is an enumerative value. Having both is asking for = trouble. On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen" = wrote: > Should we provide guidance similar or the same as what CIF uses (was = posted to the list previously)? They use direct mapping to 5 levels so = that you can have ranges of numeric values used from 0-100, low to high. = This would be the easiest solution... >=20 > Thanks, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric = Burger [eburger-l@standardstrack.com] > Sent: Tuesday, February 19, 2013 7:38 AM > To: MILE IETF > Subject: Re: [mile] IOCs >=20 > If there really is no value to a value, do not let people hurt = themselves. >=20 > If there is a proprietary reason for a value, we should say what we = mean and call it such. For example: >=20 > This is XML so put your = NON-INTEROPERABLE mumble you want here > or > 42 > or > balderdash >=20 > On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" = wrote: >=20 >> I would agree that flexibility is something to strive for. However = there >> isn't enough in the RFC to make the numeric confidence value = understood by >> the recipient and therefore actionable. =46rom the spec: >>=20 >> "numeric. The element content contains a number that conveys the = confidence >> of the data. The semantics of this number outside the scope of this >> specification" >>=20 >> Based on that I can score my confidence with 1 being most confident = and 100 >> being least. Perfectly legitimate but would probably mess everybody = up. What >> if my scale is 1000 and yours is 100. I send you something with a = score of >> 100 you will think I am absolutely certain when I am only 10% so. = Knowing >> how sure the sender is about a piece of data shared is critical. If = the >> sender puts an arbitrary number in the field I have no point of = reference. >> It's meaningless to me. >>=20 >> We spell out what the relative value is for low/med/high. I know = those are >> self-explanatory but they are still spelled out. I would urge that we = do the >> same for a numeric value. If not there needs to be something added so = that >> in addition to the numeric value I have a point of reference for how = certain >> you are based on the number you put there. >>=20 >> Thanks, >>=20 >> --Chris >>=20 >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Banghart, John >> Sent: Monday, February 18, 2013 7:42 AM >> To: Eric Burger; MILE IETF >> Subject: Re: [mile] IOCs >>=20 >> Eric, >>=20 >> Well, I think you answered your own initial question, but I'm going = to jump >> in anyway. :) >>=20 >> Generally speaking, I think we want to strike a balance between >> standardization and flexibility. We are unlikely to arrive at any = sort of >> one-size-fits-all scheme, no matter how long we talk about it. = Instead, we >> should be focusing on solidifying the areas we can all agree on, and = allow >> flexibility for those that we don't. It's an age old clich=E9, but = let's not >> let perfect be the enemy of the good. >>=20 >> -John >>=20 >> On 2/16/13 12:42 PM, "Eric Burger" = wrote: >>=20 >>> What is the justification for both numeric and enumerated values >>> (low/medium/high)? In general such a schema is begging for >>> interoperability problems. >>>=20 >>> I suppose I can understand both sides of the argument. On the We = Need >>> Numbers side is those that actually calculate a percentage or other >>> objective measure in the confidence may want to use those real = numbers. >>> As well, on the We Need Numbers side is the argument that three >>> enumerated values may not prove sufficient in the future. On the We >>> Need Enumerated Values side is confidence, other than 0% and 100%, = tend >>> to be arbitrary guesses. Putting a number on this value imparts a = level >>> of specificity that does not exist. Also, it is a lot easier to map >>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>=20 >>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>> wrote: >>>=20 >>>> That will work provided I (and everyone else) has a mapping for the >>>> numbers. I would prefer a simple low/med/high scheme. The more we = add >>>> the more you have to be able to differentiate between them. However >>>> for potential interoperability I do see the benefit of the 5. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> From: Moriarty, Kathleen >>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>> To: Harrington, Christopher; MILE IETF >>>> Subject: RE: [mile] IOCs >>>>=20 >>>>=20 >>>> If you think of IODEF just for transport, could you meet your needs >>>> with storing the values differently in a database (IODEF is just = meant >>>> for the exchange)? The numbers map to low/med/high - for db = storage - >>>> if numbers are used, you could store the equivalent value, adding = the >>>> 2 additional ones provided. >>>>=20 >>>> Does it make sense to expand the set of values to match what CIF is >>>> doing if we went forward with the approach of supporting both = options? >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Harrington, Christopher >>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> =46rom a data processing standpoint it is going to create extra = work >>>> for the people who are going to receive this data if we support = both >>>> numeric and alpha characters in the same field. I can envision = people >>>> wanting to search, sort, store, etc the data in this field. If we >>>> allow both data types then everyone will need to have a mapping of >>>> some sort. I have a field for confidence in my threat tracking >>>> database. Having both a numeric score and alpha characters / words >>>> creates issues when trying to interact with the data. I agree that = we >>>> need to support both however I don't think both should be in the = same >>>> field. I would much rather see 2 different fields for Confidence if = we >>>> are going to support 2 different data types. >>>>=20 >>>> This will be a larger issue should Confidence be used elsewhere. >>>> Ideally in future revisions I would like to see attribution = expressed >>>> as some form of attribution is almost always shared with an IoC. >>>> Currently there are 5 areas where we (EMC) uses confidence. >>>>=20 >>>> Indicator (how confident are you that this is a valid IoC) >>>> Indicator_Set (how confident are you that all of the indcators in = the >>>> set should be in the set) Campaign (how confident are you that all >>>> Indicator_Sets are part of this campaign) Threat Actor (how = confident >>>> are you that the Campaign is attributed to this Threat Actor) = Threat >>>> Actor type (how confident are you that this Theat Actor is APT, >>>> Crimeware, other) >>>>=20 >>>> The threat actor name and the threat actor type are usually the = first >>>> 2 things that anyone processing IoCs wants to know as they drive = priority. >>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>> of information for us. Sorry to take us a little off the path but = I >>>> wanted to show where Confidence could be used. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of C. Henry Adams & BIE >>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Again, I would concur that both a numeric and subjective analysis = of >>>> the Confidence Rating needs to be express, but combined in a >>>> simplified schema as such below: >>>>=20 >>>> 1LL .... etc. >>>>=20 >>>> 2P >>>>=20 >>>> 3AC >>>>=20 >>>> 4U >>>>=20 >>>> 5I >>>>=20 >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D= Urgent, >>>> 5 =3D Imminent ) >>>>=20 >>>> Here's my point, perhaps a set of numeric related or associated >>>> definitions can lower the propagation of error regarding the = analysis. >>>>=20 >>>> Thanks, >>>> C. Henry Adams >>>>=20 >>>>=20 >>>> I agree that what we really need is both. In most situations a = low, >>>> medium and high may be acceptable but there are times when we will >>>> want to show that confidence in a situation is increasing or >>>> decreasing. If we are only looking at a three levels, we cannot >>>> express what is needed to show confidence is trending up on the = data >>>> being exchanged about the event. >>>>=20 >>>> Kathleen included the following in a previous message. >>>>=20 >>>> >>>>=20 >>>> Vs: >>>>=20 >>>> 85 >>>>=20 >>>> I really think we need to include both capabilities as John alluded >>>> to since confidence is not a three tiered item but something that = is >>>> indeed subjective and we need a means to show a reasonably accurate >>>> confidence index that the sender is trying to convey. >>>>=20 >>>> Kent Landfield >>>>=20 >>>> McAfee | An Intel Company >>>> Direct: +1.972.963.7096 >>>> Mobile: +1.817.637.8026 >>>> Web: www.mcafee.com >>>>=20 >>>> From: , John Banghart >>>> Date: Wednesday, February 13, 2013 7:16 AM >>>> To: "Stoecker, Paul" , Kathleen Moriarty >>>> , Brian Trammell = >>>> Cc: "C. Henry Adams & BIE" , MILE IETF >>>> >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Paul, >>>>=20 >>>> I agree that confidence is subjective, but subjectivity can be >>>> reduced within communities that interact frequently. = Prioritization >>>> of indicators and response between tightly connected sharing = partners >>>> might require a more specific level of detail, particularly during = a >>>> crisis situation. >>>>=20 >>>> =46rom that perspective, I think the guidance should allow for >>>> additional granularity, while stressing the "high, medium, low" as >>>> preferred for broad interoperability. >>>>=20 >>>> -John >>>>=20 >>>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>>=20 >>>> I may have been too succinct in my response ;-) >>>>=20 >>>> Confidence is a subjective thing, so I think we should use = subjective >>>> terms: Low, Medium, High. Having a numeric scale with a map that >>>> essentially would say something like: >>>>=20 >>>> 1-33 =3D Low >>>> 34-67=3D Medium >>>> 68-100=3DHigh >>>>=20 >>>> Is just a more complicated way of saying that something is Low, >>>> Medium, High...do we really thing that how High something is makes >>>> that much of a difference? >>>>=20 >>>> This is like when you get your Performance review where it is Does >>>> Not Meet, Meets and Exceeds...your boss tells you that you are a = High >>>> Meets...your bonus tells you that you got the same bonus that all = the >>>> other Meets got >>>> ;-) >>>>=20 >>>> Anyway, I digress but trying to prove a point that I would argue = that >>>> confidence in this case is going to be basically a gut feeling, so = why >>>> use numeric values when Low, Medium, High would do just fine. >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" = >>>> wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> Both approaches will validate in the current schema. The >>>> representation looks a little different for each, here is an = example: >>>>=20 >>>> >>>>=20 >>>> Vs: >>>>=20 >>>> 85 >>>>=20 >>>> Searching capability is a great point, agreed. I'd like to hear = from >>>> more people to make sure we don't lose a capability that others = find >>>> extremely useful (need to gauge that). Other options is that the >>>> guidance can also discourage the use of the numeric in addition to >>>> specifying how to select ranges. >>>>=20 >>>> Any other opinions? >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: Stoecker, Paul >>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>> To: Brian Trammell >>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Cant we make Confidence a List that has only 3 values: High, = Medium, >>>> and Low? Any other value means that the Document will mot = validate >>>> against the schema. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>> >>>> wrote: >>>>=20 >>>> Hi, Kathleen, all, >>>>=20 >>>> I think 3.10.4 in 5070 takes the right approach here: trying to = build >>>> interoperable numeric scales for assessment is a very hard problem. >>>> (Were I charged with defining such a scale, the value "70" would = mean >>>> "we compared this incident report to N past similar incident = reports >>>> according to similarity algorithm S, and 70% of the past reports = had >>>> assessed impacts within E% of the actual, measured final impact -- = I >>>> think for most applications this is vastly more difficult and >>>> rigorous than it needs to be.) >>>>=20 >>>> Unless a numeric Confidence value is based on some actual, = repeatably >>>> measurable aspect of the Assessment report -- which I suspect in >>>> many/most/all cases it's not -- then it just represents a guess, >>>> however educated. Each team will probably naturally tune its own >>>> scales such that each value generally means the same thing in each >>>> report. Across teams, I don't know. >>>>=20 >>>> On the other hand, Assessments are by their very nature educated >>>> guesses, anyway, so I don't know that I'd find much use in = automating >>>> a response based on the assessment confidence. Chris has a good >>>> point, though -- it makes searching difficult and sorting kind of >> pointless. >>>>=20 >>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then = I >>>> agree, we should put that in the guidance document (along with a = note >>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>> of the users of this field use a 100-point scale with 100 meaning >>>> "yes" and 0 meaning "any resemblance these values may have to = actual >>>> fact is purely coincidental", then let's consider renaming it = "percent" >> in 5070-bis. >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as contributor) >>>>=20 >>>>=20 >>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>> wrote: >>>>=20 >>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>> change it if it needs to be changed. The value is for a confidence >>>> rating on the indicators shared. The definitions may be helpful = for >>>> anyone who wants to work on this discussion. IODEF has various >>>> markers that can be used in a complimentary way without conflating >>>> the markers meaning. >>>>=20 >>>> I think some people using IODEF find the numerical values more >>>> helpful, and it would be good to understand what people have = learned >>>> from using the current structure (what works/does not work). The >>>> scales I have seen are 0-100. There is of course a subjective >>>> element to assigning a numerical value to the confidence and it may >>>> vary from entity to entity. With this type of rating you may need = to >>>> consider who it came from and how they scored the confidence rating >>>> to map to your own rating. It would be good to hear more thoughts = on >> this. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>> To: MILE IETF >>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>> Subject: Re: [mile] IOCs >>>>=20 >>>>=20 >>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>> point. Different Confidence levels will cause confusion. It = appears >>>> that there maybe a need for some type of simplified standardization >>>> to be established between all Sharing Groups in this regard. >>>>=20 >>>> Perhaps numerical scoring set at lower values should express levels >>>> of urgency. >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D= Urgent, >>>> 5 =3D Imminent ) >>>>=20 >>>> Thanks, >>>> C. Henry Adams >>>>=20 >>>>=20 >>>>=20 >>>> I see some confusion coming down the pike if we start using >>>> Confidence the way it is supported. If I am using low/med/high and >>>> someone sends me an IoC with a score of 70, what does that mean to >>>> me? What if I am using a scale of >>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the = ability >>>> to describe something with a consistent language. It really gets = ugly >>>> when we store IoC from multiple sources. I have confidence values >>>> that are numeric as well as text. Makes searching / sorting very >>>> problematic. >>>>=20 >>>> At this point we have to roll with what we have. I would strongly >>>> recommend that we revisit this at some point. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Hi Chris & Take, >>>>=20 >>>> I'll just focus on the confidence scoring. Right now, the schema >>>> allows for you to either use a numerical score OR the ratings of = low, >>>> medium, and high. >>>> Different sharing groups can decide how they want to share the = data. >>>> If >>>> people were to use the numerical values, I agree it would be = helpful >>>> to have guidance. This could go in the IODE guidance document. >>>>=20 >>>> I have seen examples of current users that use each of the >>>> approaches, so we'll need to keep the option for backwards >>>> compatibility and it is nice to keep in flexible options where we >>>> can. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: Harrington, Christopher >>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> The number of indicators wouldn't necessarily drive the use of >>>> indicator_set_id. The purpose is to show relationship. If I sent 3 = IP >>>> addresses that were used as C2 for 3 different campaigns I would = have >>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>=20 >>>> My suggestion would be a simple low, medium, high. I think if we >>>> break it down to more levels than that we would need to provide >>>> guidance on scoring, rating, etc. I think most people should be = able >>>> to understand low/med/high without having to have a mathematical >>>> method for arriving at the level. >>>>=20 >>>> Low - I am not sure >>>> Medium - I am reasonably sure >>>> High - I am very sure >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Regarding the indicator_set_id, I agree, it is useful when we need = to >>>> deal with large sets of indicators. >>>> Since indicator_set_id attribute is optional (right?), it could be >>>> omitted if we need to deal with only small number of indicators. >>>>=20 >>>> Regarding the use case, I like the idea of using the confidence >>>> attribute for the reason Chris kindly described. >>>> I would like to hear a bit more on this: is it going to be = numerical? >>>> For >>>> instance, 1 means "no confidence" while 5 means "strong = confidence", >>>> etc? >>>>=20 >>>> Thank you. >>>> Take >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] >>>> Sent: Friday, February 08, 2013 4:11 AM >>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> With respect to tying things back to threat actors, from what I = have >>>> seen and use this is a generally accepted grouping: >>>>=20 >>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>=20 >>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>> would be beneficial as making those associations is not a perfect >>>> science by any means. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Thursday, February 07, 2013 2:00 PM >>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; = 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Hi Take & others, >>>>=20 >>>> Thanks for chiming in, I've been talking about this with Chris and = a >>>> few others on their use cases and would like more opinions. I'll >>>> provide an option below from what we have discussed from a CIRC = view >>>> point. We are also wondering how to also provide logic in IODEF = that >>>> could cross over into SCI attached schemas or IODEF extensions (the >>>> solutions may all tie together with this discussion - or there may = be >>>> better/more elegant solutions others would like to propose). >>>>=20 >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> I like this discussion. >>>> I agree, it would be good idea to have indicator identifiers inside >>>> the IOC-related classes. >>>>=20 >>>> KMM: At the class level, we may have several indicators listed that >>>> should be viewed as a set and may have another instance of that = same >>>> class that is a related issue, but a separate set. We could as you >>>> say, list the indicator IDs connected through the reference class. >>>> The set IDs might give us other ways to group the values when we = get >>>> into logic and relationships between sets or indicators. This = could >>>> also be a way to connect indicators or sets across XML documents = that >>>> could have been shared previously. If there are a large number of >>>> indicators in the set, then this becomes useful, for smaller sets, = I >>>> agree it doesn't make as much sense. >>>>=20 >>>> What do others think? >>>>=20 >>>> Then for indicators not included in the base schema that may not = fit >>>> into a category in the SCI draft, do we create a place for these = off >>>> of SCI or right off of the IODE schema in EventData? >>>> (more details >>>> on >>>> this in my first message). >>>>=20 >>>> If we could see any indicator of compromise as computer event = record, >>>> we could use SCI:EventReport class as the place for the XML-based >>>> IOCs that couldn't fit anywhere else. >>>>=20 >>>> KMM: That sounds like a good idea to me. This should go into >>>> guidance in the SCI draft. Does anyone else want to weigh in? >>>>=20 >>>>=20 >>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>> KMM: Sounds good, thanks! >>>>=20 >>>> I agree to have indicator_uid, but I am not sure about the needs of >>>> the indicator_set_id. >>>> I understand we could do some grouping of individual indicator_uids >>>> and its usability, but I am not sure whether we do not have any = other >>>> way to express these groupings. >>>> For instance, a Reference class refers to several indicadtor_uids. >>>> In >>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>=20 >>>> KMM: It may be, what do you think about large sets of indicators or >>>> subsequent messages that add indicators to existing sets? Would = this >>>> happen? Would it be easier to express relationships with sets of >>>> indicators in addition to individual indicators? By using this, it >>>> could give us a unique way to also provide the logic and >>>> relationships in a new class of IODEF so we don't have to worry = about >>>> adding it into the current structure. >>>> If there are better ways to handle that, and others can provide = some >>>> options, that would be appreciated! >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> I would appreciate if anybody could share expertise on this. Though = I >>>> think I have read all the emails in the list, I might have >>>> mis-understood some points. >>>>=20 >>>> By the way, I think the indicator_uids should be added to the SCI >>>> classes' >>>> attributes so that they can be correlated with another information = as >>>> well. >>>>=20 >>>> Thanks >>>> Take >>>>=20 >>>>=20 >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Harrington, Christopher >>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> I think some sort of group ID would do the trick. We also need a >>>> logical and / or somewhere to show relationship between indicators. >>>> If >>>> I give you >>>> 2 >>>> registry keys do they both have to be present to be an indication = of >>>> compromise or is either one by themselves an indicator? Both would >>>> have the same group ID since they are related. >>>>=20 >>>> Thanks, >>>> --Chris >>>>=20 >>>> From: Stoecker, Paul >>>> Sent: Sunday, February 03, 2013 8:26 PM >>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> What if we added indicator group ID along with the indicator_uid? >>>> This would allow you to group indicators that are related into the >>>> same group ID. >>>> Would this resolve the issue? >>>>=20 >>>> It is either that or going back to adding a Detection (or = Indicators) >>>> class that will should be used to take all of the indicators put = them >>>> into one place and have the ability to group the ones that go >>>> together. I don't mean a place to put indicators that are missing >>>> from IODEF.I mean a place in the IODEF document where you put the >>>> indicators that are used for detection and prevention of the shared >>>> Incident. I don't know the answer here, but there has got to be a >>>> good way for indicators to be identified and being able to group = them >>>> as Chris has suggested without basically recreating something >>>> complicated like STIX. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>>=20 >>>> From: , Kathleen >>>> Date: Sunday, February 3, 2013 5:11 PM >>>> To: "Harrington, Christopher" , = MILE >>>> IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Hi Chris, >>>>=20 >>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>=20 >>>> The list has already said they would like to see indicators added = to >>>> the definitions in RFC5070-bis, to be more explicit about including >>>> indicators and sets of indicators in IODE documents as opposed to >>>> 'parts of an incident or the useful information on an incident for >>>> sharing purposes. It was written before we used terms like >>>> indicators. With that in mind, Rosella proposed a number of = changes >>>> back in July, both for guidance and for format updates. It may = help >>>> to have the first draft try to address at least some of these = issues >>>> so people can understand the problems and at least a proposed >>>> solution. >>>>=20 >>>> As you point out, we need to be able to show relationships between >>>> sets of indicators, where we may have a few sets of indicators that >>>> could have a relationship to each other within a document. In the >>>> July presentation, one of the questions was to see if we should add >>>> new category attribute values for the System class that would = connect >>>> the list of included indicators. I think we should still keep the >>>> concept of a Node to a single node, but perhaps within System, list >>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>> help solve the issue as NodeRole values would compliment an >>>> AttackType (FraudType values could be included in AttackType or = some >>>> broader term). It may be better to have the FraudTypes, plus >>>> attribute values like "C2-server", "sinkhole", = "MalwareDistribution" >>>> for added context so you know what to do with the received set of >>>> indicators. >>>>=20 >>>> I am proposing that we change IODEF to include multiple sets of >>>> indicators, add an AttackType attribute (or some other name), a >>>> method to connect indicators and indicator sets within an IODEF = using >>>> an attribute of indicator_uid (or some other name) with a string >>>> value to make the connection points, and add a few indicators that >>>> are commonly shared into the base IODEF. >>>>=20 >>>> Back in July, we talked about adding Registry Key/Value pairs and >>>> hashes to the main IODEF document (trying to see if this will help >>>> Chris below). What if we added the Registry Key/Value pairs as a >>>> class off of RecordData, using a similar structure to what is in >>>> RFC5901, and also added the ability to include hashes in = RecordData? >>>> I think if we then had the indicator_uid at the RecordData level, = we >>>> could connect a set within that structure and repeat the structure >>>> for other sets in the same way we would do with Node inside of the >>>> System class, using the indicator_uid to tie the set together. = Then >>>> at the more specific level for the hash, registry Key/value, IP, = etc. >>>> use an indicator_uid if we needed them marked at this level as = well? >>>> Maybe we want indicator_set at the higher level? I'd like some >>>> opinions on this approach. +1 if you agree, suggestions if you = have >>>> other ideas that may work better. >>>>=20 >>>> We'll also need to worry about marking the indicators to prevent >>>> forward sharing when not permitted. We may want to use these = values >>>> or something else. >>>>=20 >>>> Thank you! >>>> Kathleen >>>>=20 >>>> From: Harrington, Christopher >>>> Sent: Friday, February 01, 2013 12:01 PM >>>> To: Moriarty, Kathleen; MILE IETF >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> I think we have a bigger relationship issue to address. Let use the >>>> Watchlist Use Case. A bunch of indicators are sent in one message. = In >>>> that message we could have groupings of indicators that we need to >>>> show are >>>> related: >>>>=20 >>>> Two or more indicators of different type that relate to the same >>>> threat: >>>> The file hash of a malicious file and the URL of the C2 that >>>> the file uses. Either or both may be present to indicate a >>>> compromise. >>>>=20 >>>> Two or more indicators of the same type that relate to the same >>>> threat: >>>> 2 different registry values for the same registry key. If >>>> either value is present it is a compromise indicator but both will >>>> not be present. >>>>=20 >>>> The problem compounds itself very quickly. Consider the scenario >>>> where both groupings above are part of the same threat. I need to >>>> show that logical groupings of Indicators are related as well. We >>>> can't send multiple IODEF messages for this from what I remember >>>> reading. >>>>=20 >>>> The last one I can think of would be when you have 2 different >>>> indicators that represent the same indicator. It's not uncommon to >>>> send both the >>>> MD5 >>>> and SHA1 hash of a malicious file. The indicator is the file but = the >>>> IOCs are the 2 hash values. How do we show they are related? If we >>>> use a unique Inidcator ID for each hash value there needs to be a >>>> higher level grouping. >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> Christopher Harrington >>>> Consulting Security Engineer >>>> GSO - Critical Incident Response Center EMC - Where Information = Lives >>>> 174 Middlesex Turnpike >>>> Bedford, MA 01730 >>>> 781-515-5862 (work) >>>> 603-583-1585 (cell) >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Moriarty, Kathleen >>>> Sent: Friday, February 01, 2013 11:28 AM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> All - >>>>=20 >>>> I'd like your input and will refocus the thread to get opinions = from >>>> the list on options to help solve the problems raised in my message >>>> and additionally in Paul's message. >>>>=20 >>>> Interesting point, C. Henry. Our objective here is to have machine >>>> automated exchanges, so we rely on encryption rather than = obfuscation >>>> to achieve the necessary level of confidentiality. >>>>=20 >>>> Paul mentioned the need to distinguish indicators of compromise = from >>>> context information that may also include IP address or other data >>>> that could be indicators. The question I raised was on how to >>>> connect sets of indicators in the same IODEF document, assuming the >>>> ability to have watchlists that could have several sets of = indicators >>>> included, as well as to connect indicators that may be included in >>>> embedded schemas. >>>>=20 >>>> If we add an attribute on all of the relevant indicators, let's say >>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>> mark who sent the indicator as well so that we can prevent forward >>>> sharing when it is not permitted or handle that separately? >>>>=20 >>>> Then for indicators not included in the base schema that may not = fit >>>> into a category in the SCI draft, do we create a place for these = off >>>> of SCI or right off of the IODE schema in EventData? (more details = on >>>> this in my first message). >>>>=20 >>>> Comments and questions encouraged to figure out the right technical >>>> solution to have this machine automatable. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of C. >>>> Henry Adams & BIE >>>> Sent: Monday, January 28, 2013 11:25 PM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Temporal Dependency sounds interesting. I remember when I first = ran >>>> across this particular craft, an experienced colleague asked me a >>>> peculiar question. He said, " How do you stop someone from = tracking >>>> the IP Address to your computer?" >>>>=20 >>>> I replied, "I don't know, how?" >>>>=20 >>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>> connected- which is constantly on!" LOL >>>>=20 >>>> Here's my point (Hypothetical Situation) : There is a 1st = Responder >>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>> or let's just say "Live" Terrorist Situation. He /or She needs to >>>> communication back to other Officials that he /or somehow is in >>>> Danger. The device used to communicate has been captured by the >>>> great minds of the enemy. It's only a matter of time before they >>>> utilize reverse engineering to figure out how it functions. = However, >>>> their pride comes before a fall when seeking the location of other >>>> similar devices to attack. Why? Perhaps the less thought of = concepts >>>> that makes the device function properly, saves the day by disguise = or >>>> cutting it off (figuratively speaking). >>>>=20 >>>> Just a visionary thought. >>>>=20 >>>> C. Henry Adams >>>> chenryadams@biemediagroup.com >>>> http://biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>=20 >>>> From: Dave Misell >>>> Subject: Re: [mile] IOCs >>>> To: "C. Henry Adams & BIE" >>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>=20 >>>> Yours Faithfully, >>>>=20 >>>> Dave Misell MSc CISSP >>>> SilentCircle dsm >>>> 07710 380044 >>>> david.misell@bcs.org >>>>=20 >>>>=20 >>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>> >>>> wrote: >>>>=20 >>>> Serialization of a particular Lists of XML Classes in a unique way >>>> was closely related to what I attempted to express when I stated, >>>> "consider to a degree what appears to be illogical in brilliant = minds >>>> in some instances." >>>>=20 >>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>> would be nice if the UID was in some way disguised from those who >>>> study this Security Art Form in a negative way. >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> Re: [mile] IOCs >>>>=20 >>>> Sunday, January 27, 2013 8:52 PM >>>> From: >>>> "Stoecker, Paul" >>>> To: >>>> "mile@ietf.org" >>>> I would like to look at this from a slightly different >>>> perspectiveSlet's say I get an XML document that tells me about an >>>> incident. This document has source IP and destination IP that is >>>> being shared. However, what I don't know is which IP address is my >>>> indicator and which is just a contextual piece of information. = This >>>> means that my detection product isn't going to know which one to = use >>>> either, because there is nothing to tell me which IP is the one, = even >>>> if the roles are set it still might not be enough to tell my system >>>> which one I should use as the indicator. >>>>=20 >>>> If we had something like indicator_id as an attribute, it would = allow >>>> us to easily identify indicators from contextual data. I do admit = to >>>> being biased as I have spent much of my career working on the >>>> monitoring and detection side of these things, so I am just = thinking >>>> of ways to make it very clear what the indicators are in the XML >>>> document and the other data that may be important as I investigate >>>> activity that I have detected off of those indicators. >>>>=20 >>>>=20 >>>> I did suggest the detection class, but I think we may get more >>>> flexibility with the indicator_uid. One thing that I haven't >>>> considered is the UID portion of thisShow do we use that UID? How = is >>>> the UID created? Are there standards for UIDs? >>>>=20 >>>> Regards, >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>> wrote: >>>>=20 >>>> From: C. Henry Adams & BIE >>>> Subject: RE: [mile] IOCs >>>> To: "KathleenMoriarty" >>>> Cc: mile@ietf.org >>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>=20 >>>> Greetings Kathleen, >>>>=20 >>>> Your logic stimulates my visionary brain because I'm amazed at the >>>> many avenues you review with this approach at once. However, = could >>>> you share a few advantages and disadvantages to the latter? >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ---------------------------------------------- >>>> "we could continue to group items in logical places as is done now = in >>>> IODEF and then have the extension point for combined indicators via >>>> SCI." >>>> = -------------------------------------------------------------------- >>>> -------- >>>> --------------------------------------------- >>>>=20 >>>> You pointed out what you consider to be logical places, but if I >>>> wanted to protect information from parties capable of ascertaining = it >>>> from your logical places, perhaps we should also consider to a = degree >>>> what appears to be illogical in brilliant minds in some instances. >>>>=20 >>>>=20 >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) >>>> chenryadams@biemediagroup.com >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>> wrote: >>>>=20 >>>> From: Moriarty, Kathleen >>>> Subject: RE: [mile] IOCs >>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>> >>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>=20 >>>> Hello C. Henry & others, >>>>=20 >>>> Thanks for taking a look at this. We have a few considerations in >>>> this email thread I would like to hear thoughts on (and there may = be >>>> more once RFC5070-bis is actively edited). >>>>=20 >>>> The AdditionalData class and the RecordItem class both allow for >>>> non-XML extensions. Where you place the extensions should be >>>> specific to the logical grouping of the parent elements so you can >>>> understand more about the included data in most cases. >>>>=20 >>>> The Impact class can be used to provide context information on the >>>> included data of the report and also can include a confidence = rating >>>> on the report as a whole. Extensions related to impact would be = one >>>> level higher (at the moment) in the Assessment class using the >>>> AdditionalData extension point. >>>>=20 >>>> Take asked about including vulnerability information, I would think >>>> that would fit under the Vulnerability extension point of the SCI >>>> draft in the Method class. He did ask about non-XML. RecordItem = or >>>> AdditionalData do allow for non-XML extension points, we could = either >>>> have the SCI draft handle these as well or have the extensions that >>>> are non-XML come directly off the AdditionalData or RecordItem >>>> classes according to what makes sense from a logical standpoint. >>>>=20 >>>> As for my question, it was two-fold. >>>>=20 >>>> Indicator based schemas have a reference number or a GUID for the >>>> various indicators they share. If we are extending to embed other >>>> schemas that include such reference or GUID identifiers, do we want >>>> to add an attribute to the various elements in IODEF that could be >>>> indicators? Is this enough to make the connections or is something >>>> else else needed? We could add something like an Indicator_ID in >>>> RFC5070-bis which would then correlate to the reference or GUID >>>> identifiers. >>>>=20 >>>> Then the other question was on how to include indicators that are = not >>>> in the base schema that may be related or have language with "and" >>>> "or" >>>> to >>>> specify the relationships. In some cases, you will want to group >>>> these indictors in one extension point, where they may fit = logically >>>> in multiple places if the relationships did not need to be shown in >>>> the data format. If we have cases like this where you need more >>>> complex representations, should we use one extension point via the >>>> SCI draft off of the EventData class AdditionalData extension = point? >>>> Opinions are needed here.... >>>>=20 >>>> A few people have mentioned wanting to include some commonly shared >>>> indictors into the base IODEF document. We could have a catch-all >>>> class that does this and has an extension point off of it in >>>> EventData or we could continue to group items in logical places as = is >>>> done now in IODEF and then have the extension point for combined >>>> indicators via SCI. I think I like the latter approach. >>>>=20 >>>> Thank you, >>>> Kathleen >>>> ________________________________________ >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>> Henry >>>> Adams & BIE [chatlga2000@yahoo.com] >>>> Sent: Saturday, January 26, 2013 3:05 AM >>>> To: mile@ietf.org >>>> Cc: C. Henry Adams >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Greetings Everyone, >>>>=20 >>>> Take mentioned two types of indicators based on the : >>>> = -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>> 1) If the indicators are something like an XML-based alert/warning = of >>>> information leakage, it could be an event that are conveyed in the >>>> SCI's EventReport class, IMHO. >>>>=20 >>>> 2) If the indicators are something like an non-XML ones, I guess it >>>> could be conveyed without using SCI draft. >>>> For instance, we could use Impact class of the base IODEF to convey >>>> the indicators. >>>> We could for instance extend the list of indicators of the Impact >>>> class, if needed. >>>> = -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>>=20 >>>> In doing so he pointed out the "Impact Class" >>>>=20 >>>> Whereas, Kathleen stated, >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ------------------------- >>>> For the discussion below, I was thinking more of combined set with >>>> relationships that may be included in a single extension point, so >>>> that's why I was thinking about the EventData class, but there may = be >>>> better locations or a specific area within the EventData. >>>>=20 >>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ------------------------ >>>>=20 >>>> Kathleen thoughts related yet still with other indicators and the >>>> EventData Class. >>>>=20 >>>> Is there a possible way to create a new XML class which encompass >>>> combining the EventData, Detection and base IODEF classes to = simplify >>>> this issue? >>>>=20 >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) >>>> chenryadams@biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 From eburger-l@standardstrack.com Tue Feb 19 06:45:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262EA21F8904 for ; Tue, 19 Feb 2013 06:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dYUdcA3nG4t for ; Tue, 19 Feb 2013 06:45:37 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3821821F8832 for ; Tue, 19 Feb 2013 06:45:37 -0800 (PST) Received: from [141.161.20.235] (port=51865) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7oRm-0005oS-I0 for mile@ietf.org; Tue, 19 Feb 2013 06:45:30 -0800 Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Tue, 19 Feb 2013 09:45:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: MILE IETF X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:45:40 -0000 That's the purpose of allowing arbitrary (or, possibly well defined) = values to the tag. You can go entirely off the reservation = and make up stuff, but you can also create a standard name space to = promote interoperability. Going this route also lets you experiment and = then pick what does work in the wild, instead of us spending the next = two years arguing over what a confidence of 27 means. On Feb 19, 2013, at 9:28 AM, "Banghart, John" = wrote: > Chris, >=20 > I guess I'm envisioning a circumstance where the "meaning" of the = values > is agreed to between sharing partners offline. But you are correct, = that > the spec should allow for the that meaning to be characterized. >=20 > -John >=20 > On 2/19/13 7:24 AM, "Harrington, Christopher" > wrote: >=20 >> I would agree that flexibility is something to strive for. However = there >> isn't enough in the RFC to make the numeric confidence value = understood by >> the recipient and therefore actionable. =46rom the spec: >>=20 >> "numeric. The element content contains a number that conveys the >> confidence >> of the data. The semantics of this number outside the scope of this >> specification" >>=20 >> Based on that I can score my confidence with 1 being most confident = and >> 100 >> being least. Perfectly legitimate but would probably mess everybody = up. >> What >> if my scale is 1000 and yours is 100. I send you something with a = score of >> 100 you will think I am absolutely certain when I am only 10% so. = Knowing >> how sure the sender is about a piece of data shared is critical. If = the >> sender puts an arbitrary number in the field I have no point of = reference. >> It's meaningless to me. >>=20 >> We spell out what the relative value is for low/med/high. I know = those are >> self-explanatory but they are still spelled out. I would urge that we = do >> the >> same for a numeric value. If not there needs to be something added so = that >> in addition to the numeric value I have a point of reference for how >> certain >> you are based on the number you put there. >>=20 >> Thanks, >>=20 >> --Chris >>=20 >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Banghart, John >> Sent: Monday, February 18, 2013 7:42 AM >> To: Eric Burger; MILE IETF >> Subject: Re: [mile] IOCs >>=20 >> Eric, >>=20 >> Well, I think you answered your own initial question, but I'm going = to >> jump >> in anyway. :) >>=20 >> Generally speaking, I think we want to strike a balance between >> standardization and flexibility. We are unlikely to arrive at any = sort of >> one-size-fits-all scheme, no matter how long we talk about it. = Instead, >> we >> should be focusing on solidifying the areas we can all agree on, and = allow >> flexibility for those that we don't. It's an age old clich=E9, but = let's >> not >> let perfect be the enemy of the good. >>=20 >> -John >>=20 >> On 2/16/13 12:42 PM, "Eric Burger" = wrote: >>=20 >>> What is the justification for both numeric and enumerated values >>> (low/medium/high)? In general such a schema is begging for >>> interoperability problems. >>>=20 >>> I suppose I can understand both sides of the argument. On the We = Need >>> Numbers side is those that actually calculate a percentage or other >>> objective measure in the confidence may want to use those real = numbers. >>> As well, on the We Need Numbers side is the argument that three >>> enumerated values may not prove sufficient in the future. On the We >>> Need Enumerated Values side is confidence, other than 0% and 100%, = tend >>> to be arbitrary guesses. Putting a number on this value imparts a = level >>> of specificity that does not exist. Also, it is a lot easier to map >>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>=20 >>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>> wrote: >>>=20 >>>> That will work provided I (and everyone else) has a mapping for the >>>> numbers. I would prefer a simple low/med/high scheme. The more we = add >>>> the more you have to be able to differentiate between them. However >>>> for potential interoperability I do see the benefit of the 5. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> From: Moriarty, Kathleen >>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>> To: Harrington, Christopher; MILE IETF >>>> Subject: RE: [mile] IOCs >>>>=20 >>>>=20 >>>> If you think of IODEF just for transport, could you meet your needs >>>> with storing the values differently in a database (IODEF is just = meant >>>> for the exchange)? The numbers map to low/med/high - for db = storage - >>>> if numbers are used, you could store the equivalent value, adding = the >>>> 2 additional ones provided. >>>>=20 >>>> Does it make sense to expand the set of values to match what CIF is >>>> doing if we went forward with the approach of supporting both = options? >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Harrington, Christopher >>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> =46rom a data processing standpoint it is going to create extra = work >>>> for the people who are going to receive this data if we support = both >>>> numeric and alpha characters in the same field. I can envision = people >>>> wanting to search, sort, store, etc the data in this field. If we >>>> allow both data types then everyone will need to have a mapping of >>>> some sort. I have a field for confidence in my threat tracking >>>> database. Having both a numeric score and alpha characters / words >>>> creates issues when trying to interact with the data. I agree that = we >>>> need to support both however I don't think both should be in the = same >>>> field. I would much rather see 2 different fields for Confidence if = we >>>> are going to support 2 different data types. >>>>=20 >>>> This will be a larger issue should Confidence be used elsewhere. >>>> Ideally in future revisions I would like to see attribution = expressed >>>> as some form of attribution is almost always shared with an IoC. >>>> Currently there are 5 areas where we (EMC) uses confidence. >>>>=20 >>>> Indicator (how confident are you that this is a valid IoC) >>>> Indicator_Set (how confident are you that all of the indcators in = the >>>> set should be in the set) Campaign (how confident are you that all >>>> Indicator_Sets are part of this campaign) Threat Actor (how = confident >>>> are you that the Campaign is attributed to this Threat Actor) = Threat >>>> Actor type (how confident are you that this Theat Actor is APT, >>>> Crimeware, other) >>>>=20 >>>> The threat actor name and the threat actor type are usually the = first >>>> 2 things that anyone processing IoCs wants to know as they drive >>>> priority. >>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>> of information for us. Sorry to take us a little off the path but = I >>>> wanted to show where Confidence could be used. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of C. Henry Adams & BIE >>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Again, I would concur that both a numeric and subjective analysis = of >>>> the Confidence Rating needs to be express, but combined in a >>>> simplified schema as such below: >>>>=20 >>>> 1LL .... etc. >>>>=20 >>>> 2P >>>>=20 >>>> 3AC >>>>=20 >>>> 4U >>>>=20 >>>> 5I >>>>=20 >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D= Urgent, >>>> 5 =3D Imminent ) >>>>=20 >>>> Here's my point, perhaps a set of numeric related or associated >>>> definitions can lower the propagation of error regarding the = analysis. >>>>=20 >>>> Thanks, >>>> C. Henry Adams >>>>=20 >>>>=20 >>>> I agree that what we really need is both. In most situations a = low, >>>> medium and high may be acceptable but there are times when we will >>>> want to show that confidence in a situation is increasing or >>>> decreasing. If we are only looking at a three levels, we cannot >>>> express what is needed to show confidence is trending up on the = data >>>> being exchanged about the event. >>>>=20 >>>> Kathleen included the following in a previous message. >>>>=20 >>>> >>>>=20 >>>> Vs: >>>>=20 >>>> 85 >>>>=20 >>>> I really think we need to include both capabilities as John alluded >>>> to since confidence is not a three tiered item but something that = is >>>> indeed subjective and we need a means to show a reasonably accurate >>>> confidence index that the sender is trying to convey. >>>>=20 >>>> Kent Landfield >>>>=20 >>>> McAfee | An Intel Company >>>> Direct: +1.972.963.7096 >>>> Mobile: +1.817.637.8026 >>>> Web: www.mcafee.com >>>>=20 >>>> From: , John Banghart >>>> Date: Wednesday, February 13, 2013 7:16 AM >>>> To: "Stoecker, Paul" , Kathleen Moriarty >>>> , Brian Trammell = >>>> Cc: "C. Henry Adams & BIE" , MILE IETF >>>> >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Paul, >>>>=20 >>>> I agree that confidence is subjective, but subjectivity can be >>>> reduced within communities that interact frequently. = Prioritization >>>> of indicators and response between tightly connected sharing = partners >>>> might require a more specific level of detail, particularly during = a >>>> crisis situation. >>>>=20 >>>> =46rom that perspective, I think the guidance should allow for >>>> additional granularity, while stressing the "high, medium, low" as >>>> preferred for broad interoperability. >>>>=20 >>>> -John >>>>=20 >>>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>>=20 >>>> I may have been too succinct in my response ;-) >>>>=20 >>>> Confidence is a subjective thing, so I think we should use = subjective >>>> terms: Low, Medium, High. Having a numeric scale with a map that >>>> essentially would say something like: >>>>=20 >>>> 1-33 =3D Low >>>> 34-67=3D Medium >>>> 68-100=3DHigh >>>>=20 >>>> Is just a more complicated way of saying that something is Low, >>>> Medium, High...do we really thing that how High something is makes >>>> that much of a difference? >>>>=20 >>>> This is like when you get your Performance review where it is Does >>>> Not Meet, Meets and Exceeds...your boss tells you that you are a = High >>>> Meets...your bonus tells you that you got the same bonus that all = the >>>> other Meets got >>>> ;-) >>>>=20 >>>> Anyway, I digress but trying to prove a point that I would argue = that >>>> confidence in this case is going to be basically a gut feeling, so = why >>>> use numeric values when Low, Medium, High would do just fine. >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" = >>>> wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> Both approaches will validate in the current schema. The >>>> representation looks a little different for each, here is an = example: >>>>=20 >>>> >>>>=20 >>>> Vs: >>>>=20 >>>> 85 >>>>=20 >>>> Searching capability is a great point, agreed. I'd like to hear = from >>>> more people to make sure we don't lose a capability that others = find >>>> extremely useful (need to gauge that). Other options is that the >>>> guidance can also discourage the use of the numeric in addition to >>>> specifying how to select ranges. >>>>=20 >>>> Any other opinions? >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: Stoecker, Paul >>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>> To: Brian Trammell >>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Cant we make Confidence a List that has only 3 values: High, = Medium, >>>> and Low? Any other value means that the Document will mot = validate >>>> against the schema. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>> >>>> wrote: >>>>=20 >>>> Hi, Kathleen, all, >>>>=20 >>>> I think 3.10.4 in 5070 takes the right approach here: trying to = build >>>> interoperable numeric scales for assessment is a very hard problem. >>>> (Were I charged with defining such a scale, the value "70" would = mean >>>> "we compared this incident report to N past similar incident = reports >>>> according to similarity algorithm S, and 70% of the past reports = had >>>> assessed impacts within E% of the actual, measured final impact -- = I >>>> think for most applications this is vastly more difficult and >>>> rigorous than it needs to be.) >>>>=20 >>>> Unless a numeric Confidence value is based on some actual, = repeatably >>>> measurable aspect of the Assessment report -- which I suspect in >>>> many/most/all cases it's not -- then it just represents a guess, >>>> however educated. Each team will probably naturally tune its own >>>> scales such that each value generally means the same thing in each >>>> report. Across teams, I don't know. >>>>=20 >>>> On the other hand, Assessments are by their very nature educated >>>> guesses, anyway, so I don't know that I'd find much use in = automating >>>> a response based on the assessment confidence. Chris has a good >>>> point, though -- it makes searching difficult and sorting kind of >> pointless. >>>>=20 >>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then = I >>>> agree, we should put that in the guidance document (along with a = note >>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>> of the users of this field use a 100-point scale with 100 meaning >>>> "yes" and 0 meaning "any resemblance these values may have to = actual >>>> fact is purely coincidental", then let's consider renaming it = "percent" >> in 5070-bis. >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as contributor) >>>>=20 >>>>=20 >>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>> wrote: >>>>=20 >>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>> change it if it needs to be changed. The value is for a confidence >>>> rating on the indicators shared. The definitions may be helpful = for >>>> anyone who wants to work on this discussion. IODEF has various >>>> markers that can be used in a complimentary way without conflating >>>> the markers meaning. >>>>=20 >>>> I think some people using IODEF find the numerical values more >>>> helpful, and it would be good to understand what people have = learned >>>> from using the current structure (what works/does not work). The >>>> scales I have seen are 0-100. There is of course a subjective >>>> element to assigning a numerical value to the confidence and it may >>>> vary from entity to entity. With this type of rating you may need = to >>>> consider who it came from and how they scored the confidence rating >>>> to map to your own rating. It would be good to hear more thoughts = on >> this. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>> To: MILE IETF >>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>> Subject: Re: [mile] IOCs >>>>=20 >>>>=20 >>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>> point. Different Confidence levels will cause confusion. It = appears >>>> that there maybe a need for some type of simplified standardization >>>> to be established between all Sharing Groups in this regard. >>>>=20 >>>> Perhaps numerical scoring set at lower values should express levels >>>> of urgency. >>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D= Urgent, >>>> 5 =3D Imminent ) >>>>=20 >>>> Thanks, >>>> C. Henry Adams >>>>=20 >>>>=20 >>>>=20 >>>> I see some confusion coming down the pike if we start using >>>> Confidence the way it is supported. If I am using low/med/high and >>>> someone sends me an IoC with a score of 70, what does that mean to >>>> me? What if I am using a scale of >>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the = ability >>>> to describe something with a consistent language. It really gets = ugly >>>> when we store IoC from multiple sources. I have confidence values >>>> that are numeric as well as text. Makes searching / sorting very >>>> problematic. >>>>=20 >>>> At this point we have to roll with what we have. I would strongly >>>> recommend that we revisit this at some point. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Hi Chris & Take, >>>>=20 >>>> I'll just focus on the confidence scoring. Right now, the schema >>>> allows for you to either use a numerical score OR the ratings of = low, >>>> medium, and high. >>>> Different sharing groups can decide how they want to share the = data. >>>> If >>>> people were to use the numerical values, I agree it would be = helpful >>>> to have guidance. This could go in the IODE guidance document. >>>>=20 >>>> I have seen examples of current users that use each of the >>>> approaches, so we'll need to keep the option for backwards >>>> compatibility and it is nice to keep in flexible options where we >>>> can. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: Harrington, Christopher >>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> The number of indicators wouldn't necessarily drive the use of >>>> indicator_set_id. The purpose is to show relationship. If I sent 3 = IP >>>> addresses that were used as C2 for 3 different campaigns I would = have >>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>=20 >>>> My suggestion would be a simple low, medium, high. I think if we >>>> break it down to more levels than that we would need to provide >>>> guidance on scoring, rating, etc. I think most people should be = able >>>> to understand low/med/high without having to have a mathematical >>>> method for arriving at the level. >>>>=20 >>>> Low - I am not sure >>>> Medium - I am reasonably sure >>>> High - I am very sure >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Regarding the indicator_set_id, I agree, it is useful when we need = to >>>> deal with large sets of indicators. >>>> Since indicator_set_id attribute is optional (right?), it could be >>>> omitted if we need to deal with only small number of indicators. >>>>=20 >>>> Regarding the use case, I like the idea of using the confidence >>>> attribute for the reason Chris kindly described. >>>> I would like to hear a bit more on this: is it going to be = numerical? >>>> For >>>> instance, 1 means "no confidence" while 5 means "strong = confidence", >>>> etc? >>>>=20 >>>> Thank you. >>>> Take >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] >>>> Sent: Friday, February 08, 2013 4:11 AM >>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> With respect to tying things back to threat actors, from what I = have >>>> seen and use this is a generally accepted grouping: >>>>=20 >>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>=20 >>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>> would be beneficial as making those associations is not a perfect >>>> science by any means. >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Thursday, February 07, 2013 2:00 PM >>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; = 'MILE >>>> IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> Hi Take & others, >>>>=20 >>>> Thanks for chiming in, I've been talking about this with Chris and = a >>>> few others on their use cases and would like more opinions. I'll >>>> provide an option below from what we have discussed from a CIRC = view >>>> point. We are also wondering how to also provide logic in IODEF = that >>>> could cross over into SCI attached schemas or IODEF extensions (the >>>> solutions may all tie together with this discussion - or there may = be >>>> better/more elegant solutions others would like to propose). >>>>=20 >>>> -----Original Message----- >>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>> 'MILE IETF' >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> I like this discussion. >>>> I agree, it would be good idea to have indicator identifiers inside >>>> the IOC-related classes. >>>>=20 >>>> KMM: At the class level, we may have several indicators listed that >>>> should be viewed as a set and may have another instance of that = same >>>> class that is a related issue, but a separate set. We could as you >>>> say, list the indicator IDs connected through the reference class. >>>> The set IDs might give us other ways to group the values when we = get >>>> into logic and relationships between sets or indicators. This = could >>>> also be a way to connect indicators or sets across XML documents = that >>>> could have been shared previously. If there are a large number of >>>> indicators in the set, then this becomes useful, for smaller sets, = I >>>> agree it doesn't make as much sense. >>>>=20 >>>> What do others think? >>>>=20 >>>> Then for indicators not included in the base schema that may not = fit >>>> into a category in the SCI draft, do we create a place for these = off >>>> of SCI or right off of the IODE schema in EventData? >>>> (more details >>>> on >>>> this in my first message). >>>>=20 >>>> If we could see any indicator of compromise as computer event = record, >>>> we could use SCI:EventReport class as the place for the XML-based >>>> IOCs that couldn't fit anywhere else. >>>>=20 >>>> KMM: That sounds like a good idea to me. This should go into >>>> guidance in the SCI draft. Does anyone else want to weigh in? >>>>=20 >>>>=20 >>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>> KMM: Sounds good, thanks! >>>>=20 >>>> I agree to have indicator_uid, but I am not sure about the needs of >>>> the indicator_set_id. >>>> I understand we could do some grouping of individual indicator_uids >>>> and its usability, but I am not sure whether we do not have any = other >>>> way to express these groupings. >>>> For instance, a Reference class refers to several indicadtor_uids. >>>> In >>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>=20 >>>> KMM: It may be, what do you think about large sets of indicators or >>>> subsequent messages that add indicators to existing sets? Would = this >>>> happen? Would it be easier to express relationships with sets of >>>> indicators in addition to individual indicators? By using this, it >>>> could give us a unique way to also provide the logic and >>>> relationships in a new class of IODEF so we don't have to worry = about >>>> adding it into the current structure. >>>> If there are better ways to handle that, and others can provide = some >>>> options, that would be appreciated! >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> I would appreciate if anybody could share expertise on this. Though = I >>>> think I have read all the emails in the list, I might have >>>> mis-understood some points. >>>>=20 >>>> By the way, I think the indicator_uids should be added to the SCI >>>> classes' >>>> attributes so that they can be correlated with another information = as >>>> well. >>>>=20 >>>> Thanks >>>> Take >>>>=20 >>>>=20 >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Harrington, Christopher >>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> I think some sort of group ID would do the trick. We also need a >>>> logical and / or somewhere to show relationship between indicators. >>>> If >>>> I give you >>>> 2 >>>> registry keys do they both have to be present to be an indication = of >>>> compromise or is either one by themselves an indicator? Both would >>>> have the same group ID since they are related. >>>>=20 >>>> Thanks, >>>> --Chris >>>>=20 >>>> From: Stoecker, Paul >>>> Sent: Sunday, February 03, 2013 8:26 PM >>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> What if we added indicator group ID along with the indicator_uid? >>>> This would allow you to group indicators that are related into the >>>> same group ID. >>>> Would this resolve the issue? >>>>=20 >>>> It is either that or going back to adding a Detection (or = Indicators) >>>> class that will should be used to take all of the indicators put = them >>>> into one place and have the ability to group the ones that go >>>> together. I don't mean a place to put indicators that are missing >>>> from IODEF.I mean a place in the IODEF document where you put the >>>> indicators that are used for detection and prevention of the shared >>>> Incident. I don't know the answer here, but there has got to be a >>>> good way for indicators to be identified and being able to group = them >>>> as Chris has suggested without basically recreating something >>>> complicated like STIX. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>>=20 >>>> From: , Kathleen >>>> Date: Sunday, February 3, 2013 5:11 PM >>>> To: "Harrington, Christopher" , = MILE >>>> IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Hi Chris, >>>>=20 >>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>=20 >>>> The list has already said they would like to see indicators added = to >>>> the definitions in RFC5070-bis, to be more explicit about including >>>> indicators and sets of indicators in IODE documents as opposed to >>>> 'parts of an incident or the useful information on an incident for >>>> sharing purposes. It was written before we used terms like >>>> indicators. With that in mind, Rosella proposed a number of = changes >>>> back in July, both for guidance and for format updates. It may = help >>>> to have the first draft try to address at least some of these = issues >>>> so people can understand the problems and at least a proposed >>>> solution. >>>>=20 >>>> As you point out, we need to be able to show relationships between >>>> sets of indicators, where we may have a few sets of indicators that >>>> could have a relationship to each other within a document. In the >>>> July presentation, one of the questions was to see if we should add >>>> new category attribute values for the System class that would = connect >>>> the list of included indicators. I think we should still keep the >>>> concept of a Node to a single node, but perhaps within System, list >>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>> help solve the issue as NodeRole values would compliment an >>>> AttackType (FraudType values could be included in AttackType or = some >>>> broader term). It may be better to have the FraudTypes, plus >>>> attribute values like "C2-server", "sinkhole", = "MalwareDistribution" >>>> for added context so you know what to do with the received set of >>>> indicators. >>>>=20 >>>> I am proposing that we change IODEF to include multiple sets of >>>> indicators, add an AttackType attribute (or some other name), a >>>> method to connect indicators and indicator sets within an IODEF = using >>>> an attribute of indicator_uid (or some other name) with a string >>>> value to make the connection points, and add a few indicators that >>>> are commonly shared into the base IODEF. >>>>=20 >>>> Back in July, we talked about adding Registry Key/Value pairs and >>>> hashes to the main IODEF document (trying to see if this will help >>>> Chris below). What if we added the Registry Key/Value pairs as a >>>> class off of RecordData, using a similar structure to what is in >>>> RFC5901, and also added the ability to include hashes in = RecordData? >>>> I think if we then had the indicator_uid at the RecordData level, = we >>>> could connect a set within that structure and repeat the structure >>>> for other sets in the same way we would do with Node inside of the >>>> System class, using the indicator_uid to tie the set together. = Then >>>> at the more specific level for the hash, registry Key/value, IP, = etc. >>>> use an indicator_uid if we needed them marked at this level as = well? >>>> Maybe we want indicator_set at the higher level? I'd like some >>>> opinions on this approach. +1 if you agree, suggestions if you = have >>>> other ideas that may work better. >>>>=20 >>>> We'll also need to worry about marking the indicators to prevent >>>> forward sharing when not permitted. We may want to use these = values >>>> or something else. >>>>=20 >>>> Thank you! >>>> Kathleen >>>>=20 >>>> From: Harrington, Christopher >>>> Sent: Friday, February 01, 2013 12:01 PM >>>> To: Moriarty, Kathleen; MILE IETF >>>> Subject: RE: [mile] IOCs >>>>=20 >>>> I think we have a bigger relationship issue to address. Let use the >>>> Watchlist Use Case. A bunch of indicators are sent in one message. = In >>>> that message we could have groupings of indicators that we need to >>>> show are >>>> related: >>>>=20 >>>> Two or more indicators of different type that relate to the same >>>> threat: >>>> The file hash of a malicious file and the URL of the C2 that >>>> the file uses. Either or both may be present to indicate a >>>> compromise. >>>>=20 >>>> Two or more indicators of the same type that relate to the same >>>> threat: >>>> 2 different registry values for the same registry key. If >>>> either value is present it is a compromise indicator but both will >>>> not be present. >>>>=20 >>>> The problem compounds itself very quickly. Consider the scenario >>>> where both groupings above are part of the same threat. I need to >>>> show that logical groupings of Indicators are related as well. We >>>> can't send multiple IODEF messages for this from what I remember >>>> reading. >>>>=20 >>>> The last one I can think of would be when you have 2 different >>>> indicators that represent the same indicator. It's not uncommon to >>>> send both the >>>> MD5 >>>> and SHA1 hash of a malicious file. The indicator is the file but = the >>>> IOCs are the 2 hash values. How do we show they are related? If we >>>> use a unique Inidcator ID for each hash value there needs to be a >>>> higher level grouping. >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, >>>>=20 >>>> --Chris >>>>=20 >>>> Christopher Harrington >>>> Consulting Security Engineer >>>> GSO - Critical Incident Response Center EMC - Where Information = Lives >>>> 174 Middlesex Turnpike >>>> Bedford, MA 01730 >>>> 781-515-5862 (work) >>>> 603-583-1585 (cell) >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Moriarty, Kathleen >>>> Sent: Friday, February 01, 2013 11:28 AM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> All - >>>>=20 >>>> I'd like your input and will refocus the thread to get opinions = from >>>> the list on options to help solve the problems raised in my message >>>> and additionally in Paul's message. >>>>=20 >>>> Interesting point, C. Henry. Our objective here is to have machine >>>> automated exchanges, so we rely on encryption rather than = obfuscation >>>> to achieve the necessary level of confidentiality. >>>>=20 >>>> Paul mentioned the need to distinguish indicators of compromise = from >>>> context information that may also include IP address or other data >>>> that could be indicators. The question I raised was on how to >>>> connect sets of indicators in the same IODEF document, assuming the >>>> ability to have watchlists that could have several sets of = indicators >>>> included, as well as to connect indicators that may be included in >>>> embedded schemas. >>>>=20 >>>> If we add an attribute on all of the relevant indicators, let's say >>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>> mark who sent the indicator as well so that we can prevent forward >>>> sharing when it is not permitted or handle that separately? >>>>=20 >>>> Then for indicators not included in the base schema that may not = fit >>>> into a category in the SCI draft, do we create a place for these = off >>>> of SCI or right off of the IODE schema in EventData? (more details = on >>>> this in my first message). >>>>=20 >>>> Comments and questions encouraged to figure out the right technical >>>> solution to have this machine automatable. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of C. >>>> Henry Adams & BIE >>>> Sent: Monday, January 28, 2013 11:25 PM >>>> To: MILE IETF >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Temporal Dependency sounds interesting. I remember when I first = ran >>>> across this particular craft, an experienced colleague asked me a >>>> peculiar question. He said, " How do you stop someone from = tracking >>>> the IP Address to your computer?" >>>>=20 >>>> I replied, "I don't know, how?" >>>>=20 >>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>> connected- which is constantly on!" LOL >>>>=20 >>>> Here's my point (Hypothetical Situation) : There is a 1st = Responder >>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>> or let's just say "Live" Terrorist Situation. He /or She needs to >>>> communication back to other Officials that he /or somehow is in >>>> Danger. The device used to communicate has been captured by the >>>> great minds of the enemy. It's only a matter of time before they >>>> utilize reverse engineering to figure out how it functions. = However, >>>> their pride comes before a fall when seeking the location of other >>>> similar devices to attack. Why? Perhaps the less thought of = concepts >>>> that makes the device function properly, saves the day by disguise = or >>>> cutting it off (figuratively speaking). >>>>=20 >>>> Just a visionary thought. >>>>=20 >>>> C. Henry Adams >>>> chenryadams@biemediagroup.com >>>> http://biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>=20 >>>> From: Dave Misell >>>> Subject: Re: [mile] IOCs >>>> To: "C. Henry Adams & BIE" >>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>=20 >>>> Yours Faithfully, >>>>=20 >>>> Dave Misell MSc CISSP >>>> SilentCircle dsm >>>> 07710 380044 >>>> david.misell@bcs.org >>>>=20 >>>>=20 >>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>> >>>> wrote: >>>>=20 >>>> Serialization of a particular Lists of XML Classes in a unique way >>>> was closely related to what I attempted to express when I stated, >>>> "consider to a degree what appears to be illogical in brilliant = minds >>>> in some instances." >>>>=20 >>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>> would be nice if the UID was in some way disguised from those who >>>> study this Security Art Form in a negative way. >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> Re: [mile] IOCs >>>>=20 >>>> Sunday, January 27, 2013 8:52 PM >>>> From: >>>> "Stoecker, Paul" >>>> To: >>>> "mile@ietf.org" >>>> I would like to look at this from a slightly different >>>> perspective=A9let's say I get an XML document that tells me about = an >>>> incident. This document has source IP and destination IP that is >>>> being shared. However, what I don't know is which IP address is my >>>> indicator and which is just a contextual piece of information. = This >>>> means that my detection product isn't going to know which one to = use >>>> either, because there is nothing to tell me which IP is the one, = even >>>> if the roles are set it still might not be enough to tell my system >>>> which one I should use as the indicator. >>>>=20 >>>> If we had something like indicator_id as an attribute, it would = allow >>>> us to easily identify indicators from contextual data. I do admit = to >>>> being biased as I have spent much of my career working on the >>>> monitoring and detection side of these things, so I am just = thinking >>>> of ways to make it very clear what the indicators are in the XML >>>> document and the other data that may be important as I investigate >>>> activity that I have detected off of those indicators. >>>>=20 >>>>=20 >>>> I did suggest the detection class, but I think we may get more >>>> flexibility with the indicator_uid. One thing that I haven't >>>> considered is the UID portion of this=A9how do we use that UID? = How is >>>> the UID created? Are there standards for UIDs? >>>>=20 >>>> Regards, >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>> Paul W. Stoecker, Ph.D. >>>> SMC Lead Content Architect >>>> RSA, The Security Division of EMC >>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>=20 >>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>> wrote: >>>>=20 >>>> From: C. Henry Adams & BIE >>>> Subject: RE: [mile] IOCs >>>> To: "KathleenMoriarty" >>>> Cc: mile@ietf.org >>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>=20 >>>> Greetings Kathleen, >>>>=20 >>>> Your logic stimulates my visionary brain because I'm amazed at the >>>> many avenues you review with this approach at once. However, = could >>>> you share a few advantages and disadvantages to the latter? >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ---------------------------------------------- >>>> "we could continue to group items in logical places as is done now = in >>>> IODEF and then have the extension point for combined indicators via >>>> SCI." >>>> = -------------------------------------------------------------------- >>>> -------- >>>> --------------------------------------------- >>>>=20 >>>> You pointed out what you consider to be logical places, but if I >>>> wanted to protect information from parties capable of ascertaining = it >>>> from your logical places, perhaps we should also consider to a = degree >>>> what appears to be illogical in brilliant minds in some instances. >>>>=20 >>>>=20 >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) >>>> chenryadams@biemediagroup.com >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>>=20 >>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>> wrote: >>>>=20 >>>> From: Moriarty, Kathleen >>>> Subject: RE: [mile] IOCs >>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>> >>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>=20 >>>> Hello C. Henry & others, >>>>=20 >>>> Thanks for taking a look at this. We have a few considerations in >>>> this email thread I would like to hear thoughts on (and there may = be >>>> more once RFC5070-bis is actively edited). >>>>=20 >>>> The AdditionalData class and the RecordItem class both allow for >>>> non-XML extensions. Where you place the extensions should be >>>> specific to the logical grouping of the parent elements so you can >>>> understand more about the included data in most cases. >>>>=20 >>>> The Impact class can be used to provide context information on the >>>> included data of the report and also can include a confidence = rating >>>> on the report as a whole. Extensions related to impact would be = one >>>> level higher (at the moment) in the Assessment class using the >>>> AdditionalData extension point. >>>>=20 >>>> Take asked about including vulnerability information, I would think >>>> that would fit under the Vulnerability extension point of the SCI >>>> draft in the Method class. He did ask about non-XML. RecordItem = or >>>> AdditionalData do allow for non-XML extension points, we could = either >>>> have the SCI draft handle these as well or have the extensions that >>>> are non-XML come directly off the AdditionalData or RecordItem >>>> classes according to what makes sense from a logical standpoint. >>>>=20 >>>> As for my question, it was two-fold. >>>>=20 >>>> Indicator based schemas have a reference number or a GUID for the >>>> various indicators they share. If we are extending to embed other >>>> schemas that include such reference or GUID identifiers, do we want >>>> to add an attribute to the various elements in IODEF that could be >>>> indicators? Is this enough to make the connections or is something >>>> else else needed? We could add something like an Indicator_ID in >>>> RFC5070-bis which would then correlate to the reference or GUID >>>> identifiers. >>>>=20 >>>> Then the other question was on how to include indicators that are = not >>>> in the base schema that may be related or have language with "and" >>>> "or" >>>> to >>>> specify the relationships. In some cases, you will want to group >>>> these indictors in one extension point, where they may fit = logically >>>> in multiple places if the relationships did not need to be shown in >>>> the data format. If we have cases like this where you need more >>>> complex representations, should we use one extension point via the >>>> SCI draft off of the EventData class AdditionalData extension = point? >>>> Opinions are needed here.... >>>>=20 >>>> A few people have mentioned wanting to include some commonly shared >>>> indictors into the base IODEF document. We could have a catch-all >>>> class that does this and has an extension point off of it in >>>> EventData or we could continue to group items in logical places as = is >>>> done now in IODEF and then have the extension point for combined >>>> indicators via SCI. I think I like the latter approach. >>>>=20 >>>> Thank you, >>>> Kathleen >>>> ________________________________________ >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>> Henry >>>> Adams & BIE [chatlga2000@yahoo.com] >>>> Sent: Saturday, January 26, 2013 3:05 AM >>>> To: mile@ietf.org >>>> Cc: C. Henry Adams >>>> Subject: Re: [mile] IOCs >>>>=20 >>>> Greetings Everyone, >>>>=20 >>>> Take mentioned two types of indicators based on the : >>>> = -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>> 1) If the indicators are something like an XML-based alert/warning = of >>>> information leakage, it could be an event that are conveyed in the >>>> SCI's EventReport class, IMHO. >>>>=20 >>>> 2) If the indicators are something like an non-XML ones, I guess it >>>> could be conveyed without using SCI draft. >>>> For instance, we could use Impact class of the base IODEF to convey >>>> the indicators. >>>> We could for instance extend the list of indicators of the Impact >>>> class, if needed. >>>> = -------------------------------------------------------------------- >>>> -------- >>>> -------------------------- >>>>=20 >>>> In doing so he pointed out the "Impact Class" >>>>=20 >>>> Whereas, Kathleen stated, >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ------------------------- >>>> For the discussion below, I was thinking more of combined set with >>>> relationships that may be included in a single extension point, so >>>> that's why I was thinking about the EventData class, but there may = be >>>> better locations or a specific area within the EventData. >>>>=20 >>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>> = -------------------------------------------------------------------- >>>> -------- >>>> ------------------------ >>>>=20 >>>> Kathleen thoughts related yet still with other indicators and the >>>> EventData Class. >>>>=20 >>>> Is there a possible way to create a new XML class which encompass >>>> combining the EventData, Detection and base IODEF classes to = simplify >>>> this issue? >>>>=20 >>>>=20 >>>> C. Henry Adams >>>> chatlga2000@yahoo.com (Direct Email) >>>> chenryadams@biemediagroup.com >>>>=20 >>>>=20 >>>> The information contained herein is for the exclusive use of the >>>> original recipient. This information is granted for limited >>>> distribution within the recipient's place of business for planning >>>> purposes only. Further dissemination, whether private or public is >>>> prohibited. >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >=20 From john.banghart@nist.gov Tue Feb 19 06:52:30 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606121F8DD5 for ; Tue, 19 Feb 2013 06:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRbshVe-aW0g for ; Tue, 19 Feb 2013 06:52:27 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 81BBB21F8DD3 for ; Tue, 19 Feb 2013 06:52:26 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Feb 2013 09:52:21 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 19 Feb 2013 09:52:14 -0500 From: "Banghart, John" To: Eric Burger , MILE IETF Date: Tue, 19 Feb 2013 09:52:10 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4OsLRA8itu7nTtQ9OzECO05PR1Ow== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:52:30 -0000 I think we agree. -John On 2/19/13 9:45 AM, "Eric Burger" wrote: >That's the purpose of allowing arbitrary (or, possibly well defined) >values to the tag. You can go entirely off the reservation >and make up stuff, but you can also create a standard name space to >promote interoperability. Going this route also lets you experiment and >then pick what does work in the wild, instead of us spending the next two >years arguing over what a confidence of 27 means. > >On Feb 19, 2013, at 9:28 AM, "Banghart, John" >wrote: > >> Chris, >> >> I guess I'm envisioning a circumstance where the "meaning" of the values >> is agreed to between sharing partners offline. But you are correct, >>that >> the spec should allow for the that meaning to be characterized. >> >> -John >> >> On 2/19/13 7:24 AM, "Harrington, Christopher" >> wrote: >> >>> I would agree that flexibility is something to strive for. However >>>there >>> isn't enough in the RFC to make the numeric confidence value >>>understood by >>> the recipient and therefore actionable. From the spec: >>> >>> "numeric. The element content contains a number that conveys the >>> confidence >>> of the data. The semantics of this number outside the scope of this >>> specification" >>> >>> Based on that I can score my confidence with 1 being most confident and >>> 100 >>> being least. Perfectly legitimate but would probably mess everybody up. >>> What >>> if my scale is 1000 and yours is 100. I send you something with a >>>score of >>> 100 you will think I am absolutely certain when I am only 10% so. >>>Knowing >>> how sure the sender is about a piece of data shared is critical. If the >>> sender puts an arbitrary number in the field I have no point of >>>reference. >>> It's meaningless to me. >>> >>> We spell out what the relative value is for low/med/high. I know those >>>are >>> self-explanatory but they are still spelled out. I would urge that we >>>do >>> the >>> same for a numeric value. If not there needs to be something added so >>>that >>> in addition to the numeric value I have a point of reference for how >>> certain >>> you are based on the number you put there. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>> Banghart, John >>> Sent: Monday, February 18, 2013 7:42 AM >>> To: Eric Burger; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Eric, >>> >>> Well, I think you answered your own initial question, but I'm going to >>> jump >>> in anyway. :) >>> >>> Generally speaking, I think we want to strike a balance between >>> standardization and flexibility. We are unlikely to arrive at any >>>sort of >>> one-size-fits-all scheme, no matter how long we talk about it. >>>Instead, >>> we >>> should be focusing on solidifying the areas we can all agree on, and >>>allow >>> flexibility for those that we don't. It's an age old clich=E9, but let= 's >>> not >>> let perfect be the enemy of the good. >>> >>> -John >>> >>> On 2/16/13 12:42 PM, "Eric Burger" >>>wrote: >>> >>>> What is the justification for both numeric and enumerated values >>>> (low/medium/high)? In general such a schema is begging for >>>> interoperability problems. >>>> >>>> I suppose I can understand both sides of the argument. On the We Need >>>> Numbers side is those that actually calculate a percentage or other >>>> objective measure in the confidence may want to use those real >>>>numbers. >>>> As well, on the We Need Numbers side is the argument that three >>>> enumerated values may not prove sufficient in the future. On the We >>>> Need Enumerated Values side is confidence, other than 0% and 100%, >>>>tend >>>> to be arbitrary guesses. Putting a number on this value imparts a >>>>level >>>> of specificity that does not exist. Also, it is a lot easier to map >>>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>> >>>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>>> wrote: >>>> >>>>> That will work provided I (and everyone else) has a mapping for the >>>>> numbers. I would prefer a simple low/med/high scheme. The more we >>>>>add >>>>> the more you have to be able to differentiate between them. However >>>>> for potential interoperability I do see the benefit of the 5. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>>> To: Harrington, Christopher; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> >>>>> If you think of IODEF just for transport, could you meet your needs >>>>> with storing the values differently in a database (IODEF is just >>>>>meant >>>>> for the exchange)? The numbers map to low/med/high - for db storage >>>>>- >>>>> if numbers are used, you could store the equivalent value, adding the >>>>> 2 additional ones provided. >>>>> >>>>> Does it make sense to expand the set of values to match what CIF is >>>>> doing if we went forward with the approach of supporting both >>>>>options? >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> From a data processing standpoint it is going to create extra work >>>>> for the people who are going to receive this data if we support both >>>>> numeric and alpha characters in the same field. I can envision people >>>>> wanting to search, sort, store, etc the data in this field. If we >>>>> allow both data types then everyone will need to have a mapping of >>>>> some sort. I have a field for confidence in my threat tracking >>>>> database. Having both a numeric score and alpha characters / words >>>>> creates issues when trying to interact with the data. I agree that we >>>>> need to support both however I don't think both should be in the same >>>>> field. I would much rather see 2 different fields for Confidence if >>>>>we >>>>> are going to support 2 different data types. >>>>> >>>>> This will be a larger issue should Confidence be used elsewhere. >>>>> Ideally in future revisions I would like to see attribution expressed >>>>> as some form of attribution is almost always shared with an IoC. >>>>> Currently there are 5 areas where we (EMC) uses confidence. >>>>> >>>>> Indicator (how confident are you that this is a valid IoC) >>>>> Indicator_Set (how confident are you that all of the indcators in the >>>>> set should be in the set) Campaign (how confident are you that all >>>>> Indicator_Sets are part of this campaign) Threat Actor (how >>>>>confident >>>>> are you that the Campaign is attributed to this Threat Actor) Threat >>>>> Actor type (how confident are you that this Theat Actor is APT, >>>>> Crimeware, other) >>>>> >>>>> The threat actor name and the threat actor type are usually the first >>>>> 2 things that anyone processing IoCs wants to know as they drive >>>>> priority. >>>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>>> of information for us. Sorry to take us a little off the path but I >>>>> wanted to show where Confidence could be used. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. Henry Adams & BIE >>>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Again, I would concur that both a numeric and subjective analysis of >>>>> the Confidence Rating needs to be express, but combined in a >>>>> simplified schema as such below: >>>>> >>>>> 1LL .... etc. >>>>> >>>>> 2P >>>>> >>>>> 3AC >>>>> >>>>> 4U >>>>> >>>>> 5I >>>>> >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Here's my point, perhaps a set of numeric related or associated >>>>> definitions can lower the propagation of error regarding the >>>>>analysis. >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> I agree that what we really need is both. In most situations a low, >>>>> medium and high may be acceptable but there are times when we will >>>>> want to show that confidence in a situation is increasing or >>>>> decreasing. If we are only looking at a three levels, we cannot >>>>> express what is needed to show confidence is trending up on the data >>>>> being exchanged about the event. >>>>> >>>>> Kathleen included the following in a previous message. >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> I really think we need to include both capabilities as John alluded >>>>> to since confidence is not a three tiered item but something that is >>>>> indeed subjective and we need a means to show a reasonably accurate >>>>> confidence index that the sender is trying to convey. >>>>> >>>>> Kent Landfield >>>>> >>>>> McAfee | An Intel Company >>>>> Direct: +1.972.963.7096 >>>>> Mobile: +1.817.637.8026 >>>>> Web: www.mcafee.com >>>>> >>>>> From: , John Banghart >>>>> Date: Wednesday, February 13, 2013 7:16 AM >>>>> To: "Stoecker, Paul" , Kathleen Moriarty >>>>> , Brian Trammell >>>>> Cc: "C. Henry Adams & BIE" , MILE IETF >>>>> >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Paul, >>>>> >>>>> I agree that confidence is subjective, but subjectivity can be >>>>> reduced within communities that interact frequently. Prioritization >>>>> of indicators and response between tightly connected sharing >>>>>partners >>>>> might require a more specific level of detail, particularly during a >>>>> crisis situation. >>>>> >>>>> From that perspective, I think the guidance should allow for >>>>> additional granularity, while stressing the "high, medium, low" as >>>>> preferred for broad interoperability. >>>>> >>>>> -John >>>>> >>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>>> >>>>> I may have been too succinct in my response ;-) >>>>> >>>>> Confidence is a subjective thing, so I think we should use subjective >>>>> terms: Low, Medium, High. Having a numeric scale with a map that >>>>> essentially would say something like: >>>>> >>>>> 1-33 =3D Low >>>>> 34-67=3D Medium >>>>> 68-100=3DHigh >>>>> >>>>> Is just a more complicated way of saying that something is Low, >>>>> Medium, High...do we really thing that how High something is makes >>>>> that much of a difference? >>>>> >>>>> This is like when you get your Performance review where it is Does >>>>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>>>> Meets...your bonus tells you that you got the same bonus that all the >>>>> other Meets got >>>>> ;-) >>>>> >>>>> Anyway, I digress but trying to prove a point that I would argue that >>>>> confidence in this case is going to be basically a gut feeling, so >>>>>why >>>>> use numeric values when Low, Medium, High would do just fine. >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Both approaches will validate in the current schema. The >>>>> representation looks a little different for each, here is an example: >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> Searching capability is a great point, agreed. I'd like to hear from >>>>> more people to make sure we don't lose a capability that others find >>>>> extremely useful (need to gauge that). Other options is that the >>>>> guidance can also discourage the use of the numeric in addition to >>>>> specifying how to select ranges. >>>>> >>>>> Any other opinions? >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Stoecker, Paul >>>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>>> To: Brian Trammell >>>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Cant we make Confidence a List that has only 3 values: High, Medium, >>>>> and Low? Any other value means that the Document will mot validate >>>>> against the schema. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>>> >>>>> wrote: >>>>> >>>>> Hi, Kathleen, all, >>>>> >>>>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>>>> interoperable numeric scales for assessment is a very hard problem. >>>>> (Were I charged with defining such a scale, the value "70" would mean >>>>> "we compared this incident report to N past similar incident reports >>>>> according to similarity algorithm S, and 70% of the past reports had >>>>> assessed impacts within E% of the actual, measured final impact -- I >>>>> think for most applications this is vastly more difficult and >>>>> rigorous than it needs to be.) >>>>> >>>>> Unless a numeric Confidence value is based on some actual, repeatably >>>>> measurable aspect of the Assessment report -- which I suspect in >>>>> many/most/all cases it's not -- then it just represents a guess, >>>>> however educated. Each team will probably naturally tune its own >>>>> scales such that each value generally means the same thing in each >>>>> report. Across teams, I don't know. >>>>> >>>>> On the other hand, Assessments are by their very nature educated >>>>> guesses, anyway, so I don't know that I'd find much use in automating >>>>> a response based on the assessment confidence. Chris has a good >>>>> point, though -- it makes searching difficult and sorting kind of >>> pointless. >>>>> >>>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>>>> agree, we should put that in the guidance document (along with a note >>>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>>> of the users of this field use a 100-point scale with 100 meaning >>>>> "yes" and 0 meaning "any resemblance these values may have to actual >>>>> fact is purely coincidental", then let's consider renaming it >>>>>"percent" >>> in 5070-bis. >>>>> >>>>> Best regards, >>>>> >>>>> Brian (as contributor) >>>>> >>>>> >>>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>>> change it if it needs to be changed. The value is for a confidence >>>>> rating on the indicators shared. The definitions may be helpful for >>>>> anyone who wants to work on this discussion. IODEF has various >>>>> markers that can be used in a complimentary way without conflating >>>>> the markers meaning. >>>>> >>>>> I think some people using IODEF find the numerical values more >>>>> helpful, and it would be good to understand what people have learned >>>>> from using the current structure (what works/does not work). The >>>>> scales I have seen are 0-100. There is of course a subjective >>>>> element to assigning a numerical value to the confidence and it may >>>>> vary from entity to entity. With this type of rating you may need to >>>>> consider who it came from and how they scored the confidence rating >>>>> to map to your own rating. It would be good to hear more thoughts on >>> this. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>>> To: MILE IETF >>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> >>>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>>> point. Different Confidence levels will cause confusion. It appears >>>>> that there maybe a need for some type of simplified standardization >>>>> to be established between all Sharing Groups in this regard. >>>>> >>>>> Perhaps numerical scoring set at lower values should express levels >>>>> of urgency. >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> >>>>> I see some confusion coming down the pike if we start using >>>>> Confidence the way it is supported. If I am using low/med/high and >>>>> someone sends me an IoC with a score of 70, what does that mean to >>>>> me? What if I am using a scale of >>>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>>>> to describe something with a consistent language. It really gets ugly >>>>> when we store IoC from multiple sources. I have confidence values >>>>> that are numeric as well as text. Makes searching / sorting very >>>>> problematic. >>>>> >>>>> At this point we have to roll with what we have. I would strongly >>>>> recommend that we revisit this at some point. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Chris & Take, >>>>> >>>>> I'll just focus on the confidence scoring. Right now, the schema >>>>> allows for you to either use a numerical score OR the ratings of low, >>>>> medium, and high. >>>>> Different sharing groups can decide how they want to share the data. >>>>> If >>>>> people were to use the numerical values, I agree it would be helpful >>>>> to have guidance. This could go in the IODE guidance document. >>>>> >>>>> I have seen examples of current users that use each of the >>>>> approaches, so we'll need to keep the option for backwards >>>>> compatibility and it is nice to keep in flexible options where we >>>>> can. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher >>>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> The number of indicators wouldn't necessarily drive the use of >>>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>>>> addresses that were used as C2 for 3 different campaigns I would have >>>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>> >>>>> My suggestion would be a simple low, medium, high. I think if we >>>>> break it down to more levels than that we would need to provide >>>>> guidance on scoring, rating, etc. I think most people should be able >>>>> to understand low/med/high without having to have a mathematical >>>>> method for arriving at the level. >>>>> >>>>> Low - I am not sure >>>>> Medium - I am reasonably sure >>>>> High - I am very sure >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>>> deal with large sets of indicators. >>>>> Since indicator_set_id attribute is optional (right?), it could be >>>>> omitted if we need to deal with only small number of indicators. >>>>> >>>>> Regarding the use case, I like the idea of using the confidence >>>>> attribute for the reason Chris kindly described. >>>>> I would like to hear a bit more on this: is it going to be numerical? >>>>> For >>>>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>>> etc? >>>>> >>>>> Thank you. >>>>> Take >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> With respect to tying things back to threat actors, from what I have >>>>> seen and use this is a generally accepted grouping: >>>>> >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>> >>>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Take & others, >>>>> >>>>> Thanks for chiming in, I've been talking about this with Chris and a >>>>> few others on their use cases and would like more opinions. I'll >>>>> provide an option below from what we have discussed from a CIRC view >>>>> point. We are also wondering how to also provide logic in IODEF that >>>>> could cross over into SCI attached schemas or IODEF extensions (the >>>>> solutions may all tie together with this discussion - or there may be >>>>> better/more elegant solutions others would like to propose). >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I like this discussion. >>>>> I agree, it would be good idea to have indicator identifiers inside >>>>> the IOC-related classes. >>>>> >>>>> KMM: At the class level, we may have several indicators listed that >>>>> should be viewed as a set and may have another instance of that same >>>>> class that is a related issue, but a separate set. We could as you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we get >>>>> into logic and relationships between sets or indicators. This could >>>>> also be a way to connect indicators or sets across XML documents that >>>>> could have been shared previously. If there are a large number of >>>>> indicators in the set, then this becomes useful, for smaller sets, I >>>>> agree it doesn't make as much sense. >>>>> >>>>> What do others think? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? >>>>> (more details >>>>> on >>>>> this in my first message). >>>>> >>>>> If we could see any indicator of compromise as computer event record, >>>>> we could use SCI:EventReport class as the place for the XML-based >>>>> IOCs that couldn't fit anywhere else. >>>>> >>>>> KMM: That sounds like a good idea to me. This should go into >>>>> guidance in the SCI draft. Does anyone else want to weigh in? >>>>> >>>>> >>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>>> KMM: Sounds good, thanks! >>>>> >>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>> the indicator_set_id. >>>>> I understand we could do some grouping of individual indicator_uids >>>>> and its usability, but I am not sure whether we do not have any other >>>>> way to express these groupings. >>>>> For instance, a Reference class refers to several indicadtor_uids. >>>>> In >>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>> >>>>> KMM: It may be, what do you think about large sets of indicators or >>>>> subsequent messages that add indicators to existing sets? Would this >>>>> happen? Would it be easier to express relationships with sets of >>>>> indicators in addition to individual indicators? By using this, it >>>>> could give us a unique way to also provide the logic and >>>>> relationships in a new class of IODEF so we don't have to worry about >>>>> adding it into the current structure. >>>>> If there are better ways to handle that, and others can provide some >>>>> options, that would be appreciated! >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> I would appreciate if anybody could share expertise on this. Though I >>>>> think I have read all the emails in the list, I might have >>>>> mis-understood some points. >>>>> >>>>> By the way, I think the indicator_uids should be added to the SCI >>>>> classes' >>>>> attributes so that they can be correlated with another information as >>>>> well. >>>>> >>>>> Thanks >>>>> Take >>>>> >>>>> >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between indicators. >>>>> If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>> >>>>> Thanks, >>>>> --Chris >>>>> >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>> >>>>> It is either that or going back to adding a Detection (or Indicators) >>>>> class that will should be used to take all of the indicators put them >>>>> into one place and have the ability to group the ones that go >>>>> together. I don't mean a place to put indicators that are missing >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the shared >>>>> Incident. I don't know the answer here, but there has got to be a >>>>> good way for indicators to be identified and being able to group them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> From: , Kathleen >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" , MILE >>>>> IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>> >>>>> The list has already said they would like to see indicators added to >>>>> the definitions in RFC5070-bis, to be more explicit about including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes. It was written before we used terms like >>>>> indicators. With that in mind, Rosella proposed a number of changes >>>>> back in July, both for guidance and for format updates. It may help >>>>> to have the first draft try to address at least some of these issues >>>>> so people can understand the problems and at least a proposed >>>>> solution. >>>>> >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators that >>>>> could have a relationship to each other within a document. In the >>>>> July presentation, one of the questions was to see if we should add >>>>> new category attribute values for the System class that would connect >>>>> the list of included indicators. I think we should still keep the >>>>> concept of a Node to a single node, but perhaps within System, list >>>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an >>>>> AttackType (FraudType values could be included in AttackType or some >>>>> broader term). It may be better to have the FraudTypes, plus >>>>> attribute values like "C2-server", "sinkhole", "MalwareDistribution" >>>>> for added context so you know what to do with the received set of >>>>> indicators. >>>>> >>>>> I am proposing that we change IODEF to include multiple sets of >>>>> indicators, add an AttackType attribute (or some other name), a >>>>> method to connect indicators and indicator sets within an IODEF using >>>>> an attribute of indicator_uid (or some other name) with a string >>>>> value to make the connection points, and add a few indicators that >>>>> are commonly shared into the base IODEF. >>>>> >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below). What if we added the Registry Key/Value pairs as a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, we >>>>> could connect a set within that structure and repeat the structure >>>>> for other sets in the same way we would do with Node inside of the >>>>> System class, using the indicator_uid to tie the set together. Then >>>>> at the more specific level for the hash, registry Key/value, IP, etc. >>>>> use an indicator_uid if we needed them marked at this level as well? >>>>> Maybe we want indicator_set at the higher level? I'd like some >>>>> opinions on this approach. +1 if you agree, suggestions if you have >>>>> other ideas that may work better. >>>>> >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted. We may want to use these values >>>>> or something else. >>>>> >>>>> Thank you! >>>>> Kathleen >>>>> >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I think we have a bigger relationship issue to address. Let use the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>> >>>>> Two or more indicators of different type that relate to the same >>>>> threat: >>>>> The file hash of a malicious file and the URL of the C2 that >>>>> the file uses. Either or both may be present to indicate a >>>>> compromise. >>>>> >>>>> Two or more indicators of the same type that relate to the same >>>>> threat: >>>>> 2 different registry values for the same registry key. If >>>>> either value is present it is a compromise indicator but both will >>>>> not be present. >>>>> >>>>> The problem compounds itself very quickly. Consider the scenario >>>>> where both groupings above are part of the same threat. I need to >>>>> show that logical groupings of Indicators are related as well. We >>>>> can't send multiple IODEF messages for this from what I remember >>>>> reading. >>>>> >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>>> IOCs are the 2 hash values. How do we show they are related? If we >>>>> use a unique Inidcator ID for each hash value there needs to be a >>>>> higher level grouping. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> All - >>>>> >>>>> I'd like your input and will refocus the thread to get opinions from >>>>> the list on options to help solve the problems raised in my message >>>>> and additionally in Paul's message. >>>>> >>>>> Interesting point, C. Henry. Our objective here is to have machine >>>>> automated exchanges, so we rely on encryption rather than obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>> >>>>> Paul mentioned the need to distinguish indicators of compromise from >>>>> context information that may also include IP address or other data >>>>> that could be indicators. The question I raised was on how to >>>>> connect sets of indicators in the same IODEF document, assuming the >>>>> ability to have watchlists that could have several sets of indicators >>>>> included, as well as to connect indicators that may be included in >>>>> embedded schemas. >>>>> >>>>> If we add an attribute on all of the relevant indicators, let's say >>>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>>> mark who sent the indicator as well so that we can prevent forward >>>>> sharing when it is not permitted or handle that separately? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? (more details on >>>>> this in my first message). >>>>> >>>>> Comments and questions encouraged to figure out the right technical >>>>> solution to have this machine automatable. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Temporal Dependency sounds interesting. I remember when I first ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question. He said, " How do you stop someone from tracking >>>>> the IP Address to your computer?" >>>>> >>>>> I replied, "I don't know, how?" >>>>> >>>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>>> connected- which is constantly on!" LOL >>>>> >>>>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>>> or let's just say "Live" Terrorist Situation. He /or She needs to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger. The device used to communicate has been captured by the >>>>> great minds of the enemy. It's only a matter of time before they >>>>> utilize reverse engineering to figure out how it functions. However, >>>>> their pride comes before a fall when seeking the location of other >>>>> similar devices to attack. Why? Perhaps the less thought of concepts >>>>> that makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>> >>>>> Just a visionary thought. >>>>> >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>> >>>>> From: Dave Misell >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>> >>>>> Yours Faithfully, >>>>> >>>>> Dave Misell MSc CISSP >>>>> SilentCircle dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>> >>>>> >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>>> >>>>> wrote: >>>>> >>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>> was closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant minds >>>>> in some instances." >>>>> >>>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>>> would be nice if the UID was in some way disguised from those who >>>>> study this Security Art Form in a negative way. >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> Re: [mile] IOCs >>>>> >>>>> Sunday, January 27, 2013 8:52 PM >>>>> From: >>>>> "Stoecker, Paul" >>>>> To: >>>>> "mile@ietf.org" >>>>> I would like to look at this from a slightly different >>>>> perspective=A9let's say I get an XML document that tells me about an >>>>> incident. This document has source IP and destination IP that is >>>>> being shared. However, what I don't know is which IP address is my >>>>> indicator and which is just a contextual piece of information. This >>>>> means that my detection product isn't going to know which one to use >>>>> either, because there is nothing to tell me which IP is the one, even >>>>> if the roles are set it still might not be enough to tell my system >>>>> which one I should use as the indicator. >>>>> >>>>> If we had something like indicator_id as an attribute, it would allow >>>>> us to easily identify indicators from contextual data. I do admit to >>>>> being biased as I have spent much of my career working on the >>>>> monitoring and detection side of these things, so I am just thinking >>>>> of ways to make it very clear what the indicators are in the XML >>>>> document and the other data that may be important as I investigate >>>>> activity that I have detected off of those indicators. >>>>> >>>>> >>>>> I did suggest the detection class, but I think we may get more >>>>> flexibility with the indicator_uid. One thing that I haven't >>>>> considered is the UID portion of this=A9how do we use that UID? How = is >>>>> the UID created? Are there standards for UIDs? >>>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>> wrote: >>>>> >>>>> From: C. Henry Adams & BIE >>>>> Subject: RE: [mile] IOCs >>>>> To: "KathleenMoriarty" >>>>> Cc: mile@ietf.org >>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>> >>>>> Greetings Kathleen, >>>>> >>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>> many avenues you review with this approach at once. However, could >>>>> you share a few advantages and disadvantages to the latter? >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>> "we could continue to group items in logical places as is done now in >>>>> IODEF and then have the extension point for combined indicators via >>>>> SCI." >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>> >>>>> You pointed out what you consider to be logical places, but if I >>>>> wanted to protect information from parties capable of ascertaining it >>>>> from your logical places, perhaps we should also consider to a degree >>>>> what appears to be illogical in brilliant minds in some instances. >>>>> >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>>> wrote: >>>>> >>>>> From: Moriarty, Kathleen >>>>> Subject: RE: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>>> >>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>> >>>>> Hello C. Henry & others, >>>>> >>>>> Thanks for taking a look at this. We have a few considerations in >>>>> this email thread I would like to hear thoughts on (and there may be >>>>> more once RFC5070-bis is actively edited). >>>>> >>>>> The AdditionalData class and the RecordItem class both allow for >>>>> non-XML extensions. Where you place the extensions should be >>>>> specific to the logical grouping of the parent elements so you can >>>>> understand more about the included data in most cases. >>>>> >>>>> The Impact class can be used to provide context information on the >>>>> included data of the report and also can include a confidence rating >>>>> on the report as a whole. Extensions related to impact would be one >>>>> level higher (at the moment) in the Assessment class using the >>>>> AdditionalData extension point. >>>>> >>>>> Take asked about including vulnerability information, I would think >>>>> that would fit under the Vulnerability extension point of the SCI >>>>> draft in the Method class. He did ask about non-XML. RecordItem or >>>>> AdditionalData do allow for non-XML extension points, we could either >>>>> have the SCI draft handle these as well or have the extensions that >>>>> are non-XML come directly off the AdditionalData or RecordItem >>>>> classes according to what makes sense from a logical standpoint. >>>>> >>>>> As for my question, it was two-fold. >>>>> >>>>> Indicator based schemas have a reference number or a GUID for the >>>>> various indicators they share. If we are extending to embed other >>>>> schemas that include such reference or GUID identifiers, do we want >>>>> to add an attribute to the various elements in IODEF that could be >>>>> indicators? Is this enough to make the connections or is something >>>>> else else needed? We could add something like an Indicator_ID in >>>>> RFC5070-bis which would then correlate to the reference or GUID >>>>> identifiers. >>>>> >>>>> Then the other question was on how to include indicators that are not >>>>> in the base schema that may be related or have language with "and" >>>>> "or" >>>>> to >>>>> specify the relationships. In some cases, you will want to group >>>>> these indictors in one extension point, where they may fit logically >>>>> in multiple places if the relationships did not need to be shown in >>>>> the data format. If we have cases like this where you need more >>>>> complex representations, should we use one extension point via the >>>>> SCI draft off of the EventData class AdditionalData extension point? >>>>> Opinions are needed here.... >>>>> >>>>> A few people have mentioned wanting to include some commonly shared >>>>> indictors into the base IODEF document. We could have a catch-all >>>>> class that does this and has an extension point off of it in >>>>> EventData or we could continue to group items in logical places as is >>>>> done now in IODEF and then have the extension point for combined >>>>> indicators via SCI. I think I like the latter approach. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>> To: mile@ietf.org >>>>> Cc: C. Henry Adams >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Greetings Everyone, >>>>> >>>>> Take mentioned two types of indicators based on the : >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> 1) If the indicators are something like an XML-based alert/warning of >>>>> information leakage, it could be an event that are conveyed in the >>>>> SCI's EventReport class, IMHO. >>>>> >>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>> could be conveyed without using SCI draft. >>>>> For instance, we could use Impact class of the base IODEF to convey >>>>> the indicators. >>>>> We could for instance extend the list of indicators of the Impact >>>>> class, if needed. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> >>>>> In doing so he pointed out the "Impact Class" >>>>> >>>>> Whereas, Kathleen stated, >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>> For the discussion below, I was thinking more of combined set with >>>>> relationships that may be included in a single extension point, so >>>>> that's why I was thinking about the EventData class, but there may be >>>>> better locations or a specific area within the EventData. >>>>> >>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>> >>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>> >>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to simplify >>>>> this issue? >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> 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 Paul.Stoecker@rsa.com Tue Feb 19 06:54:49 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ABA21F8C61 for ; Tue, 19 Feb 2013 06:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ypNyfrGbFrz for ; Tue, 19 Feb 2013 06:54:46 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AAB3B21F8D72 for ; Tue, 19 Feb 2013 06:54:44 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JEsf2K004581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 09:54:41 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 19 Feb 2013 09:54:21 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1JEsKoQ003895; Tue, 19 Feb 2013 09:54:20 -0500 Received: from mx33a.corp.emc.com ([169.254.1.215]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 19 Feb 2013 09:54:20 -0500 From: "Stoecker, Paul" To: Eric Burger , MILE IETF Date: Tue, 19 Feb 2013 09:54:16 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4OsP9HRRqau0ubTbSpF04k0PAlMg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:54:49 -0000 This is exactly my point. I would leave out the numeric ratings. I consume the data and at least with the enumerated type I don't have to also create a map if I want to get back to low, medium and high. I will have to make that transform anyway, so that my SOC knows the confidence without having to keep looking it up ;-) I like the simplicity of the enumerated type=8Apeople can take that and make it into whatever they want as far as numerics are concerned. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/19/13 9:43 AM, "Eric Burger" wrote: >If the proposal is 0-19 =3D low, 20-39 =3D =8A, 80-99 =3D high, then why d= o we >have the numbers, or why do we have the enumerated type? Either it is a >number or it is an enumerative value. Having both is asking for trouble. > >On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen" > wrote: > >> Should we provide guidance similar or the same as what CIF uses (was >>posted to the list previously)? They use direct mapping to 5 levels so >>that you can have ranges of numeric values used from 0-100, low to high. >> This would be the easiest solution... >> >> Thanks, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric >>Burger [eburger-l@standardstrack.com] >> Sent: Tuesday, February 19, 2013 7:38 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> If there really is no value to a value, do not let people hurt >>themselves. >> >> If there is a proprietary reason for a value, we should say what we >>mean and call it such. For example: >> >> This is XML so put your >>NON-INTEROPERABLE mumble you want here >> or >> 42 >> or >> >rating=3D"medium">balderdash>gToMe> >> >> On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" >> wrote: >> >>> I would agree that flexibility is something to strive for. However >>>there >>> isn't enough in the RFC to make the numeric confidence value >>>understood by >>> the recipient and therefore actionable. From the spec: >>> >>> "numeric. The element content contains a number that conveys the >>>confidence >>> of the data. The semantics of this number outside the scope of this >>> specification" >>> >>> Based on that I can score my confidence with 1 being most confident >>>and 100 >>> being least. Perfectly legitimate but would probably mess everybody >>>up. What >>> if my scale is 1000 and yours is 100. I send you something with a >>>score of >>> 100 you will think I am absolutely certain when I am only 10% so. >>>Knowing >>> how sure the sender is about a piece of data shared is critical. If the >>> sender puts an arbitrary number in the field I have no point of >>>reference. >>> It's meaningless to me. >>> >>> We spell out what the relative value is for low/med/high. I know those >>>are >>> self-explanatory but they are still spelled out. I would urge that we >>>do the >>> same for a numeric value. If not there needs to be something added so >>>that >>> in addition to the numeric value I have a point of reference for how >>>certain >>> you are based on the number you put there. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>> Banghart, John >>> Sent: Monday, February 18, 2013 7:42 AM >>> To: Eric Burger; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Eric, >>> >>> Well, I think you answered your own initial question, but I'm going to >>>jump >>> in anyway. :) >>> >>> Generally speaking, I think we want to strike a balance between >>> standardization and flexibility. We are unlikely to arrive at any >>>sort of >>> one-size-fits-all scheme, no matter how long we talk about it. >>>Instead, we >>> should be focusing on solidifying the areas we can all agree on, and >>>allow >>> flexibility for those that we don't. It's an age old clich=E9, but >>>let's not >>> let perfect be the enemy of the good. >>> >>> -John >>> >>> On 2/16/13 12:42 PM, "Eric Burger" >>>wrote: >>> >>>> What is the justification for both numeric and enumerated values >>>> (low/medium/high)? In general such a schema is begging for >>>> interoperability problems. >>>> >>>> I suppose I can understand both sides of the argument. On the We Need >>>> Numbers side is those that actually calculate a percentage or other >>>> objective measure in the confidence may want to use those real >>>>numbers. >>>> As well, on the We Need Numbers side is the argument that three >>>> enumerated values may not prove sufficient in the future. On the We >>>> Need Enumerated Values side is confidence, other than 0% and 100%, >>>>tend >>>> to be arbitrary guesses. Putting a number on this value imparts a >>>>level >>>> of specificity that does not exist. Also, it is a lot easier to map >>>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>> >>>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>>> wrote: >>>> >>>>> That will work provided I (and everyone else) has a mapping for the >>>>> numbers. I would prefer a simple low/med/high scheme. The more we >>>>>add >>>>> the more you have to be able to differentiate between them. However >>>>> for potential interoperability I do see the benefit of the 5. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>>> To: Harrington, Christopher; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> >>>>> If you think of IODEF just for transport, could you meet your needs >>>>> with storing the values differently in a database (IODEF is just >>>>>meant >>>>> for the exchange)? The numbers map to low/med/high - for db storage >>>>>- >>>>> if numbers are used, you could store the equivalent value, adding the >>>>> 2 additional ones provided. >>>>> >>>>> Does it make sense to expand the set of values to match what CIF is >>>>> doing if we went forward with the approach of supporting both >>>>>options? >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> From a data processing standpoint it is going to create extra work >>>>> for the people who are going to receive this data if we support both >>>>> numeric and alpha characters in the same field. I can envision people >>>>> wanting to search, sort, store, etc the data in this field. If we >>>>> allow both data types then everyone will need to have a mapping of >>>>> some sort. I have a field for confidence in my threat tracking >>>>> database. Having both a numeric score and alpha characters / words >>>>> creates issues when trying to interact with the data. I agree that we >>>>> need to support both however I don't think both should be in the same >>>>> field. I would much rather see 2 different fields for Confidence if >>>>>we >>>>> are going to support 2 different data types. >>>>> >>>>> This will be a larger issue should Confidence be used elsewhere. >>>>> Ideally in future revisions I would like to see attribution expressed >>>>> as some form of attribution is almost always shared with an IoC. >>>>> Currently there are 5 areas where we (EMC) uses confidence. >>>>> >>>>> Indicator (how confident are you that this is a valid IoC) >>>>> Indicator_Set (how confident are you that all of the indcators in the >>>>> set should be in the set) Campaign (how confident are you that all >>>>> Indicator_Sets are part of this campaign) Threat Actor (how >>>>>confident >>>>> are you that the Campaign is attributed to this Threat Actor) Threat >>>>> Actor type (how confident are you that this Theat Actor is APT, >>>>> Crimeware, other) >>>>> >>>>> The threat actor name and the threat actor type are usually the first >>>>> 2 things that anyone processing IoCs wants to know as they drive >>>>>priority. >>>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>>> of information for us. Sorry to take us a little off the path but I >>>>> wanted to show where Confidence could be used. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. Henry Adams & BIE >>>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Again, I would concur that both a numeric and subjective analysis of >>>>> the Confidence Rating needs to be express, but combined in a >>>>> simplified schema as such below: >>>>> >>>>> 1LL .... etc. >>>>> >>>>> 2P >>>>> >>>>> 3AC >>>>> >>>>> 4U >>>>> >>>>> 5I >>>>> >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Here's my point, perhaps a set of numeric related or associated >>>>> definitions can lower the propagation of error regarding the >>>>>analysis. >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> I agree that what we really need is both. In most situations a low, >>>>> medium and high may be acceptable but there are times when we will >>>>> want to show that confidence in a situation is increasing or >>>>> decreasing. If we are only looking at a three levels, we cannot >>>>> express what is needed to show confidence is trending up on the data >>>>> being exchanged about the event. >>>>> >>>>> Kathleen included the following in a previous message. >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> I really think we need to include both capabilities as John alluded >>>>> to since confidence is not a three tiered item but something that is >>>>> indeed subjective and we need a means to show a reasonably accurate >>>>> confidence index that the sender is trying to convey. >>>>> >>>>> Kent Landfield >>>>> >>>>> McAfee | An Intel Company >>>>> Direct: +1.972.963.7096 >>>>> Mobile: +1.817.637.8026 >>>>> Web: www.mcafee.com >>>>> >>>>> From: , John Banghart >>>>> Date: Wednesday, February 13, 2013 7:16 AM >>>>> To: "Stoecker, Paul" , Kathleen Moriarty >>>>> , Brian Trammell >>>>> Cc: "C. Henry Adams & BIE" , MILE IETF >>>>> >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Paul, >>>>> >>>>> I agree that confidence is subjective, but subjectivity can be >>>>> reduced within communities that interact frequently. Prioritization >>>>> of indicators and response between tightly connected sharing >>>>>partners >>>>> might require a more specific level of detail, particularly during a >>>>> crisis situation. >>>>> >>>>> From that perspective, I think the guidance should allow for >>>>> additional granularity, while stressing the "high, medium, low" as >>>>> preferred for broad interoperability. >>>>> >>>>> -John >>>>> >>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>>> >>>>> I may have been too succinct in my response ;-) >>>>> >>>>> Confidence is a subjective thing, so I think we should use subjective >>>>> terms: Low, Medium, High. Having a numeric scale with a map that >>>>> essentially would say something like: >>>>> >>>>> 1-33 =3D Low >>>>> 34-67=3D Medium >>>>> 68-100=3DHigh >>>>> >>>>> Is just a more complicated way of saying that something is Low, >>>>> Medium, High...do we really thing that how High something is makes >>>>> that much of a difference? >>>>> >>>>> This is like when you get your Performance review where it is Does >>>>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>>>> Meets...your bonus tells you that you got the same bonus that all the >>>>> other Meets got >>>>> ;-) >>>>> >>>>> Anyway, I digress but trying to prove a point that I would argue that >>>>> confidence in this case is going to be basically a gut feeling, so >>>>>why >>>>> use numeric values when Low, Medium, High would do just fine. >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Both approaches will validate in the current schema. The >>>>> representation looks a little different for each, here is an example: >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> Searching capability is a great point, agreed. I'd like to hear from >>>>> more people to make sure we don't lose a capability that others find >>>>> extremely useful (need to gauge that). Other options is that the >>>>> guidance can also discourage the use of the numeric in addition to >>>>> specifying how to select ranges. >>>>> >>>>> Any other opinions? >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Stoecker, Paul >>>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>>> To: Brian Trammell >>>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Cant we make Confidence a List that has only 3 values: High, Medium, >>>>> and Low? Any other value means that the Document will mot validate >>>>> against the schema. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>>> >>>>> wrote: >>>>> >>>>> Hi, Kathleen, all, >>>>> >>>>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>>>> interoperable numeric scales for assessment is a very hard problem. >>>>> (Were I charged with defining such a scale, the value "70" would mean >>>>> "we compared this incident report to N past similar incident reports >>>>> according to similarity algorithm S, and 70% of the past reports had >>>>> assessed impacts within E% of the actual, measured final impact -- I >>>>> think for most applications this is vastly more difficult and >>>>> rigorous than it needs to be.) >>>>> >>>>> Unless a numeric Confidence value is based on some actual, repeatably >>>>> measurable aspect of the Assessment report -- which I suspect in >>>>> many/most/all cases it's not -- then it just represents a guess, >>>>> however educated. Each team will probably naturally tune its own >>>>> scales such that each value generally means the same thing in each >>>>> report. Across teams, I don't know. >>>>> >>>>> On the other hand, Assessments are by their very nature educated >>>>> guesses, anyway, so I don't know that I'd find much use in automating >>>>> a response based on the assessment confidence. Chris has a good >>>>> point, though -- it makes searching difficult and sorting kind of >>> pointless. >>>>> >>>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>>>> agree, we should put that in the guidance document (along with a note >>>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>>> of the users of this field use a 100-point scale with 100 meaning >>>>> "yes" and 0 meaning "any resemblance these values may have to actual >>>>> fact is purely coincidental", then let's consider renaming it >>>>>"percent" >>> in 5070-bis. >>>>> >>>>> Best regards, >>>>> >>>>> Brian (as contributor) >>>>> >>>>> >>>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>>> change it if it needs to be changed. The value is for a confidence >>>>> rating on the indicators shared. The definitions may be helpful for >>>>> anyone who wants to work on this discussion. IODEF has various >>>>> markers that can be used in a complimentary way without conflating >>>>> the markers meaning. >>>>> >>>>> I think some people using IODEF find the numerical values more >>>>> helpful, and it would be good to understand what people have learned >>>>> from using the current structure (what works/does not work). The >>>>> scales I have seen are 0-100. There is of course a subjective >>>>> element to assigning a numerical value to the confidence and it may >>>>> vary from entity to entity. With this type of rating you may need to >>>>> consider who it came from and how they scored the confidence rating >>>>> to map to your own rating. It would be good to hear more thoughts on >>> this. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>>> To: MILE IETF >>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> >>>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>>> point. Different Confidence levels will cause confusion. It appears >>>>> that there maybe a need for some type of simplified standardization >>>>> to be established between all Sharing Groups in this regard. >>>>> >>>>> Perhaps numerical scoring set at lower values should express levels >>>>> of urgency. >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> >>>>> I see some confusion coming down the pike if we start using >>>>> Confidence the way it is supported. If I am using low/med/high and >>>>> someone sends me an IoC with a score of 70, what does that mean to >>>>> me? What if I am using a scale of >>>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>>>> to describe something with a consistent language. It really gets ugly >>>>> when we store IoC from multiple sources. I have confidence values >>>>> that are numeric as well as text. Makes searching / sorting very >>>>> problematic. >>>>> >>>>> At this point we have to roll with what we have. I would strongly >>>>> recommend that we revisit this at some point. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Chris & Take, >>>>> >>>>> I'll just focus on the confidence scoring. Right now, the schema >>>>> allows for you to either use a numerical score OR the ratings of low, >>>>> medium, and high. >>>>> Different sharing groups can decide how they want to share the data. >>>>> If >>>>> people were to use the numerical values, I agree it would be helpful >>>>> to have guidance. This could go in the IODE guidance document. >>>>> >>>>> I have seen examples of current users that use each of the >>>>> approaches, so we'll need to keep the option for backwards >>>>> compatibility and it is nice to keep in flexible options where we >>>>> can. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher >>>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> The number of indicators wouldn't necessarily drive the use of >>>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>>>> addresses that were used as C2 for 3 different campaigns I would have >>>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>> >>>>> My suggestion would be a simple low, medium, high. I think if we >>>>> break it down to more levels than that we would need to provide >>>>> guidance on scoring, rating, etc. I think most people should be able >>>>> to understand low/med/high without having to have a mathematical >>>>> method for arriving at the level. >>>>> >>>>> Low - I am not sure >>>>> Medium - I am reasonably sure >>>>> High - I am very sure >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>>> deal with large sets of indicators. >>>>> Since indicator_set_id attribute is optional (right?), it could be >>>>> omitted if we need to deal with only small number of indicators. >>>>> >>>>> Regarding the use case, I like the idea of using the confidence >>>>> attribute for the reason Chris kindly described. >>>>> I would like to hear a bit more on this: is it going to be numerical? >>>>> For >>>>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>>> etc? >>>>> >>>>> Thank you. >>>>> Take >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> With respect to tying things back to threat actors, from what I have >>>>> seen and use this is a generally accepted grouping: >>>>> >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>> >>>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Take & others, >>>>> >>>>> Thanks for chiming in, I've been talking about this with Chris and a >>>>> few others on their use cases and would like more opinions. I'll >>>>> provide an option below from what we have discussed from a CIRC view >>>>> point. We are also wondering how to also provide logic in IODEF that >>>>> could cross over into SCI attached schemas or IODEF extensions (the >>>>> solutions may all tie together with this discussion - or there may be >>>>> better/more elegant solutions others would like to propose). >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I like this discussion. >>>>> I agree, it would be good idea to have indicator identifiers inside >>>>> the IOC-related classes. >>>>> >>>>> KMM: At the class level, we may have several indicators listed that >>>>> should be viewed as a set and may have another instance of that same >>>>> class that is a related issue, but a separate set. We could as you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we get >>>>> into logic and relationships between sets or indicators. This could >>>>> also be a way to connect indicators or sets across XML documents that >>>>> could have been shared previously. If there are a large number of >>>>> indicators in the set, then this becomes useful, for smaller sets, I >>>>> agree it doesn't make as much sense. >>>>> >>>>> What do others think? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? >>>>> (more details >>>>> on >>>>> this in my first message). >>>>> >>>>> If we could see any indicator of compromise as computer event record, >>>>> we could use SCI:EventReport class as the place for the XML-based >>>>> IOCs that couldn't fit anywhere else. >>>>> >>>>> KMM: That sounds like a good idea to me. This should go into >>>>> guidance in the SCI draft. Does anyone else want to weigh in? >>>>> >>>>> >>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>>> KMM: Sounds good, thanks! >>>>> >>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>> the indicator_set_id. >>>>> I understand we could do some grouping of individual indicator_uids >>>>> and its usability, but I am not sure whether we do not have any other >>>>> way to express these groupings. >>>>> For instance, a Reference class refers to several indicadtor_uids. >>>>> In >>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>> >>>>> KMM: It may be, what do you think about large sets of indicators or >>>>> subsequent messages that add indicators to existing sets? Would this >>>>> happen? Would it be easier to express relationships with sets of >>>>> indicators in addition to individual indicators? By using this, it >>>>> could give us a unique way to also provide the logic and >>>>> relationships in a new class of IODEF so we don't have to worry about >>>>> adding it into the current structure. >>>>> If there are better ways to handle that, and others can provide some >>>>> options, that would be appreciated! >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> I would appreciate if anybody could share expertise on this. Though I >>>>> think I have read all the emails in the list, I might have >>>>> mis-understood some points. >>>>> >>>>> By the way, I think the indicator_uids should be added to the SCI >>>>> classes' >>>>> attributes so that they can be correlated with another information as >>>>> well. >>>>> >>>>> Thanks >>>>> Take >>>>> >>>>> >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between indicators. >>>>> If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>> >>>>> Thanks, >>>>> --Chris >>>>> >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>> >>>>> It is either that or going back to adding a Detection (or Indicators) >>>>> class that will should be used to take all of the indicators put them >>>>> into one place and have the ability to group the ones that go >>>>> together. I don't mean a place to put indicators that are missing >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the shared >>>>> Incident. I don't know the answer here, but there has got to be a >>>>> good way for indicators to be identified and being able to group them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> From: , Kathleen >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" , MILE >>>>> IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>> >>>>> The list has already said they would like to see indicators added to >>>>> the definitions in RFC5070-bis, to be more explicit about including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes. It was written before we used terms like >>>>> indicators. With that in mind, Rosella proposed a number of changes >>>>> back in July, both for guidance and for format updates. It may help >>>>> to have the first draft try to address at least some of these issues >>>>> so people can understand the problems and at least a proposed >>>>> solution. >>>>> >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators that >>>>> could have a relationship to each other within a document. In the >>>>> July presentation, one of the questions was to see if we should add >>>>> new category attribute values for the System class that would connect >>>>> the list of included indicators. I think we should still keep the >>>>> concept of a Node to a single node, but perhaps within System, list >>>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an >>>>> AttackType (FraudType values could be included in AttackType or some >>>>> broader term). It may be better to have the FraudTypes, plus >>>>> attribute values like "C2-server", "sinkhole", "MalwareDistribution" >>>>> for added context so you know what to do with the received set of >>>>> indicators. >>>>> >>>>> I am proposing that we change IODEF to include multiple sets of >>>>> indicators, add an AttackType attribute (or some other name), a >>>>> method to connect indicators and indicator sets within an IODEF using >>>>> an attribute of indicator_uid (or some other name) with a string >>>>> value to make the connection points, and add a few indicators that >>>>> are commonly shared into the base IODEF. >>>>> >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below). What if we added the Registry Key/Value pairs as a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, we >>>>> could connect a set within that structure and repeat the structure >>>>> for other sets in the same way we would do with Node inside of the >>>>> System class, using the indicator_uid to tie the set together. Then >>>>> at the more specific level for the hash, registry Key/value, IP, etc. >>>>> use an indicator_uid if we needed them marked at this level as well? >>>>> Maybe we want indicator_set at the higher level? I'd like some >>>>> opinions on this approach. +1 if you agree, suggestions if you have >>>>> other ideas that may work better. >>>>> >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted. We may want to use these values >>>>> or something else. >>>>> >>>>> Thank you! >>>>> Kathleen >>>>> >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I think we have a bigger relationship issue to address. Let use the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>> >>>>> Two or more indicators of different type that relate to the same >>>>> threat: >>>>> The file hash of a malicious file and the URL of the C2 that >>>>> the file uses. Either or both may be present to indicate a >>>>> compromise. >>>>> >>>>> Two or more indicators of the same type that relate to the same >>>>> threat: >>>>> 2 different registry values for the same registry key. If >>>>> either value is present it is a compromise indicator but both will >>>>> not be present. >>>>> >>>>> The problem compounds itself very quickly. Consider the scenario >>>>> where both groupings above are part of the same threat. I need to >>>>> show that logical groupings of Indicators are related as well. We >>>>> can't send multiple IODEF messages for this from what I remember >>>>> reading. >>>>> >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>>> IOCs are the 2 hash values. How do we show they are related? If we >>>>> use a unique Inidcator ID for each hash value there needs to be a >>>>> higher level grouping. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> All - >>>>> >>>>> I'd like your input and will refocus the thread to get opinions from >>>>> the list on options to help solve the problems raised in my message >>>>> and additionally in Paul's message. >>>>> >>>>> Interesting point, C. Henry. Our objective here is to have machine >>>>> automated exchanges, so we rely on encryption rather than obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>> >>>>> Paul mentioned the need to distinguish indicators of compromise from >>>>> context information that may also include IP address or other data >>>>> that could be indicators. The question I raised was on how to >>>>> connect sets of indicators in the same IODEF document, assuming the >>>>> ability to have watchlists that could have several sets of indicators >>>>> included, as well as to connect indicators that may be included in >>>>> embedded schemas. >>>>> >>>>> If we add an attribute on all of the relevant indicators, let's say >>>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>>> mark who sent the indicator as well so that we can prevent forward >>>>> sharing when it is not permitted or handle that separately? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? (more details on >>>>> this in my first message). >>>>> >>>>> Comments and questions encouraged to figure out the right technical >>>>> solution to have this machine automatable. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Temporal Dependency sounds interesting. I remember when I first ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question. He said, " How do you stop someone from tracking >>>>> the IP Address to your computer?" >>>>> >>>>> I replied, "I don't know, how?" >>>>> >>>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>>> connected- which is constantly on!" LOL >>>>> >>>>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>>> or let's just say "Live" Terrorist Situation. He /or She needs to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger. The device used to communicate has been captured by the >>>>> great minds of the enemy. It's only a matter of time before they >>>>> utilize reverse engineering to figure out how it functions. However, >>>>> their pride comes before a fall when seeking the location of other >>>>> similar devices to attack. Why? Perhaps the less thought of concepts >>>>> that makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>> >>>>> Just a visionary thought. >>>>> >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>> >>>>> From: Dave Misell >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>> >>>>> Yours Faithfully, >>>>> >>>>> Dave Misell MSc CISSP >>>>> SilentCircle dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>> >>>>> >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>>> >>>>> wrote: >>>>> >>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>> was closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant minds >>>>> in some instances." >>>>> >>>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>>> would be nice if the UID was in some way disguised from those who >>>>> study this Security Art Form in a negative way. >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> Re: [mile] IOCs >>>>> >>>>> Sunday, January 27, 2013 8:52 PM >>>>> From: >>>>> "Stoecker, Paul" >>>>> To: >>>>> "mile@ietf.org" >>>>> I would like to look at this from a slightly different >>>>> perspectiveSlet's say I get an XML document that tells me about an >>>>> incident. This document has source IP and destination IP that is >>>>> being shared. However, what I don't know is which IP address is my >>>>> indicator and which is just a contextual piece of information. This >>>>> means that my detection product isn't going to know which one to use >>>>> either, because there is nothing to tell me which IP is the one, even >>>>> if the roles are set it still might not be enough to tell my system >>>>> which one I should use as the indicator. >>>>> >>>>> If we had something like indicator_id as an attribute, it would allow >>>>> us to easily identify indicators from contextual data. I do admit to >>>>> being biased as I have spent much of my career working on the >>>>> monitoring and detection side of these things, so I am just thinking >>>>> of ways to make it very clear what the indicators are in the XML >>>>> document and the other data that may be important as I investigate >>>>> activity that I have detected off of those indicators. >>>>> >>>>> >>>>> I did suggest the detection class, but I think we may get more >>>>> flexibility with the indicator_uid. One thing that I haven't >>>>> considered is the UID portion of thisShow do we use that UID? How is >>>>> the UID created? Are there standards for UIDs? >>>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>> wrote: >>>>> >>>>> From: C. Henry Adams & BIE >>>>> Subject: RE: [mile] IOCs >>>>> To: "KathleenMoriarty" >>>>> Cc: mile@ietf.org >>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>> >>>>> Greetings Kathleen, >>>>> >>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>> many avenues you review with this approach at once. However, could >>>>> you share a few advantages and disadvantages to the latter? >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>> "we could continue to group items in logical places as is done now in >>>>> IODEF and then have the extension point for combined indicators via >>>>> SCI." >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>> >>>>> You pointed out what you consider to be logical places, but if I >>>>> wanted to protect information from parties capable of ascertaining it >>>>> from your logical places, perhaps we should also consider to a degree >>>>> what appears to be illogical in brilliant minds in some instances. >>>>> >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>>> wrote: >>>>> >>>>> From: Moriarty, Kathleen >>>>> Subject: RE: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>>> >>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>> >>>>> Hello C. Henry & others, >>>>> >>>>> Thanks for taking a look at this. We have a few considerations in >>>>> this email thread I would like to hear thoughts on (and there may be >>>>> more once RFC5070-bis is actively edited). >>>>> >>>>> The AdditionalData class and the RecordItem class both allow for >>>>> non-XML extensions. Where you place the extensions should be >>>>> specific to the logical grouping of the parent elements so you can >>>>> understand more about the included data in most cases. >>>>> >>>>> The Impact class can be used to provide context information on the >>>>> included data of the report and also can include a confidence rating >>>>> on the report as a whole. Extensions related to impact would be one >>>>> level higher (at the moment) in the Assessment class using the >>>>> AdditionalData extension point. >>>>> >>>>> Take asked about including vulnerability information, I would think >>>>> that would fit under the Vulnerability extension point of the SCI >>>>> draft in the Method class. He did ask about non-XML. RecordItem or >>>>> AdditionalData do allow for non-XML extension points, we could either >>>>> have the SCI draft handle these as well or have the extensions that >>>>> are non-XML come directly off the AdditionalData or RecordItem >>>>> classes according to what makes sense from a logical standpoint. >>>>> >>>>> As for my question, it was two-fold. >>>>> >>>>> Indicator based schemas have a reference number or a GUID for the >>>>> various indicators they share. If we are extending to embed other >>>>> schemas that include such reference or GUID identifiers, do we want >>>>> to add an attribute to the various elements in IODEF that could be >>>>> indicators? Is this enough to make the connections or is something >>>>> else else needed? We could add something like an Indicator_ID in >>>>> RFC5070-bis which would then correlate to the reference or GUID >>>>> identifiers. >>>>> >>>>> Then the other question was on how to include indicators that are not >>>>> in the base schema that may be related or have language with "and" >>>>> "or" >>>>> to >>>>> specify the relationships. In some cases, you will want to group >>>>> these indictors in one extension point, where they may fit logically >>>>> in multiple places if the relationships did not need to be shown in >>>>> the data format. If we have cases like this where you need more >>>>> complex representations, should we use one extension point via the >>>>> SCI draft off of the EventData class AdditionalData extension point? >>>>> Opinions are needed here.... >>>>> >>>>> A few people have mentioned wanting to include some commonly shared >>>>> indictors into the base IODEF document. We could have a catch-all >>>>> class that does this and has an extension point off of it in >>>>> EventData or we could continue to group items in logical places as is >>>>> done now in IODEF and then have the extension point for combined >>>>> indicators via SCI. I think I like the latter approach. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>> To: mile@ietf.org >>>>> Cc: C. Henry Adams >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Greetings Everyone, >>>>> >>>>> Take mentioned two types of indicators based on the : >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> 1) If the indicators are something like an XML-based alert/warning of >>>>> information leakage, it could be an event that are conveyed in the >>>>> SCI's EventReport class, IMHO. >>>>> >>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>> could be conveyed without using SCI draft. >>>>> For instance, we could use Impact class of the base IODEF to convey >>>>> the indicators. >>>>> We could for instance extend the list of indicators of the Impact >>>>> class, if needed. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> >>>>> In doing so he pointed out the "Impact Class" >>>>> >>>>> Whereas, Kathleen stated, >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>> For the discussion below, I was thinking more of combined set with >>>>> relationships that may be included in a single extension point, so >>>>> that's why I was thinking about the EventData class, but there may be >>>>> better locations or a specific area within the EventData. >>>>> >>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>> >>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>> >>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to simplify >>>>> this issue? >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From chatlga2000@yahoo.com Tue Feb 19 21:29:25 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8BB21F8802 for ; Tue, 19 Feb 2013 21:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.838 X-Spam-Level: ** X-Spam-Status: No, score=2.838 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBFEoNWDsuLx for ; Tue, 19 Feb 2013 21:29:19 -0800 (PST) Received: from nm40-vm6.bullet.mail.ne1.yahoo.com (nm40-vm6.bullet.mail.ne1.yahoo.com [98.138.229.182]) by ietfa.amsl.com (Postfix) with ESMTP id D647121F87D7 for ; Tue, 19 Feb 2013 21:29:11 -0800 (PST) Received: from [98.138.90.51] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2013 05:29:11 -0000 Received: from [98.138.89.193] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2013 05:29:11 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 20 Feb 2013 05:29:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 134549.44725.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 44899 invoked by uid 60001); 20 Feb 2013 05:29:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361338150; bh=n/4kB+cJac5A3FOFx3TnKTAsBuL+YqWxR903deqKjA8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=PkIHYbd/RtEwtvEtTopnunIvCtypR0y8ozwvtpZlyQWz/y33fF+BVn8tgbkBx3nRHU/J8bJUgcq0t3jprIQHiGSKa9JIkXta3bKhp1R/HnO4AYRoNL5/VG7wrY4Mygz/vHfleyjyE4GzZ3i5HtxwPYZQA3W7biq/kelcLikaqgM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=vwTw//FYruCnZUiC/dmC/OJMe3gQjf4873j+S4GhJRMPsoC8NsbrOQoJcEP9L4uVMtV3+qOfSR9tV/R7GTZNrFT4qzgoSfHd6ds8cNDNRjal5f72huilsSdN6rAHm/HF/MkZVzF+X2kQ+JnyQeeHdr8kLDvsYYERxBa4iExcMa8=; X-YMail-OSG: 4K4p69EVM1kQg4T2zEHCj6IId8.R7RZSj1p0FXi8mVhvyxZ W0VeX_NdfUegnyd.PBLbqUYBdnyHpoI6p2pJtCp0opcwY4IdhVWHpgkOdcdN 6hskkhi3jFzInrygRYwWKFkH7Ch8uqL9hnCX7qwkxWONQGBTWOeSI0yckNi3 nW2z_ME1HN_5ax8uV416ieNkkwU3HDfVs2jCYDUNg1miPpJTPmNBfQISZYhc f3AbHkt_K0lsiFBb5UExe0ATPhAJFU6yRwRcaQGTcAmgRjBiwKrEPgnU1CR0 SlWb_51Q1P0m1jJlvlONf6ldhqcdpavuSV_zWQDm6VqcOERFwUZqE6iSWu.8 7gHhp7EtQZxPhGP4ZXy0.NPI48W1whPQT7iSq8emxZHawA104DLat3FNNwnj ggXcPb9lXq7xC7rkGovCaFSSYjGoemQgiGU_sqBdLrGtbKt0Kn0K.I5QzMP5 6VQBjiPwcgScBSzsoELi7MUIE44LDlZ5tN6NKbraVV1utZ3V7l5OPjpEqKuF Ydfuiy5EACD8PNwjvs3yf41a_eYcm56XTu..c3mvY.uGIA3Q2vHrIIMiw Received: from [71.22.243.36] by web121604.mail.ne1.yahoo.com via HTTP; Tue, 19 Feb 2013 21:29:10 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEV2ZXJ5b25lLA0KDQpBZnRlciBmdXJ0aGVyIGNvbnNpZGVyYXRpb24swqAgSSBzdGlsbCB0ZW5kIHRvIGxlYW4gdG93YXJkIGEgc2ltcGxpZmllZCB2ZXJzaW9uIG9mIHRoZSBjb25maWRlbmNlIHJhdGluZy7CoCBXaGljaCBpbiBteSBvcGluaW9uLCBoYXMgbm93IGNoYW5nZWQgdG8gRU5VTSBvciBlbnVtZXJhdGVkIHR5cGUgT05MWS4NCg0KRnVydGhlcm1vcmUswqAgcGVyaGFwcyB7IGxvdywgbWVkaXVtLCBoaWdofSzCoCBzaG91bGQgYmUgYWx0ZXJlZCB0byBiZSB7bG93LCBtaW5vciwgbWUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361338150.43634.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Tue, 19 Feb 2013 21:29:10 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-1834828720-1361338150=:43634" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 05:29:25 -0000 ---36511695-1834828720-1361338150=:43634 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings Everyone, After further consideration,=C2=A0 I still tend to lean toward a simplified= version of the confidence rating.=C2=A0 Which in my opinion, has now chang= ed to ENUM or enumerated type ONLY. Furthermore,=C2=A0 perhaps { low, medium, high},=C2=A0 should be altered to= be {low, minor, medium, high, major} This has a low confidence rating of compromise This has a minor confidence rating of compromi= se This has a medium confidence rating of compro= mise This has a high confidence rating of compromise= This has a major confidence rating of compromi= se << Not sure if the statement below is logical, just Brainstorming>> Furthermore, let's say Low was map to 1.0.=C2=A0=C2=A0 Minor map to 2.0. Me= dium map to 3.0=C2=A0 High map to 4.0.=C2=A0 Major map to 5.0 The mapping procedure is the value built-in the ENUM.=C2=A0 (Please feel fr= ee to correct me if I'm wrong.) Then, simple statistical math is apply in some form to equate an overall va= lue of analysis. C. Henry Adams =0A This is exactly my point.=C2=A0 I would leave out the numeric ratings.=C2= =A0 I consume the data and at least with the enumerated type I don't have to also create a map if I want to get back to low, medium and high.=C2=A0 I wi= ll have to make that transform anyway, so that my SOC knows the confidence without having to keep looking it up ;-)=C2=A0 I like the simplicity of the enumerated type=C5=A0people can take that and make it into whatever they wa= nt as far as numerics are concerned. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/19/13 9:43 AM, "Eric Burger" wrote: >If the proposal is 0-19 =3D low, 20-39 =3D =C5=A0, 80-99 =3D high, then wh= y do we >have the numbers, or why do we have the enumerated type? Either it is a >number or it is an enumerative value. Having both is asking for trouble. > >On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen" > wrote: > >> Should we provide guidance similar or the same as what CIF uses (was >>posted to the list previously)?=C2=A0 They use direct mapping to 5 levels= so >>that you can have ranges of numeric values used from 0-100, low to high. >> This would be the easiest solution... >> >> Thanks, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric >>Burger [eburger-l@standardstrack.com] >> Sent: Tuesday, February 19, 2013 7:38 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> If there really is no value to a value, do not let people hurt >>themselves. >> >> If there is a proprietary reason for a value, we should say what we >>mean and call it such. For example: >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is XML so put= your >>NON-INTEROPERABLE mumble you want here >> or >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 42 >> or >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >rating=3D"medium">balderdash>gToMe> >> >> On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" >> wrote: >> >>> I would agree that flexibility is something to strive for. However >>>there >>> isn't enough in the RFC to make the numeric confidence value >>>understood by >>> the recipient and therefore actionable. From the spec: >>> >>> "numeric.=C2=A0 The element content contains a number that conveys the >>>confidence >>> of the data.=C2=A0 The semantics of this number outside the scope of th= is >>> specification" >>> >>> Based on that I can score my confidence with 1 being most confident >>>and 100 >>> being least. Perfectly legitimate but would probably mess everybody >>>up. What >>> if my scale is 1000 and yours is 100. I send you something with a >>>score of >>> 100 you will think I am absolutely certain when I am only 10% so. >>>Knowing >>> how sure the sender is about a piece of data shared is critical. If the >>> sender puts an arbitrary number in the field I have no point of >>>reference. >>> It's meaningless to me. >>> >>> We spell out what the relative value is for low/med/high. I know those >>>are >>> self-explanatory but they are still spelled out. I would urge that we >>>do the >>> same for a numeric value. If not there needs to be something added so >>>that >>> in addition to the numeric value I have a point of reference for how >>>certain >>> you are based on the number you put there. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>> Banghart, John >>> Sent: Monday, February 18, 2013 7:42 AM >>> To: Eric Burger; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Eric, >>> >>> Well, I think you answered your own initial question, but I'm going to >>>jump >>> in anyway.=C2=A0 :) >>> >>> Generally speaking, I think we want to strike a balance between >>> standardization and flexibility.=C2=A0 We are unlikely to arrive at any >>>sort of >>> one-size-fits-all scheme, no matter how long we talk about it. >>>Instead, we >>> should be focusing on solidifying the areas we can all agree on, and >>>allow >>> flexibility for those that we don't.=C2=A0 It's an age old clich=C3=A9,= but >>>let's not >>> let perfect be the enemy of the good. >>> >>> -John >>> >>> On 2/16/13 12:42 PM, "Eric Burger" >>>wrote: >>> >>>> What is the justification for both numeric and enumerated values >>>> (low/medium/high)?=C2=A0 In general such a schema is begging for >>>> interoperability problems. >>>> >>>> I suppose I can understand both sides of the argument.=C2=A0 On the We= Need >>>> Numbers side is those that actually calculate a percentage or other >>>> objective measure in the confidence may want to use those real >>>>numbers. >>>> As well, on the We Need Numbers side is the argument that three >>>> enumerated values may not prove sufficient in the future. On the We >>>> Need Enumerated Values side is confidence, other than 0% and 100%, >>>>tend >>>> to be arbitrary guesses. Putting a number on this value imparts a >>>>level >>>> of specificity that does not exist. Also, it is a lot easier to map >>>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>> >>>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>>> wrote: >>>> >>>>> That will work provided I (and everyone else) has a mapping for the >>>>> numbers.=C2=A0 I would prefer a simple low/med/high scheme. The more = we >>>>>add >>>>> the more you have to be able to differentiate between them. However >>>>> for potential interoperability I do see the benefit of the 5. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>>> To: Harrington, Christopher; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> >>>>> If you think of IODEF just for transport, could you meet your needs >>>>> with storing the values differently in a database (IODEF is just >>>>>meant >>>>> for the exchange)?=C2=A0 The numbers map to low/med/high - for db sto= rage >>>>>- >>>>> if numbers are used, you could store the equivalent value, adding the >>>>> 2 additional ones provided. >>>>> >>>>> Does it make sense to expand the set of values to match what CIF is >>>>> doing if we went forward with the approach of supporting both >>>>>options? >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> From a data processing standpoint it is going to create extra work >>>>> for the people who are going to receive this data if we support both >>>>> numeric and alpha characters in the same field. I can envision people >>>>> wanting to search, sort, store, etc the data in this field. If we >>>>> allow both data types then everyone will need to have a mapping of >>>>> some sort. I have a field for confidence in my threat tracking >>>>> database. Having both a numeric score and alpha characters / words >>>>> creates issues when trying to interact with the data. I agree that we >>>>> need to support both however I don't think both should be in the same >>>>> field. I would much rather see 2 different fields for Confidence if >>>>>we >>>>> are going to support 2 different data types. >>>>> >>>>> This will be a larger issue should Confidence be used elsewhere. >>>>> Ideally in future revisions I would like to see attribution expressed >>>>> as=C2=A0 some form of attribution is almost always shared with an IoC= . >>>>> Currently there are 5 areas where we=C2=A0 (EMC) uses confidence. >>>>> >>>>> Indicator (how confident are you that this is a valid IoC) >>>>> Indicator_Set (how confident are you that all of the indcators in the >>>>> set should be in the set)=C2=A0 Campaign (how confident are you that = all >>>>> Indicator_Sets are part of this campaign)=C2=A0 Threat Actor (how >>>>>confident >>>>> are you that the Campaign is attributed to this Threat Actor)=C2=A0 T= hreat >>>>> Actor type (how confident are you that this Theat Actor is APT, >>>>> Crimeware, other) >>>>> >>>>> The threat actor name and the threat actor type are usually the first >>>>> 2 things that anyone processing IoCs wants to know as they drive >>>>>priority. >>>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>>> of information for us.=C2=A0 Sorry to take us a little off the path b= ut I >>>>> wanted to show where Confidence could be used. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. Henry Adams & BIE >>>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Again, I would concur that both a numeric and subjective analysis of >>>>> the Confidence Rating needs to be express, but combined in a >>>>> simplified schema as such below: >>>>> >>>>> 1LL .... etc. >>>>> >>>>> 2P >>>>> >>>>> 3AC >>>>> >>>>> 4U >>>>> >>>>> 5I >>>>> >>>>> ( i.e.=C2=A0 1 =3D Less Likely,=C2=A0=C2=A0=C2=A02 =3D Probable,=C2= =A0 3 =3D A Concern,=C2=A0 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Here's my point, perhaps a set of numeric related or associated >>>>> definitions can lower the propagation of error regarding the >>>>>analysis. >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> I agree that what we really need is both.=C2=A0 In most situations a = low, >>>>> medium and high may be acceptable but there are times when we will >>>>> want to show that confidence in a situation is increasing or >>>>> decreasing.=C2=A0 If we are only looking at a three levels, we cannot >>>>> express what is needed to show confidence is trending up on the data >>>>> being exchanged about the event. >>>>> >>>>> Kathleen included the following in a previous message. >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> I really think we need to include both capabilities as John alluded >>>>> to since confidence is not a three tiered item but something that is >>>>> indeed subjective and we need a means to show a reasonably accurate >>>>> confidence index that the sender is trying to convey. >>>>> >>>>> Kent Landfield >>>>> >>>>> McAfee | An Intel Company >>>>> Direct: +1.972.963.7096 >>>>> Mobile: +1.817.637.8026 >>>>> Web: www.mcafee.com >>>>> >>>>> From: , John Banghart >>>>> Date: Wednesday, February 13, 2013 7:16 AM >>>>> To: "Stoecker, Paul" , Kathleen Moriarty >>>>> , Brian Trammell >>>>> Cc: "C. Henry Adams & BIE" , MILE IETF >>>>> >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Paul, >>>>> >>>>> I agree that confidence is subjective, but subjectivity can be >>>>> reduced=C2=A0 within communities that interact frequently.=C2=A0 Prio= ritization >>>>> of indicators=C2=A0 and response between tightly connected sharing >>>>>partners >>>>> might require a=C2=A0 more specific level of detail, particularly dur= ing a >>>>> crisis situation. >>>>> >>>>> From that perspective, I think the guidance should allow for >>>>> additional granularity, while stressing the "high, medium, low" as >>>>> preferred for broad interoperability. >>>>> >>>>> -John >>>>> >>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" wrote: >>>>> >>>>> I may have been too succinct in my response ;-) >>>>> >>>>> Confidence is a subjective thing, so I think we should use subjective >>>>> terms:=C2=A0 Low, Medium, High.=C2=A0 Having a numeric scale with a m= ap that >>>>> essentially would say something like: >>>>> >>>>> 1-33 =3D Low >>>>> 34-67=3D Medium >>>>> 68-100=3DHigh >>>>> >>>>> Is just a more complicated way of saying that something is Low, >>>>> Medium,=C2=A0 High...do we really thing that how High something is ma= kes >>>>> that much of a=C2=A0 difference? >>>>> >>>>> This is like when you get your Performance review where it is Does >>>>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>>>> Meets...your bonus tells you that you got the same bonus that all the >>>>> other Meets got >>>>> ;-) >>>>> >>>>> Anyway, I digress but trying to prove a point that I would argue that >>>>> confidence in this case is going to be basically a gut feeling, so >>>>>why >>>>> use=C2=A0 numeric values when Low, Medium, High would do just fine. >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Both approaches will validate in the current schema.=C2=A0 The >>>>> representation looks a little different for each, here is an example: >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> Searching capability is a great point, agreed.=C2=A0 I'd like to hear= from >>>>> more people to make sure we don't lose a capability that others find >>>>> extremely useful (need to gauge that).=C2=A0 Other options is that th= e >>>>> guidance can also discourage the use of the numeric in addition to >>>>> specifying how to select ranges. >>>>> >>>>> Any other opinions? >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Stoecker, Paul >>>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>>> To: Brian Trammell >>>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Cant we make Confidence a List that has only 3 values:=C2=A0 High, Me= dium, >>>>> and=C2=A0 Low?=C2=A0 Any other value means that the Document will mot= validate >>>>> against=C2=A0 the schema. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>>> >>>>> wrote: >>>>> >>>>> Hi, Kathleen, all, >>>>> >>>>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>>>> interoperable numeric scales for assessment is a very hard problem. >>>>> (Were I charged with defining such a scale, the value "70" would mean >>>>> "we compared this incident report to N past similar incident reports >>>>> according to similarity algorithm S, and 70% of the past reports had >>>>> assessed impacts within E% of the actual, measured final impact -- I >>>>> think for most applications this is vastly more difficult and >>>>> rigorous than it needs to be.) >>>>> >>>>> Unless a numeric Confidence value is based on some actual, repeatably >>>>> measurable aspect of the Assessment report -- which I suspect in >>>>> many/most/all cases it's not -- then it just represents a guess, >>>>> however educated.=C2=A0 Each team will probably naturally tune its ow= n >>>>> scales such that each value generally means the same thing in each >>>>> report. Across teams, I don't know. >>>>> >>>>> On the other hand, Assessments are by their very nature educated >>>>> guesses, anyway, so I don't know that I'd find much use in automating >>>>> a response based on the assessment confidence. Chris has a good >>>>> point, though -- it makes searching difficult and sorting kind of >>> pointless. >>>>> >>>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>>>> agree, we should put that in the guidance document (along with a note >>>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>>> of the users of this field use a 100-point scale with 100 meaning >>>>> "yes" and 0 meaning "any resemblance these values may have to actual >>>>> fact is purely coincidental", then let's consider renaming it >>>>>"percent" >>> in 5070-bis. >>>>> >>>>> Best regards, >>>>> >>>>> Brian (as contributor) >>>>> >>>>> >>>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>>> wrote: >>>>> >>>>> Please see section 3.10.4 of RFC5070 as a starting point.=C2=A0 We ca= n >>>>> change it if it needs to be changed.=C2=A0 The value is for a confide= nce >>>>> rating on the indicators shared.=C2=A0 The definitions may be helpful= for >>>>> anyone who wants to work on this discussion.=C2=A0 IODEF has various >>>>> markers that can be used in a complimentary way without conflating >>>>> the markers meaning. >>>>> >>>>> I think some people using IODEF find the numerical values more >>>>> helpful, and it would be good to understand what people have learned >>>>> from using the current structure (what works/does not work).=C2=A0 Th= e >>>>> scales I have seen are 0-100.=C2=A0 There is of course a subjective >>>>> element to assigning a numerical value to the confidence and it may >>>>> vary from entity to entity.=C2=A0 With this type of rating you may ne= ed to >>>>> consider who it came from and how they scored the confidence rating >>>>> to map to your own rating.=C2=A0 It would be good to hear more though= ts on >>> this. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>>> To: MILE IETF >>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> >>>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>>> point.=C2=A0 Different Confidence levels will cause confusion.=C2=A0 = It appears >>>>> that there maybe a need for some type of simplified standardization >>>>> to be established between all Sharing Groups in this regard. >>>>> >>>>> Perhaps numerical scoring set at lower values should express levels >>>>> of urgency. >>>>> ( i.e.=C2=A0 1 =3D Less Likely,=C2=A0=C2=A0=C2=A02 =3D Probable,=C2= =A0 3 =3D A Concern,=C2=A0 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> >>>>> I see some confusion coming down the pike if we start using >>>>> Confidence the way it is supported. If I am using low/med/high and >>>>> someone sends me an IoC with a score of 70, what does that mean to >>>>> me? What if I am using a scale of >>>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>>>> to describe something with a consistent language. It really gets ugly >>>>> when we store IoC from multiple sources. I have confidence values >>>>> that are numeric as well as text.=C2=A0 Makes searching / sorting ver= y >>>>> problematic. >>>>> >>>>> At this point we have to roll with what we have. I would strongly >>>>> recommend that we revisit this at some point. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Chris & Take, >>>>> >>>>> I'll just focus on the confidence scoring.=C2=A0 Right now, the schem= a >>>>> allows for you to either use a numerical score OR the ratings of low, >>>>> medium, and high. >>>>> Different sharing groups can decide how they want to share the data. >>>>> If >>>>> people were to use the numerical values, I agree it would be helpful >>>>> to have guidance.=C2=A0 This could go in the IODE guidance document. >>>>> >>>>> I have seen examples of current users that use each of the >>>>> approaches, so we'll need to keep the option for backwards >>>>> compatibility and it is nice to keep in flexible options where we >>>>> can. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher >>>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> The number of indicators wouldn't necessarily drive the use of >>>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>>>> addresses that were used as C2 for 3 different campaigns I would have >>>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>> >>>>> My suggestion would be a simple low, medium, high. I think if we >>>>> break it down to more levels than that we would need to provide >>>>> guidance on scoring, rating, etc. I think most people should be able >>>>> to understand low/med/high without having to have a mathematical >>>>> method for arriving at the level. >>>>> >>>>> Low - I am not sure >>>>> Medium - I am reasonably sure >>>>> High - I am very sure >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>>> deal with large sets of indicators. >>>>> Since indicator_set_id attribute is optional (right?), it could be >>>>> omitted if we need to deal with only small number of indicators. >>>>> >>>>> Regarding the use case, I like the idea of using the confidence >>>>> attribute for the reason Chris kindly described. >>>>> I would like to hear a bit more on this: is it going to be numerical? >>>>> For >>>>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>>> etc? >>>>> >>>>> Thank you. >>>>> Take >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> With respect to tying things back to threat actors, from what I have >>>>> seen and use this is a generally accepted grouping: >>>>> >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>> >>>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Take & others, >>>>> >>>>> Thanks for chiming in, I've been talking about this with Chris and a >>>>> few others on their use cases and would like more opinions.=C2=A0 I'l= l >>>>> provide an option below from what we have discussed from a CIRC view >>>>> point.=C2=A0 We are also wondering how to also provide logic in IODEF= that >>>>> could cross over into SCI attached schemas or IODEF extensions (the >>>>> solutions may all tie together with this discussion - or there may be >>>>> better/more elegant solutions others would like to propose). >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I like this discussion. >>>>> I agree, it would be good idea to have indicator identifiers inside >>>>> the IOC-related classes. >>>>> >>>>> KMM: At the class level, we may have several indicators listed that >>>>> should be viewed as a set and may have another instance of that same >>>>> class that is a related issue, but a separate set.=C2=A0 We could as = you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we get >>>>> into logic and relationships between sets or indicators.=C2=A0 This c= ould >>>>> also be a way to connect indicators or sets across XML documents that >>>>> could have been shared previously.=C2=A0 If there are a large number = of >>>>> indicators in the set, then this becomes useful, for smaller sets, I >>>>> agree it doesn't make as much sense. >>>>> >>>>> What do others think? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? >>>>> (more details >>>>> on >>>>> this in my first message). >>>>> >>>>> If we could see any indicator of compromise as computer event record, >>>>> we could use SCI:EventReport class as the place for the XML-based >>>>> IOCs that couldn't fit anywhere else. >>>>> >>>>> KMM: That sounds like a good idea to me.=C2=A0 This should go into >>>>> guidance in the SCI draft.=C2=A0 Does anyone else want to weigh in? >>>>> >>>>> >>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>>> KMM: Sounds good, thanks! >>>>> >>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>> the indicator_set_id. >>>>> I understand we could do some grouping of individual indicator_uids >>>>> and its usability, but I am not sure whether we do not have any other >>>>> way to express these groupings. >>>>> For instance,=C2=A0 a Reference class refers to several indicadtor_ui= ds. >>>>> In >>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>> >>>>> KMM: It may be, what do you think about large sets of indicators or >>>>> subsequent messages that add indicators to existing sets?=C2=A0 Would= this >>>>> happen?=C2=A0 Would it be easier to express relationships with sets o= f >>>>> indicators in addition to individual indicators?=C2=A0 By using this,= it >>>>> could give us a unique way to also provide the logic and >>>>> relationships in a new class of IODEF so we don't have to worry about >>>>> adding it into the current structure. >>>>> If there are better ways to handle that, and others can provide some >>>>> options, that would be appreciated! >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> I would appreciate if anybody could share expertise on this. Though I >>>>> think I have read all the emails in the list, I might have >>>>> mis-understood some points. >>>>> >>>>> By the way, I think the indicator_uids should be added to the SCI >>>>> classes' >>>>> attributes so that they can be correlated with another information as >>>>> well. >>>>> >>>>> Thanks >>>>> Take >>>>> >>>>> >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between indicators. >>>>> If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>> >>>>> Thanks, >>>>> --Chris >>>>> >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>> >>>>> It is either that or going back to adding a Detection (or Indicators) >>>>> class that will should be used to take all of the indicators put them >>>>> into one place and have the ability to group the ones that go >>>>> together.=C2=A0 I don't mean a place to put indicators that are missi= ng >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the shared >>>>> Incident.=C2=A0 I don't know the answer here, but there has got to be= a >>>>> good way for indicators to be identified and being able to group them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> From: , Kathleen >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" , MILE >>>>> IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>> >>>>> The list has already said they would like to see indicators added to >>>>> the definitions in RFC5070-bis, to be more explicit about including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes.=C2=A0 It was written before we used terms like >>>>> indicators.=C2=A0 With that in mind, Rosella proposed a number of cha= nges >>>>> back in July, both for guidance and for format updates.=C2=A0 It may = help >>>>> to have the first draft try to address at least some of these issues >>>>> so people can understand the problems and at least a proposed >>>>> solution. >>>>> >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators that >>>>> could have a relationship to each other within a document.=C2=A0 In t= he >>>>> July presentation, one of the questions was to see if we should add >>>>> new category attribute values for the System class that would connect >>>>> the list of included indicators.=C2=A0 I think we should still keep t= he >>>>> concept of a Node to a single node, but perhaps within System, list >>>>> multiple sets of Nodes that may be one type of attack.=C2=A0 Rosella = had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an >>>>> AttackType (FraudType values could be included in AttackType or some >>>>> broader term).=C2=A0 It may be better to have the FraudTypes, plus >>>>> attribute values like "C2-server", "sinkhole",=C2=A0 "MalwareDistribu= tion" >>>>> for added context so you know what to do with the received set of >>>>> indicators. >>>>> >>>>> I am proposing that we change IODEF to include multiple sets of >>>>> indicators, add an AttackType attribute (or some other name), a >>>>> method to connect indicators and indicator sets within an IODEF using >>>>> an attribute of indicator_uid (or some other name) with a string >>>>> value to make the connection points, and add a few indicators that >>>>> are commonly shared into the base IODEF. >>>>> >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below).=C2=A0 What if we added the Registry Key/Value pairs as = a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, we >>>>> could connect a set within that structure and repeat the structure >>>>> for other sets in the same way we would do with Node inside of the >>>>> System class, using the indicator_uid to tie the set together.=C2=A0 = Then >>>>> at the more specific level for the hash, registry Key/value, IP, etc. >>>>> use an indicator_uid if we needed them marked at this level as well? >>>>> Maybe we want indicator_set at the higher level?=C2=A0 I'd like some >>>>> opinions on this approach.=C2=A0 +1 if you agree, suggestions if you = have >>>>> other ideas that may work better. >>>>> >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted.=C2=A0 We may want to use these va= lues >>>>> or something else. >>>>> >>>>> Thank you! >>>>> Kathleen >>>>> >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I think we have a bigger relationship issue to address. Let use the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>> >>>>> Two or more indicators of different type that relate to the same >>>>> threat: >>>>>=C2=A0 =C2=A0 =C2=A0 The file hash of a malicious file and the URL of = the C2 that >>>>> the file uses. Either or both may be present to indicate a >>>>> compromise. >>>>> >>>>> Two or more indicators of the same type that relate to the same >>>>> threat: >>>>>=C2=A0 =C2=A0 =C2=A0 2 different registry values for the same registry= key. If >>>>> either value is present it is a compromise indicator but both will >>>>> not be present. >>>>> >>>>> The problem compounds itself very quickly. Consider the scenario >>>>> where both groupings above are part of the same threat. I need to >>>>> show that logical groupings of Indicators are related as well. We >>>>> can't send multiple IODEF messages for this from what I remember >>>>> reading. >>>>> >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>>> IOCs are the 2 hash values. How do we show they are related? If we >>>>> use a unique Inidcator ID for each hash value there needs to be a >>>>> higher level grouping. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> All - >>>>> >>>>> I'd like your input and will refocus the thread to get opinions from >>>>> the list on options to help solve the problems raised in my message >>>>> and additionally in Paul's message. >>>>> >>>>> Interesting point, C. Henry.=C2=A0 Our objective here is to have mach= ine >>>>> automated exchanges, so we rely on encryption rather than obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>> >>>>> Paul mentioned the need to distinguish indicators of compromise from >>>>> context information that may also include IP address or other data >>>>> that could be indicators.=C2=A0 The question I raised was on how to >>>>> connect sets of indicators in the same IODEF document, assuming the >>>>> ability to have watchlists that could have several sets of indicators >>>>> included, as well as to connect indicators that may be included in >>>>> embedded schemas. >>>>> >>>>> If we add an attribute on all of the relevant indicators, let's say >>>>> 'indicator-uid' how do we mark the indicators?=C2=A0 Do we use this t= o >>>>> mark who sent the indicator as well so that we can prevent forward >>>>> sharing when it is not permitted or handle that separately? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? (more details on >>>>> this in my first message). >>>>> >>>>> Comments and questions encouraged to figure out the right technical >>>>> solution to have this machine automatable. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Temporal Dependency sounds interesting.=C2=A0 I remember when I first= ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question.=C2=A0 He said, " How do you stop someone from trac= king >>>>> the IP Address to your computer?" >>>>> >>>>> I replied, "I don't know, how?" >>>>> >>>>> Then he said, "Cut the dog-gone thing off=C2=A0 and the modem that it= is >>>>> connected- which is constantly on!"=C2=A0=C2=A0=C2=A0LOL >>>>> >>>>> Here's my point (Hypothetical Situation) :=C2=A0 There is a 1st Respo= nder >>>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>>> or let's just say "Live" Terrorist Situation.=C2=A0 He /or She needs = to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger.=C2=A0 The device used to communicate has been captured by the >>>>> great minds of the enemy.=C2=A0 It's only a matter of time before the= y >>>>> utilize reverse engineering to figure out how it functions.=C2=A0 How= ever, >>>>> their pride comes before a fall when seeking the location of other >>>>> similar devices to attack.=C2=A0 Why? Perhaps the less thought of con= cepts >>>>> that makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>> >>>>> Just a visionary thought. >>>>> >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Mon, 1/28/13, Dave Misell wrote: >>>>> >>>>> From: Dave Misell >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>> >>>>> Yours Faithfully, >>>>> >>>>> Dave Misell MSc CISSP >>>>> SilentCircle=C2=A0 dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>> >>>>> >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>>> >>>>> wrote: >>>>> >>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>> was closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant minds >>>>> in some instances." >>>>> >>>>> However, I see Dr. Stoecker's point a little clearer.=C2=A0 However, = it >>>>> would be nice if the UID was in some way disguised from those who >>>>> study this Security Art Form in a negative way. >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> Re: [mile] IOCs >>>>> >>>>> Sunday, January 27, 2013 8:52 PM >>>>> From: >>>>> "Stoecker, Paul" >>>>> To: >>>>> "mile@ietf.org" >>>>> I would like to look at this from a slightly different >>>>> perspectiveSlet's say I get an XML document that tells me about an >>>>> incident.=C2=A0 This document has source IP and destination IP that i= s >>>>> being shared.=C2=A0 However, what I don't know is which IP address is= my >>>>> indicator and which is just a contextual piece of information.=C2=A0 = This >>>>> means that my detection product isn't going to know which one to use >>>>> either, because there is nothing to tell me which IP is the one, even >>>>> if the roles are set it still might not be enough to tell my system >>>>> which one I should use as the indicator. >>>>> >>>>> If we had something like indicator_id as an attribute, it would allow >>>>> us to easily identify indicators from contextual data.=C2=A0 I do adm= it to >>>>> being biased as I have spent much of my career working on the >>>>> monitoring and detection side of these things, so I am just thinking >>>>> of ways to make it very clear what the indicators are in the XML >>>>> document and the other data that may be important as I investigate >>>>> activity that I have detected off of those indicators. >>>>> >>>>> >>>>> I did suggest the detection class, but I think we may get more >>>>> flexibility with the indicator_uid.=C2=A0 One thing that I haven't >>>>> considered is the UID portion of thisShow do we use that UID?=C2=A0 H= ow is >>>>> the UID created?=C2=A0 Are there standards for UIDs? >>>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE >>>>> wrote: >>>>> >>>>> From: C. Henry Adams & BIE >>>>> Subject: RE: [mile] IOCs >>>>> To: "KathleenMoriarty" >>>>> Cc: mile@ietf.org >>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>> >>>>> Greetings Kathleen, >>>>> >>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>> many avenues you review with this approach at once.=C2=A0 However,=C2= =A0 could >>>>> you share a few advantages and disadvantages to the latter? >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>> "we could continue to group items in logical places as is done now in >>>>> IODEF and then have the extension point for combined indicators via >>>>> SCI." >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>> >>>>> You pointed out what you consider to be logical places, but if I >>>>> wanted to protect information from parties capable of ascertaining it >>>>> from your logical places, perhaps we should also consider to a degree >>>>> what appears to be illogical in brilliant minds in some instances. >>>>> >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Sat, 1/26/13, Moriarty, Kathleen >>>>> wrote: >>>>> >>>>> From: Moriarty, Kathleen >>>>> Subject: RE: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" , "mile@ietf.org" >>>>> >>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>> >>>>> Hello C. Henry & others, >>>>> >>>>> Thanks for taking a look at this.=C2=A0 We have a few considerations = in >>>>> this email thread I would like to hear thoughts on (and there may be >>>>> more once RFC5070-bis is actively edited). >>>>> >>>>> The AdditionalData class and the RecordItem class both allow for >>>>> non-XML extensions.=C2=A0 Where you place the extensions should be >>>>> specific to the logical grouping of the parent elements so you can >>>>> understand more about the included data in most cases. >>>>> >>>>> The Impact class can be used to provide context information on the >>>>> included data of the report and also can include a confidence rating >>>>> on the report as a whole.=C2=A0 Extensions related to impact would be= one >>>>> level higher (at the moment) in the Assessment class using the >>>>> AdditionalData extension point. >>>>> >>>>> Take asked about including vulnerability information, I would think >>>>> that would fit under the Vulnerability extension point of the SCI >>>>> draft in the Method class.=C2=A0 He did ask about non-XML.=C2=A0 Reco= rdItem or >>>>> AdditionalData do allow for non-XML extension points, we could either >>>>> have the SCI draft handle these as well or have the extensions that >>>>> are non-XML come directly off the AdditionalData or RecordItem >>>>> classes according to what makes sense from a logical standpoint. >>>>> >>>>> As for my question, it was two-fold. >>>>> >>>>> Indicator based schemas have a reference number or a GUID for the >>>>> various indicators they share.=C2=A0 If we are extending to embed oth= er >>>>> schemas that include such reference or GUID identifiers, do we want >>>>> to add an attribute to the various elements in IODEF that could be >>>>> indicators?=C2=A0 Is this enough to make the connections or is someth= ing >>>>> else else needed?=C2=A0 We could add something like an Indicator_ID i= n >>>>> RFC5070-bis which would then correlate to the reference or GUID >>>>> identifiers. >>>>> >>>>> Then the other question was on how to include indicators that are not >>>>> in the base schema that may be related or have language with "and" >>>>> "or" >>>>> to >>>>> specify the relationships.=C2=A0 In some cases, you will want to grou= p >>>>> these indictors in one extension point, where they may fit logically >>>>> in multiple places if the relationships did not need to be shown in >>>>> the data format.=C2=A0 If we have cases like this where you need more >>>>> complex representations, should we use one extension point via the >>>>> SCI draft off of the EventData class AdditionalData extension point? >>>>> Opinions are needed here.... >>>>> >>>>> A few people have mentioned wanting to include some commonly shared >>>>> indictors into the base IODEF document.=C2=A0 We could have a catch-a= ll >>>>> class that does this and has an extension point off of it in >>>>> EventData or we could continue to group items in logical places as is >>>>> done now in IODEF and then have the extension point for combined >>>>> indicators via SCI.=C2=A0 I think I like the latter approach. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>> To: mile@ietf.org >>>>> Cc: C. Henry Adams >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Greetings Everyone, >>>>> >>>>> Take mentioned two types of indicators based on the : >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> 1) If the indicators are something like an XML-based alert/warning of >>>>> information leakage, it could be an event that are conveyed in the >>>>> SCI's EventReport class, IMHO. >>>>> >>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>> could be conveyed without using SCI draft. >>>>> For instance, we could use Impact class of the base IODEF to convey >>>>> the indicators. >>>>> We could for instance extend the list of indicators of the Impact >>>>> class, if needed. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> >>>>> In doing so he pointed out the "Impact Class" >>>>> >>>>> Whereas, Kathleen stated, >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>> For the discussion below, I was thinking more of combined set with >>>>> relationships that may be included in a single extension point, so >>>>> that's why I was thinking about the EventData class, but there may be >>>>> better locations or a specific area within the EventData. >>>>> >>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>> >>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>> >>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to simplify >>>>> this issue? >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > ---36511695-1834828720-1361338150=:43634 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Greetings Everyone,

After further cons= ideration,  I still tend to lean toward a simplified version of the co= nfidence rating.  Which in my opinion, has now changed to ENUM or enum= erated type ONLY.

Furthermore,  perhaps { low, medium, high},&n= bsp; should be altered to be {low, minor, medium, high, major}

<c= onfidence rating=3D"low">This has a low confidence rating of compromise&= lt;/confidence>

<confidence rating=3D"minor">This has a min= or confidence rating of compromise</confidence>

<confidence= rating=3D"medium">This has a medium confidence rating of compromise<= /confidence>

<confidence rating=3D"high">This has a high co= nfidence rating of compromise</confidence>

<confidence rati= ng=3D"major">This has a major confidence rating of compromise</confidence>

<< Not sure if the statement be= low is logical, just Brainstorming>>

Furthermore, let's say Lo= w was map to 1.0.   Minor map to 2.0. Medium map to 3.0  Hig= h map to 4.0.  Major map to 5.0

The mapping procedure is the va= lue built-in the ENUM.  (Please feel free to correct me if I'm wrong.)=

Then, simple statistical math is apply in some form to equate an ov= erall value of analysis.

C. Henry Adams



=0A
This i= s exactly my point.  I would leave out the numeric ratings.  Iconsume the data and at least with the enumerated type I don't have to
= also create a map if I want to get back to low, medium and high.  I wi= ll
have to make that transform anyway, so that my SOC knows the confiden= ce
without having to keep looking it up ;-)  I like the simplicity = of the
enumerated type=C5=A0people can take that and make it into whatev= er they want
as far as numerics are concerned.



Paul W. St= oecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division o= f EMC
cell: 302.379.3375 | e: paul.stoecker@rsa.com





On 2/19/13 9:43 AM, "Eric Burger" <eburg= er-l@standardstrack.com> wrote:

>If the proposal is 0-19 =3D low, 20-39 =3D =C5=A0, 80-99 =3D high, then why do we
>have= the numbers, or why do we have the enumerated type? Either it is a
>= number or it is an enumerative value. Having both is asking for trouble.>
>On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen"
><<= a href=3D"http://us.mc1216.mail.yahoo.com/mc/compose?to=3Dkathleen.moriarty= @emc.com">kathleen.moriarty@emc.com> wrote:
>
>> Shou= ld we provide guidance similar or the same as what CIF uses (was
>>= ;posted to the list previously)?  They use direct mapping to 5 levels = so
>>that you can have ranges of numeric values used from 0-100, l= ow to high.
>> This would be the easiest solution...
>>>> Thanks,
>> Kathleen
>> _______________________= _________________
>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric
>>Burger [eburger-l@standardstrack.com]
>> Sent: Tuesday, Februa= ry 19, 2013 7:38 AM
>> To: MILE IETF
>> Subject: Re: [mil= e] IOCs
>>
>> If there really is no value to a value, do = not let people hurt
>>themselves.
>>
>> If there= is a proprietary reason for a value, we should say what we
>>mean= and call it such. For example:
>>
>>     =   <confidence rating=3D"low">This is XML so put your
>>= ;NON-INTEROPERABLE mumble you want here</confidence>
>> or>>        <confidence rating=3D"high">42&= lt;/confidence>
>> or
>>        <confidence
>>rating=3D"medium"><mydom:meansSomethingToM= e>balderdash</mydom:meansSomethin
>>gToMe></confidence= >
>>
>> On Feb 19, 2013, at 7:24 AM, "Harrington, Chri= stopher"
>><Christopher.Harrington@emc.com&= gt; wrote:
>>
>>> I would agree that flexibility is so= mething to strive for. However
>>>there
>>> isn't e= nough in the RFC to make the numeric confidence value
>>>unders= tood by
>>> the recipient and therefore actionable. From the sp= ec:
>>>
>>> "numeric.  The element content con= tains a number that conveys the
>>>confidence
>>> o= f the data.  The semantics of this number outside the scope of this>>> specification"
>>>
>>> Based on that I can score my confidence with 1 being most confident
>>>and 1= 00
>>> being least. Perfectly legitimate but would probably mes= s everybody
>>>up. What
>>> if my scale is 1000 and= yours is 100. I send you something with a
>>>score of
>&= gt;> 100 you will think I am absolutely certain when I am only 10% so.>>>Knowing
>>> how sure the sender is about a piece = of data shared is critical. If the
>>> sender puts an arbitrary= number in the field I have no point of
>>>reference.
>&g= t;> It's meaningless to me.
>>>
>>> We spell out= what the relative value is for low/med/high. I know those
>>>a= re
>>> self-explanatory but they are still spelled out. I would= urge that we
>>>do the
>>> same for a numeric valu= e. If not there needs to be something added so
>>>that
>>> in addition to the numeric value I = have a point of reference for how
>>>certain
>>> yo= u are based on the number you put there.
>>>
>>> Th= anks,
>>>
>>> --Chris
>>>
>>&g= t;
>>> -----Original Message-----
>>> From: = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beha= lf Of
>>> Banghart, John
>>> Sent: Monday, February= 18, 2013 7:42 AM
>>> To: Eric Burger; MILE IETF
>>>= ; Subject: Re: [mile] IOCs
>>>
>>> Eric,
>>= ;>
>>> Well, I think you answered your own initial question,= but I'm going to
>>>jump
>>> in anyway.  :)
>>>
>>> Generally speaking, I think we want to = strike a balance between
>>> standardization and flexibility.&n= bsp; We are unlikely to arrive at any
>>>sort of
>>>= ; one-size-fits-all scheme, no matter how long we talk about it.
>>= ;>Instead, we
>>> should be focusing on solidifying the area= s we can all agree on, and
>>>allow
>>> flexibility= for those that we don't.  It's an age old clich=C3=A9, but
>>= ;>let's not
>>> let perfect be the enemy of the good.
>= ;>>
>>> -John
>>>
>>> On 2/16/13 = 12:42 PM, "Eric Burger" <eburger-l@standardstrack.com&= gt;
>>>wrote:
>>>
>>>> What is the j= ustification for both numeric and enumerated values
>>>> (low/medium/high)?  In general such a schema is begging for
>&g= t;>> interoperability problems.
>>>>
>>>&g= t; I suppose I can understand both sides of the argument.  On the We N= eed
>>>> Numbers side is those that actually calculate a per= centage or other
>>>> objective measure in the confidence ma= y want to use those real
>>>>numbers.
>>>> As= well, on the We Need Numbers side is the argument that three
>>&g= t;> enumerated values may not prove sufficient in the future. On the We<= br>>>>> Need Enumerated Values side is confidence, other than 0= % and 100%,
>>>>tend
>>>> to be arbitrary gue= sses. Putting a number on this value imparts a
>>>>level
= >>>> of specificity that does not exist. Also, it is a lot easi= er to map
>>>> 'low' to 'low' than it is to map 0-33 to 'low'.
>>>>
>>>> On Feb 13, 2013, at 2:08= PM, "Harrington, Christopher"
>>>> <Chri= stopher.Harrington@emc.com> wrote:
>>>>
>>&g= t;>> That will work provided I (and everyone else) has a mapping for = the
>>>>> numbers.  I would prefer a simple low/med/= high scheme. The more we
>>>>>add
>>>>>= the more you have to be able to differentiate between them. However
>= ;>>>> for potential interoperability I do see the benefit of th= e 5.
>>>>>
>>>>> Thanks,
>>>= ;>>
>>>>> --Chris
>>>>>
>&g= t;>>> From: Moriarty, Kathleen
>>>>> Sent: Wedne= sday, February 13, 2013 2:05 PM
>>>>> To: Harrington, Christopher; MILE IETF
>>>>> Subject: RE: [mile] IOCs>>>>>
>>>>>
>>>>> If yo= u think of IODEF just for transport, could you meet your needs
>>&= gt;>> with storing the values differently in a database (IODEF is jus= t
>>>>>meant
>>>>> for the exchange)?&n= bsp; The numbers map to low/med/high - for db storage
>>>>&g= t;-
>>>>> if numbers are used, you could store the equiva= lent value, adding the
>>>>> 2 additional ones provided.<= br>>>>>>
>>>>> Does it make sense to expan= d the set of values to match what CIF is
>>>>> doing if w= e went forward with the approach of supporting both
>>>>>= options?
>>>>>
>>>>> Thank you,
>= >>>> Kathleen
>>>>>
>>>>> From: mile= -bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf>>>>> Of Harrington, Christopher
>>>>> S= ent: Wednesday, February 13, 2013 11:49 AM
>>>>> To: 'C. = Henry Adams & BIE'; MILE IETF
>>>>> Subject: Re: [mil= e] IOCs
>>>>>
>>>>> From a data process= ing standpoint it is going to create extra work
>>>>> for= the people who are going to receive this data if we support both
>&g= t;>>> numeric and alpha characters in the same field. I can envisi= on people
>>>>> wanting to search, sort, store, etc the d= ata in this field. If we
>>>>> allow both data types then everyone will need to have a mapping of
>>>>> some sort.= I have a field for confidence in my threat tracking
>>>>>= ; database. Having both a numeric score and alpha characters / words
>= ;>>>> creates issues when trying to interact with the data. I a= gree that we
>>>>> need to support both however I don't t= hink both should be in the same
>>>>> field. I would much= rather see 2 different fields for Confidence if
>>>>>we<= br>>>>>> are going to support 2 different data types.
>= ;>>>>
>>>>> This will be a larger issue shoul= d Confidence be used elsewhere.
>>>>> Ideally in future r= evisions I would like to see attribution expressed
>>>>> = as  some form of attribution is almost always shared with an IoC.
&= gt;>>>> Currently there are 5 areas where we  (EMC) uses confidence.
>>>>>
>>>>> Indicator= (how confident are you that this is a valid IoC)
>>>>> I= ndicator_Set (how confident are you that all of the indcators in the
>= ;>>>> set should be in the set)  Campaign (how confident a= re you that all
>>>>> Indicator_Sets are part of this cam= paign)  Threat Actor (how
>>>>>confident
>>= >>> are you that the Campaign is attributed to this Threat Actor)&= nbsp; Threat
>>>>> Actor type (how confident are you that= this Theat Actor is APT,
>>>>> Crimeware, other)
>= >>>>
>>>>> The threat actor name and the thre= at actor type are usually the first
>>>>> 2 things that a= nyone processing IoCs wants to know as they drive
>>>>>pr= iority.
>>>>> Knowing how sure the sender is that this IoC is APTis a vital piece
>>>>> of information for= us.  Sorry to take us a little off the path but I
>>>>= > wanted to show where Confidence could be used.
>>>>>=
>>>>> Thanks,
>>>>>
>>>>= ;> --Chris
>>>>>
>>>>> From: = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beha= lf
>>>>> Of C. Henry Adams & BIE
>>>>&= gt; Sent: Wednesday, February 13, 2013 10:24 AM
>>>>> To:= MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>= >>
>>>>> Again, I would concur that both a numeric = and subjective analysis of
>>>>> the Confidence Rating needs to be express, but combined in a
>>>>> simplified = schema as such below:
>>>>>
>>>>> <C= onfidence rating=3D" Alphanumeric">1LL</> .... etc.
>>>= ;>>
>>>>> <Confidence rating=3D" Alphanumeric"&g= t;2P</>
>>>>>
>>>>> <Confidenc= e rating=3D" Alphanumeric">3AC</>
>>>>>
>&= gt;>>> <Confidence rating=3D" Alphanumeric">4U</>
&= gt;>>>>
>>>>> <Confidence rating=3D" Alpha= numeric">5I</>
>>>>>
>>>>> ( i= .e.  1 =3D Less Likely,   2 =3D Probable,  3 =3D A= Concern,  4 =3D
>>>>>Urgent,
>>>>>= ; 5 =3D Imminent )
>>>>>
>>>>> Here's m= y point, perhaps a set of numeric related or associated
>>>>= > definitions can lower the propagation of error regarding the
>>&g= t;>>analysis.
>>>>>
>>>>> Thanks,=
>>>>> C. Henry Adams
>>>>>
>>= >>>
>>>>> I agree that what we really need is bo= th.  In most situations a low,
>>>>> medium and high= may be acceptable but there are times when we will
>>>>>= want to show that confidence in a situation is increasing or
>>&g= t;>> decreasing.  If we are only looking at a three levels, we c= annot
>>>>> express what is needed to show confidence is = trending up on the data
>>>>> being exchanged about the e= vent.
>>>>>
>>>>> Kathleen included the= following in a previous message.
>>>>>
>>>&g= t;> <Confidence rating=3D"low"/>
>>>>>
>>>>> Vs:>>>>>
>>>>> <Confidence rating=3D"nume= ric">85</>
>>>>>
>>>>> I reall= y think we need to include both capabilities as John alluded
>>>= ;>> to since confidence is not a three tiered item but something that= is
>>>>> indeed subjective and we need a means to show a= reasonably accurate
>>>>> confidence index that the send= er is trying to convey.
>>>>>
>>>>> Ken= t Landfield
>>>>>
>>>>> McAfee | An Int= el Company
>>>>> Direct: +1.972.963.7096
>>>&= gt;> Mobile: +1.817.637.8026
>>>>> Web: www.mcafee.com=
>>>>>
>>>>> From: <Banghart>, Jo= hn Banghart <john.banghart@nist.gov>
>>>>> Date: Wednesda= y, February 13, 2013 7:16 AM
>>>>> To: "Stoecker, Paul" &= lt;Paul.Stoecker@rsa.com>, Kathleen Moriarty
>>>&= gt;> <kathleen.moriarty@emc.com>, Brian Trammell &l= t;trammell@tik.ee.ethz.ch>
>>>>> Cc: "C. = Henry Adams & BIE" <chatlga2000@yahoo.com>, MILE IETF<= br>>>>>> <mile@ietf.org>
>>>>> Su= bject: Re: [mile] IOCs
>>>>>
>>>>> Paul,
>>>= >>
>>>>> I agree that confidence is subjective, but= subjectivity can be
>>>>> reduced  within communiti= es that interact frequently.  Prioritization
>>>>> o= f indicators  and response between tightly connected sharing
>&g= t;>>>partners
>>>>> might require a  more s= pecific level of detail, particularly during a
>>>>> cris= is situation.
>>>>>
>>>>> From that per= spective, I think the guidance should allow for
>>>>> add= itional granularity, while stressing the "high, medium, low" as
>>= >>> preferred for broad interoperability.
>>>>><= br>>>>>> -John
>>>>>
>>>>&g= t; On 2/13/13 8:04 AM, "Stoecker, Paul" <Paul.Stoecker@rsa.com> wrote:
>>>>>
>&g= t;>>> I may have been too succinct in my response ;-)
>>&= gt;>>
>>>>> Confidence is a subjective thing, so I = think we should use subjective
>>>>> terms:  Low, Me= dium, High.  Having a numeric scale with a map that
>>>>= ;> essentially would say something like:
>>>>>
>= >>>> 1-33 =3D Low
>>>>> 34-67=3D Medium
&g= t;>>>> 68-100=3DHigh
>>>>>
>>>>= ;> Is just a more complicated way of saying that something is Low,
&g= t;>>>> Medium,  High...do we really thing that how High so= mething is makes
>>>>> that much of a  difference?>>>>>
>>>>> This is like when you get yo= ur Performance review where it is Does
>>>>> Not Meet, Meet= s and Exceeds...your boss tells you that you are a High
>>>>= > Meets...your bonus tells you that you got the same bonus that all the<= br>>>>>> other Meets got
>>>>> ;-)
>= >>>>
>>>>> Anyway, I digress but trying to pr= ove a point that I would argue that
>>>>> confidence in t= his case is going to be basically a gut feeling, so
>>>>>= why
>>>>> use  numeric values when Low, Medium, High= would do just fine.
>>>>>
>>>>>
>= ;>>>> Paul W. Stoecker, Ph.D.
>>>>> SMC Lead = Content Architect
>>>>> RSA, The Security Division of EMC=
>>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com
>>>>>
>>>>&= gt;
>>>>>
>>>>>
>>>>>=
>>>>>
>>>>> On 2/13/13 7:48 AM, "Moria= rty, Kathleen" <kathleen.moriarty@emc.com>
>>= >>> wrote:
>>>>>
>>>>> Hello,<= br>>>>>>
>>>>> Both approaches will valida= te in the current schema.  The
>>>>> representation = looks a little different for each, here is an example:
>>>>&= gt;
>>>>> <Confidence rating=3D"low"/>
>>&= gt;>>
>>>>> Vs:
>>>>>
>>= >>> <Confidence rating=3D"numeric">85</>
>>>>>
>>>&= gt;> Searching capability is a great point, agreed.  I'd like to he= ar from
>>>>> more people to make sure we don't lose a ca= pability that others find
>>>>> extremely useful (need to= gauge that).  Other options is that the
>>>>> guida= nce can also discourage the use of the numeric in addition to
>>&g= t;>> specifying how to select ranges.
>>>>>
>= >>>> Any other opinions?
>>>>>
>>>= ;>> Thanks,
>>>>> Kathleen
>>>>><= br>>>>>> -----Original Message-----
>>>>> = From: Stoecker, Paul
>>>>> Sent: Wednesday, February 13, = 2013 7:14 AM
>>>>> To: Brian Trammell
>>>>= > Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>&= gt;
>>>>> Cant we make Confidence a List that has only 3 = values:  High, Medium,
>>>>> and  Low?  An= y other value means that the Document will mot validate
>>>>= > against  the schema.
>>>>>
>>>>&= gt; Sent from my iPhone
>>>>>
>>>>> On = Feb 13, 2013, at 2:14 AM, "Brian Trammell"
>>>>> <trammell@tik.ee.ethz.ch>
>>>>> wrote:
>= >>>>
>>>>> Hi, Kathleen, all,
>>>= >>
>>>>> I think 3.10.4 in 5070 takes the right app= roach here: trying to build
>>>>> interoperable numeric s= cales for assessment is a very hard problem.
>>>>> (Were I charged with defining such a scale, the value "70" would mean
&= gt;>>>> "we compared this incident report to N past similar inc= ident reports
>>>>> according to similarity algorithm S, = and 70% of the past reports had
>>>>> assessed impacts wi= thin E% of the actual, measured final impact -- I
>>>>> t= hink for most applications this is vastly more difficult and
>>>= ;>> rigorous than it needs to be.)
>>>>>
>>= ;>>> Unless a numeric Confidence value is based on some actual, re= peatably
>>>>> measurable aspect of the Assessment report= -- which I suspect in
>>>>> many/most/all cases it's not= -- then it just represents a guess,
>>>>> however educat= ed.  Each team will probably naturally tune its own
>>>>= ;> scales such that each value generally means the same thing in each
>>>>> report. Across teams, I don't know.
>&g= t;>>>
>>>>> On the other hand, Assessments are b= y their very nature educated
>>>>> guesses, anyway, so I = don't know that I'd find much use in automating
>>>>> a r= esponse based on the assessment confidence. Chris has a good
>>>= ;>> point, though -- it makes searching difficult and sorting kind of=
>>> pointless.
>>>>>
>>>>>= If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I
&= gt;>>>> agree, we should put that in the guidance document (alo= ng with a note
>>>>> that 0-33 map to low, 34 - 66 map to= medium, and 67 - 100 map to
>>>>> high, unless we want t= o do it non-linearly). If the _vast_majority_
>>>>> of th= e users of this field use a 100-point scale with 100 meaning
>>>>> "yes" and 0 meaning "any resemblance these= values may have to actual
>>>>> fact is purely coinciden= tal", then let's consider renaming it
>>>>>"percent"
&= gt;>> in 5070-bis.
>>>>>
>>>>> Be= st regards,
>>>>>
>>>>> Brian (as contr= ibutor)
>>>>>
>>>>>
>>>>= > On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"
>>>>&= gt; <kathleen.moriarty@emc.com> wrote:
>>>= >>
>>>>> Please see section 3.10.4 of RFC5070 as a = starting point.  We can
>>>>> change it if it needs = to be changed.  The value is for a confidence
>>>>> = rating on the indicators shared.  The definitions may be helpful for
>>>>> anyone who wants to work on this discussion.&n= bsp; IODEF has various
>>>>> markers that can be used in = a complimentary way without conflating
>>>>> the markers = meaning.
>>>>>
>>>>> I think some peopl= e using IODEF find the numerical values more
>>>>> helpfu= l, and it would be good to understand what people have learned
>>&= gt;>> from using the current structure (what works/does not work).&nb= sp; The
>>>>> scales I have seen are 0-100.  There i= s of course a subjective
>>>>> element to assigning a num= erical value to the confidence and it may
>>>>> vary from= entity to entity.  With this type of rating you may need to
>&g= t;>>> consider who it came from and how they scored the confidence= rating
>>>>> to map to your own rating.  It would be good to hear more thoughts on
>>> this.
>>&g= t;>>
>>>>> Thanks,
>>>>> Kathleen=
>>>>>
>>>>> From: C. Henry Adams &= BIE [mailto:chatlga2000@yahoo.com]
>>>>> Sent= : Tuesday, February 12, 2013 2:46 PM
>>>>> To: MILE IETF<= br>>>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoeck= er, Paul
>>>>> Subject: Re: [mile] IOCs
>>>&g= t;>
>>>>>
>>>>> Regarding the IOCs o= r Indicators of Compromise, Chris made a vital
>>>>> poin= t.  Different Confidence levels will cause confusion.  It appears=
>>>>> that there maybe a need for some type of simplifie= d standardization
>>>>> to be established between all Sharing Groups in this regard.
>>>>>
>>>>= > Perhaps numerical scoring set at lower values should express levels>>>>> of urgency.
>>>>> ( i.e.  1 = =3D Less Likely,   2 =3D Probable,  3 =3D A Concern,&nb= sp; 4 =3D
>>>>>Urgent,
>>>>> 5 =3D Immi= nent )
>>>>>
>>>>> Thanks,
>>&= gt;>> C. Henry Adams
>>>>>
>>>>><= br>>>>>>
>>>>> I see some confusion coming= down the pike if we start using
>>>>> Confidence the way= it is supported. If I am using low/med/high and
>>>>> so= meone sends me an IoC with a score of 70, what does that mean to
>>= ;>>> me? What if I am using a scale of
>>>>> 1 t= o 4 and someone else is on a scale of 1 to 5? We lose the ability
>>>>> to describe something with a consistent la= nguage. It really gets ugly
>>>>> when we store IoC from = multiple sources. I have confidence values
>>>>> that are= numeric as well as text.  Makes searching / sorting very
>>&= gt;>> problematic.
>>>>>
>>>>> At= this point we have to roll with what we have. I would strongly
>>= >>> recommend that we revisit this at some point.
>>>&= gt;>
>>>>> Thanks,
>>>>>
>>= >>> --Chris
>>>>>
>>>>> -----O= riginal Message-----
>>>>> From: Moriarty, Kathleen
&g= t;>>>> Sent: Tuesday, February 12, 2013 9:59 AM
>>>= >> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;<= br>>>>>> 'MILE IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> Hi Chris &= amp; Take,
>>>>>
>>>>> I'll just focus = on the confidence scoring.  Right now, the schema
>>>>&= gt; allows for you to either use a numerical score OR the ratings of low,>>>>> medium, and high.
>>>>> Different = sharing groups can decide how they want to share the data.
>>>&= gt;> If
>>>>> people were to use the numerical values,= I agree it would be helpful
>>>>> to have guidance. = ; This could go in the IODE guidance document.
>>>>>
&= gt;>>>> I have seen examples of current users that use each of = the
>>>>> approaches, so we'll need to keep the option fo= r backwards
>>>>> compatibility and it is nice to keep in= flexible options where we
>>>>> can.
>>>>>
>>>>> Thank you,
>>= ;>>> Kathleen
>>>>>
>>>>> ----= -Original Message-----
>>>>> From: Harrington, Christophe= r
>>>>> Sent: Tuesday, February 12, 2013 9:22 AM
>&= gt;>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul= ; 'MILE
>>>>> IETF'
>>>>> Subject: RE: = [mile] IOCs
>>>>>
>>>>> The number of i= ndicators wouldn't necessarily drive the use of
>>>>> ind= icator_set_id. The purpose is to show relationship. If I sent 3 IP
>&= gt;>>> addresses that were used as C2 for 3 different campaigns I = would have
>>>>> separate indicator_set_ids, each with on= e of the 3 C2 IPs
>>>>>
>>>>> My sugges= tion would be a simple low, medium, high. I think if we
>>>>> break it down to more levels than that we would= need to provide
>>>>> guidance on scoring, rating, etc. = I think most people should be able
>>>>> to understand lo= w/med/high without having to have a mathematical
>>>>> me= thod for arriving at the level.
>>>>>
>>>>= > Low - I am not sure
>>>>> Medium - I am reasonably s= ure
>>>>> High - I am very sure
>>>>>>>>>>
>>>>> Thanks,
>>>>&= gt;
>>>>> --Chris
>>>>>
>>>= >> -----Original Message-----
>>>>> From: Takeshi T= akahashi [mailto:takeshi_takahashi@nict.go.jp]
>&= gt;>>> Sent: Tuesday, February 12, 2013 4:21 AM
>>>>> To: Harrington, Christopher; Moriarty, Kathleen= ; Stoecker, Paul;
>>>>> 'MILE IETF'
>>>>&g= t; Subject: RE: [mile] IOCs
>>>>>
>>>>>= Regarding the indicator_set_id, I agree, it is useful when we need to
&= gt;>>>> deal with large sets of indicators.
>>>>= > Since indicator_set_id attribute is optional (right?), it could be
= >>>>> omitted if we need to deal with only small number of i= ndicators.
>>>>>
>>>>> Regarding the us= e case, I like the idea of using the confidence
>>>>> att= ribute for the reason Chris kindly described.
>>>>> I wou= ld like to hear a bit more on this: is it going to be numerical?
>>= ;>>> For
>>>>> instance, 1 means "no confidence"= while 5 means "strong confidence",
>>>>> etc?
>>>>>
>>>>> Thank you.
>>= ;>>> Take
>>>>>
>>>>>
>&= gt;>>> -----Original Message-----
>>>>> From: Ha= rrington, Christopher [mailto:Christopher.Harrington@emc.co= m]
>>>>> Sent: Friday, February 08, 2013 4:11 AM
&= gt;>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Pa= ul; 'MILE
>>>>> IETF'
>>>>> Subject: RE= : [mile] IOCs
>>>>>
>>>>> With respect = to tying things back to threat actors, from what I have
>>>>= > seen and use this is a generally accepted grouping:
>>>>= ;>
>>>>> Indicator --> Indictor Set --> Campaign= --> Threat Actor
>>>>>
>>>>> Campaign and Threat Actor are where having a "Confidence" attribute
>= ;>>>> would be beneficial as making those associations is not a= perfect
>>>>> science by any means.
>>>>&= gt;
>>>>> Thanks,
>>>>>
>>>= >> --Chris
>>>>>
>>>>>
>>= ;>>> -----Original Message-----
>>>>> From: Mori= arty, Kathleen
>>>>> Sent: Thursday, February 07, 2013 2:= 00 PM
>>>>> To: Takeshi Takahashi; Harrington, Christophe= r; Stoecker, Paul; 'MILE
>>>>> IETF'
>>>>&= gt; Subject: RE: [mile] IOCs
>>>>>
>>>>>= ; Hi Take & others,
>>>>>
>>>>> Tha= nks for chiming in, I've been talking about this with Chris and a
>&g= t;>>> few others on their use cases and would like more opinions.  I'll
>>>>> provide an option below from = what we have discussed from a CIRC view
>>>>> point. = ; We are also wondering how to also provide logic in IODEF that
>>= >>> could cross over into SCI attached schemas or IODEF extensions= (the
>>>>> solutions may all tie together with this disc= ussion - or there may be
>>>>> better/more elegant soluti= ons others would like to propose).
>>>>>
>>>&= gt;> -----Original Message-----
>>>>> From: Takeshi Ta= kahashi [mailto:takeshi_takahashi@nict.go.jp]
>>= >>> Sent: Tuesday, February 05, 2013 12:04 PM
>>>>&= gt; To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;
>= ;>>>> 'MILE IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> I like this di= scussion.
>>>>> I agree, it would be good idea to have in= dicator identifiers inside
>>>>> the IOC-related classes.=
>>>>>
>>>>> KMM: At the class level, w= e may have several indicators listed that
>>>>> should be= viewed as a set and may have another instance of that same
>>>= >> class that is a related issue, but a separate set.  We could = as you
>>>>> say, list the indicator IDs connected throug= h the reference class.
>>>>> The set IDs might give us ot= her ways to group the values when we get
>>>>> into logic= and relationships between sets or indicators.  This could
>>= >>> also be a way to connect indicators or sets across XML documen= ts that
>>>>> could have been shared previously.  If there are a large number of
>>>>> i= ndicators in the set, then this becomes useful, for smaller sets, I
>= >>>> agree it doesn't make as much sense.
>>>>&g= t;
>>>>> What do others think?
>>>>>>>>>> Then for indicators not included in the base schema t= hat may not fit
>>>>> into a category in the SCI draft, d= o we create a place for these off
>>>>> of SCI or right o= ff of the IODE schema in EventData?
>>>>> (more details>>>>> on
>>>>> this in my first message)= .
>>>>>
>>>>> If we could see any indic= ator of compromise as computer event record,
>>>>> we cou= ld use SCI:EventReport class as the place for the XML-based
>>>= >> IOCs that couldn't fit anywhere else.
>>>>>
>>>>> KMM: That sounds lik= e a good idea to me.  This should go into
>>>>> guid= ance in the SCI draft.  Does anyone else want to weigh in?
>>= >>>
>>>>>
>>>>> For the non-XM= L IOCs, we could use RecordData class, as suggested.
>>>>>= ; KMM: Sounds good, thanks!
>>>>>
>>>>>= I agree to have indicator_uid, but I am not sure about the needs of
>= ;>>>> the indicator_set_id.
>>>>> I understan= d we could do some grouping of individual indicator_uids
>>>>= ;> and its usability, but I am not sure whether we do not have any other=
>>>>> way to express these groupings.
>>>>= ;> For instance,  a Reference class refers to several indicadtor_ui= ds.
>>>>> In
>>>>> this case, they could be, in a sense, grouped. Isn't it enough?
>>>>&g= t;
>>>>> KMM: It may be, what do you think about large se= ts of indicators or
>>>>> subsequent messages that add in= dicators to existing sets?  Would this
>>>>> happen?=   Would it be easier to express relationships with sets of
>>= >>> indicators in addition to individual indicators?  By usin= g this, it
>>>>> could give us a unique way to also provi= de the logic and
>>>>> relationships in a new class of IO= DEF so we don't have to worry about
>>>>> adding it into = the current structure.
>>>>> If there are better ways to = handle that, and others can provide some
>>>>> options, t= hat would be appreciated!
>>>>>
>>>>> T= hank you,
>>>>> Kathleen
>>>>>
>>>>> I would appreciat= e if anybody could share expertise on this. Though I
>>>>>= ; think I have read all the emails in the list, I might have
>>>= ;>> mis-understood some points.
>>>>>
>>&g= t;>> By the way, I think the indicator_uids should be added to the SC= I
>>>>> classes'
>>>>> attributes so th= at they can be correlated with another information as
>>>>&g= t; well.
>>>>>
>>>>> Thanks
>>= >>> Take
>>>>>
>>>>>
>&g= t;>>>
>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf
>>>>> Of Harrington, Christopher
>>>&= gt;> Sent: Tuesday, February 05, 2013 4:25 AM
>>>>> To= : Stoecker, Paul; Moriarty, Kathleen; MILE IETF
>>>>> Sub= ject: Re: [mile] IOCs
>>>>>
>>>>> I thi= nk some sort of group ID would do the trick. We also need a
>>>= >> logical and / or somewhere to show relationship between indicators= .
>>>>> If
>>>>> I give you
>>= >>> 2
>>>>> registry keys do they both have to b= e present to be an indication of
>>>>> compromise or is e= ither one by themselves an indicator? Both would
>>>>> ha= ve the same group ID since they are related.
>>>>>
>= ;>>>> Thanks,
>>>>> --Chris
>>>&g= t;>
>>>>> From: Stoecker, Paul
>>>>> Sent: Sunday, February 03, 2013 8:26 PM
&g= t;>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IE= TF
>>>>> Subject: Re: [mile] IOCs
>>>>>=
>>>>> What if we added indicator group ID along with the= indicator_uid?
>>>>> This would allow you to group indic= ators that are related into the
>>>>> same group ID.
&= gt;>>>> Would this resolve the issue?
>>>>>>>>>> It is either that or going back to adding a Detectio= n (or Indicators)
>>>>> class that will should be used to= take all of the indicators put them
>>>>> into one place= and have the ability to group the ones that go
>>>>> tog= ether.  I don't mean a place to put indicators that are missing
>= ;>>>> from IODEF.I mean a place in the IODEF document where you put the
>>>>> indicators that are used for det= ection and prevention of the shared
>>>>> Incident. = I don't know the answer here, but there has got to be a
>>>>= ;> good way for indicators to be identified and being able to group them=
>>>>> as Chris has suggested without basically recreatin= g something
>>>>> complicated like STIX.
>>>&= gt;>
>>>>> Paul
>>>>>
>>>= ;>>
>>>>> Paul W. Stoecker, Ph.D.
>>>&g= t;> SMC Lead Content Architect
>>>>> RSA, The Security= Division of EMC
>>>>> cell: 302.379.3375 | e: pau= l.stoecker@rsa.com
>>>>>
>>>>>
&= gt;>>>> From: <Moriarty>, Kathleen <kathleen.moriarty@emc.com>
>>>>> Date: Su= nday, February 3, 2013 5:11 PM
>>>>> To: "Harrington, Chr= istopher" <Christopher.Harrington@emc.com>, MILE<= br>>>>>> IETF <mile@ietf.org>
>>>>&g= t; Subject: Re: [mile] IOCs
>>>>>
>>>>>= Hi Chris,
>>>>>
>>>>> I agree, we have= some work to do in the updated IODEF, RFC5070-bis.
>>>>>=
>>>>> The list has already said they would like to see i= ndicators added to
>>>>> the definitions in RFC5070-bis, = to be more explicit about including
>>>>> indicators and = sets of indicators in IODE documents as opposed to
>>>>> 'par= ts of an incident or the useful information on an incident for
>>&= gt;>> sharing purposes.  It was written before we used terms lik= e
>>>>> indicators.  With that in mind, Rosella prop= osed a number of changes
>>>>> back in July, both for gui= dance and for format updates.  It may help
>>>>> to = have the first draft try to address at least some of these issues
>&g= t;>>> so people can understand the problems and at least a propose= d
>>>>> solution.
>>>>>
>>>= >> As you point out, we need to be able to show relationships between=
>>>>> sets of indicators, where we may have a few sets o= f indicators that
>>>>> could have a relationship to each= other within a document.  In the
>>>>> July presentation, one of the questions was to see if we should add
>>= >>> new category attribute values for the System class that would = connect
>>>>> the list of included indicators.  I th= ink we should still keep the
>>>>> concept of a Node to a= single node, but perhaps within System, list
>>>>> multi= ple sets of Nodes that may be one type of attack.  Rosella had
>= >>>> suggested pulling forward the "FraudType" from RFC5901, th= is would
>>>>> help solve the issue as NodeRole values wo= uld compliment an
>>>>> AttackType (FraudType values coul= d be included in AttackType or some
>>>>> broader term).&= nbsp; It may be better to have the FraudTypes, plus
>>>>>= attribute values like "C2-server", "sinkhole",  "MalwareDistribution"=
>>>>> for added context so you know what to do with the received set of
>>>>> indicators.
>>&g= t;>>
>>>>> I am proposing that we change IODEF to i= nclude multiple sets of
>>>>> indicators, add an AttackTy= pe attribute (or some other name), a
>>>>> method to conn= ect indicators and indicator sets within an IODEF using
>>>>= > an attribute of indicator_uid (or some other name) with a string
&g= t;>>>> value to make the connection points, and add a few indic= ators that
>>>>> are commonly shared into the base IODEF.=
>>>>>
>>>>> Back in July, we talked ab= out adding Registry Key/Value pairs and
>>>>> hashes to t= he main IODEF document (trying to see if this will help
>>>>= > Chris below).  What if we added the Registry Key/Value pairs as a=
>>>>> class off of RecordData, using a similar structure to what is in
>>>>> RFC5901, and also added th= e ability to include hashes in RecordData?
>>>>> I think = if we then had the indicator_uid at the RecordData level, we
>>>= ;>> could connect a set within that structure and repeat the structur= e
>>>>> for other sets in the same way we would do with N= ode inside of the
>>>>> System class, using the indicator= _uid to tie the set together.  Then
>>>>> at the mor= e specific level for the hash, registry Key/value, IP, etc.
>>>= >> use an indicator_uid if we needed them marked at this level as wel= l?
>>>>> Maybe we want indicator_set at the higher level?=   I'd like some
>>>>> opinions on this approach.&nbs= p; +1 if you agree, suggestions if you have
>>>>> other i= deas that may work better.
>>>>>
>>>>> We'll also need to= worry about marking the indicators to prevent
>>>>> forw= ard sharing when not permitted.  We may want to use these values
&g= t;>>>> or something else.
>>>>>
>>&g= t;>> Thank you!
>>>>> Kathleen
>>>>&= gt;
>>>>> From: Harrington, Christopher
>>>&g= t;> Sent: Friday, February 01, 2013 12:01 PM
>>>>> To:= Moriarty, Kathleen; MILE IETF
>>>>> Subject: RE: [mile] = IOCs
>>>>>
>>>>> I think we have a bigg= er relationship issue to address. Let use the
>>>>> Watch= list Use Case. A bunch of indicators are sent in one message. In
>>= ;>>> that message we could have groupings of indicators that we ne= ed to
>>>>> show are
>>>>> related:
>>>>>
>>>>> Two or more indic= ators of different type that relate to the same
>>>>> thr= eat:
>>>>>      The file hash of a malicio= us file and the URL of the C2 that
>>>>> the file uses. E= ither or both may be present to indicate a
>>>>> compromi= se.
>>>>>
>>>>> Two or more indicators = of the same type that relate to the same
>>>>> threat:>>>>>      2 different registry values for t= he same registry key. If
>>>>> either value is present it= is a compromise indicator but both will
>>>>> not be pre= sent.
>>>>>
>>>>> The problem compounds= itself very quickly. Consider the scenario
>>>>> where b= oth groupings above are part of the same threat. I need to
>>>>> show that logical groupings of Indicators are r= elated as well. We
>>>>> can't send multiple IODEF messag= es for this from what I remember
>>>>> reading.
>&g= t;>>>
>>>>> The last one I can think of would be= when you have 2 different
>>>>> indicators that represen= t the same indicator. It's not uncommon to
>>>>> send bot= h the
>>>>> MD5
>>>>> and SHA1 hash of = a malicious file. The indicator is the file but the
>>>>>= IOCs are the 2 hash values. How do we show they are related? If we
>= >>>> use a unique Inidcator ID for each hash value there needs = to be a
>>>>> higher level grouping.
>>>>&= gt;
>>>>> Thoughts?
>>>>>
>>&g= t;>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> Christopher Harrin= gton
>>>>> Consulting Security Engineer
>>>&g= t;> GSO - Critical Incident Response Center EMC - Where Information Live= s
>>>>> 174 Middlesex Turnpike
>>>>> Be= dford, MA 01730
>>>>> 781-515-5862 (work)
>>>= >> 603-583-1585 (cell)
>>>>>
>>>>>= ; From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.o= rg] On Behalf
>>>>> Of Moriarty, Kathleen
>>= >>> Sent: Friday, February 01, 2013 11:28 AM
>>>>&g= t; To: MILE IETF
>>>>> Subject: Re: [mile] IOCs
>&g= t;>>>
>>>>> All -
>>>>>
>>>>> I'd like your input and = will refocus the thread to get opinions from
>>>>> the li= st on options to help solve the problems raised in my message
>>&g= t;>> and additionally in Paul's message.
>>>>>
&= gt;>>>> Interesting point, C. Henry.  Our objective here i= s to have machine
>>>>> automated exchanges, so we rely o= n encryption rather than obfuscation
>>>>> to achieve the= necessary level of confidentiality.
>>>>>
>>>= ;>> Paul mentioned the need to distinguish indicators of compromise f= rom
>>>>> context information that may also include IP ad= dress or other data
>>>>> that could be indicators. = The question I raised was on how to
>>>>> connect sets o= f indicators in the same IODEF document, assuming the
>>>>> ability to have watchlists that could have sev= eral sets of indicators
>>>>> included, as well as to con= nect indicators that may be included in
>>>>> embedded sc= hemas.
>>>>>
>>>>> If we add an attribu= te on all of the relevant indicators, let's say
>>>>> 'in= dicator-uid' how do we mark the indicators?  Do we use this to
>= >>>> mark who sent the indicator as well so that we can prevent= forward
>>>>> sharing when it is not permitted or handle= that separately?
>>>>>
>>>>> Then for = indicators not included in the base schema that may not fit
>>>= >> into a category in the SCI draft, do we create a place for these o= ff
>>>>> of SCI or right off of the IODE schema in EventD= ata? (more details on
>>>>> this in my first message).
>>>>>
>>>>> Comments and que= stions encouraged to figure out the right technical
>>>>>= solution to have this machine automatable.
>>>>>
>= >>>> Thank you,
>>>>> Kathleen
>>>= ;>>
>>>>> From: mile-bounces@ietf.org [m= ailto:mile-bounces@ietf.org] On Behalf
>>>>> O= f C.
>>>>> Henry Adams & BIE
>>>>> = Sent: Monday, January 28, 2013 11:25 PM
>>>>> To: MILE IE= TF
>>>>> Subject: Re: [mile] IOCs
>>>>>=
>>>>> Temporal Dependency sounds interesting.  I re= member when I first ran
>>>>> across this particular craft, an experienced colleague asked me a
>>>>> peculia= r question.  He said, " How do you stop someone from tracking
>&= gt;>>> the IP Address to your computer?"
>>>>>>>>>> I replied, "I don't know, how?"
>>>>&= gt;
>>>>> Then he said, "Cut the dog-gone thing off = and the modem that it is
>>>>> connected- which is const= antly on!"   LOL
>>>>>
>>>>= > Here's my point (Hypothetical Situation) :  There is a 1st Respon= der
>>>>> searching a Neighborhood for Survivors which we= re hit by a Disaster
>>>>> or let's just say "Live" Terro= rist Situation.  He /or She needs to
>>>>> communica= tion back to other Officials that he /or somehow is in
>>>>&= gt; Danger.  The device used to communicate has been captured by the
>>>>> great minds of the enemy.  It's only a= matter of time before they
>>>>> utilize reverse enginee= ring to figure out how it functions.  However,
>>>>>= their pride comes before a fall when seeking the location of other
>= >>>> similar devices to attack.  Why? Perhaps the less tho= ught of concepts
>>>>> that makes the device function pro= perly, saves the day by disguise or
>>>>> cutting it off = (figuratively speaking).
>>>>>
>>>>> Ju= st a visionary thought.
>>>>>
>>>>> C. = Henry Adams
>>>>> chenryadams@biemediagrou= p.com
>>>>> http://biemediagroup.com
>>>>>
= >>>>>
>>>>> The information contained here= in is for the exclusive use of the
>>>>> original recipie= nt. This information is granted for limited
>>>>> distrib= ution within the recipient's place of business for planning
>>>= >> purposes only. Further dissemination, whether private or public is=
>>>>> prohibited.
>>>>>
>>>= ;>> --- On Mon, 1/28/13, Dave Misell <david.misell@bcs.org> wrote:
>>>>>
>>>>> From: Dave Mi= sell <david.misell@bcs.org>
>>>>> Subject= : Re: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
>>>>> Date: Mon= day, January 28, 2013, 9:25 PM UID could be mirrored with
>>>&g= t;> DNS SEC a pemanent and temporal key, with a temporal Id?
>>= >>>
>>>>> Yours Faithfully,
>>>>&= gt;
>>>>> Dave Misell MSc CISSP
>>>>> S= ilentCircle  dsm
>>>>> 07710 380044
>>>&= gt;> david.misell@bcs.org
>>>>>
>>&= gt;>>
>>>>> On 29 Jan 2013, at 00:39, C. Henry Adam= s & BIE
>>>>> <chatlga2000@yahoo.com>= ;
>>>>> wrote:
>>>>>
>>>>= ;> Serialization of a particular Lists of XML Classes in a unique way
>= >>>> was closely related to what I attempted to express when I = stated,
>>>>> "consider to a degree what appears to be il= logical in brilliant minds
>>>>> in some instances."
&= gt;>>>>
>>>>> However, I see Dr. Stoecker's p= oint a little clearer.  However, it
>>>>> would be n= ice if the UID was in some way disguised from those who
>>>>= > study this Security Art Form in a negative way.
>>>>>= ;
>>>>> C. Henry Adams
>>>>> cha= tlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com
>>>>>
&= gt;>>>>
>>>>> The information contained herei= n is for the exclusive use of the
>>>>> original recipien= t. This information is granted for limited
>>>>> distribu= tion within the recipient's place of business for planning
>>>&= gt;> purposes only. Further dissemination, whether private or public is<= br>>>>>> prohibited.
>>>>>
>>>= >> Re: [mile] IOCs
>>>>>
>>>>> Su= nday, January 27, 2013 8:52 PM
>>>>> From:
>>>= ;>> "Stoecker, Paul" <Paul.Stoecker@rsa.com>
>= >>>> To:
>>>>> "mil= e@ietf.org" <mile@ietf.org>
>>>>> I would li= ke to look at this from a slightly different
>>>>> perspe= ctiveSlet's say I get an XML document that tells me about an
>>>= ;>> incident.  This document has source IP and destination IP th= at is
>>>>> being shared.  However, what I don't kno= w is which IP address is my
>>>>> indicator and which is = just a contextual piece of information.  This
>>>>> = means that my detection product isn't going to know which one to use
>= ;>>>> either, because there is nothing to tell me which IP is t= he one, even
>>>>> if the roles are set it still might no= t be enough to tell my system
>>>>> which one I should us= e as the indicator.
>>>>>
>>>>> If we ha= d something like indicator_id as an attribute, it would allow
>>&g= t;>> us to easily identify indicators from contextual data.  I d= o admit to
>>>>> being biased as I have spent much of my = career working on the
>>>>> monitoring and detection side= of these things, so I am just thinking
>>>>> of ways to = make it very clear what the indicators are in the XML
>>>>&g= t; document and the other data that may be important as I investigate
&g= t;>>>> activity that I have detected off of those indicators.>>>>>
>>>>>
>>>>> I di= d suggest the detection class, but I think we may get more
>>>&= gt;> flexibility with the indicator_uid.  One thing that I haven't<= br>>>>>> considered is the UID portion of thisShow do we use that UID?  How is
>>>>> the UID created?&nbs= p; Are there standards for UIDs?
>>>>>
>>>>= ;> Regards,
>>>>>
>>>>> Paul
>= >>>>
>>>>>
>>>>>
>>= ;>>> Paul W. Stoecker, Ph.D.
>>>>> SMC Lead Cont= ent Architect
>>>>> RSA, The Security Division of EMC
= >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com
>>>>>
>>>>> --- On Sat, 1/26/13, C. = Henry Adams & BIE <chatlga2000@yahoo.com>
>>&= gt;>> wrote:
>>>>>
>>>>> From: C.= Henry Adams & BIE <chatlga2000@yahoo.com>
>>>>> Subject: RE: [mi= le] IOCs
>>>>> To: "KathleenMoriarty" <kath= leen.moriarty@emc.com>
>>>>> Cc: mile@ietf.org<= br>>>>>> Date: Saturday, January 26, 2013, 6:17 PM
>&g= t;>>>
>>>>> Greetings Kathleen,
>>>&= gt;>
>>>>> Your logic stimulates my visionary brain be= cause I'm amazed at the
>>>>> many avenues you review wit= h this approach at once.  However,  could
>>>>>= you share a few advantages and disadvantages to the latter?
>>>= ;>> --------------------------------------------------------------------
&g= t;>>>> --------
>>>>> -----------------------= -----------------------
>>>>> "we could continue to group= items in logical places as is done now in
>>>>> IODEF an= d then have the extension point for combined indicators via
>>>= >> SCI."
>>>>> ------------------------------------= --------------------------------
>>>>> --------
>&g= t;>>> ---------------------------------------------
>>>= ;>>
>>>>> You pointed out what you consider to be l= ogical places, but if I
>>>>> wanted to protect informati= on from parties capable of ascertaining it
>>>>> from you= r logical places, perhaps we should also consider to a degree
>>&g= t;>> what appears to be illogical in brilliant minds in some instances.
>>>>>
>>>>>
>>>= >>
>>>>> C. Henry Adams
>>>>> chatlga2000@yahoo.com (Direct Email)
>>>>> chenryadams@biemediagroup.com
>>>>>
>&= gt;>>> The information contained herein is for the exclusive use o= f the
>>>>> original recipient. This information is grant= ed for limited
>>>>> distribution within the recipient's = place of business for planning
>>>>> purposes only. Furth= er dissemination, whether private or public is
>>>>> proh= ibited.
>>>>>
>>>>> --- On Sat, 1/26/13= , Moriarty, Kathleen <kathleen.moriarty@emc.com>
>>>>> wrote:>>>>>
>>>>> From: Moriarty, Kathleen <= ;kathleen.moriarty@emc.com>
>>>>> Subje= ct: RE: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" = <chatlga2000@yahoo.com>, "mile@ietf.org"
>>>= ;>> <mile@ietf.org>
>>>>> Date: Saturday, = January 26, 2013, 10:13 AM
>>>>>
>>>>> = Hello C. Henry & others,
>>>>>
>>>>>= ; Thanks for taking a look at this.  We have a few considerations in
>>&g= t;>> this email thread I would like to hear thoughts on (and there ma= y be
>>>>> more once RFC5070-bis is actively edited).
= >>>>>
>>>>> The AdditionalData class and t= he RecordItem class both allow for
>>>>> non-XML extensio= ns.  Where you place the extensions should be
>>>>> = specific to the logical grouping of the parent elements so you can
>&= gt;>>> understand more about the included data in most cases.
&= gt;>>>>
>>>>> The Impact class can be used to= provide context information on the
>>>>> included data o= f the report and also can include a confidence rating
>>>>&g= t; on the report as a whole.  Extensions related to impact would be on= e
>>>>> level higher (at the moment) in the Assessment class using the
>>>>> AdditionalData extensio= n point.
>>>>>
>>>>> Take asked about i= ncluding vulnerability information, I would think
>>>>> t= hat would fit under the Vulnerability extension point of the SCI
>>= ;>>> draft in the Method class.  He did ask about non-XML.&nb= sp; RecordItem or
>>>>> AdditionalData do allow for non-X= ML extension points, we could either
>>>>> have the SCI d= raft handle these as well or have the extensions that
>>>>&g= t; are non-XML come directly off the AdditionalData or RecordItem
>&g= t;>>> classes according to what makes sense from a logical standpo= int.
>>>>>
>>>>> As for my question, it= was two-fold.
>>>>>
>>>>> Indicator ba= sed schemas have a reference number or a GUID for the
>>>>> various indicators they share.  If we are= extending to embed other
>>>>> schemas that include such= reference or GUID identifiers, do we want
>>>>> to add a= n attribute to the various elements in IODEF that could be
>>>&= gt;> indicators?  Is this enough to make the connections or is some= thing
>>>>> else else needed?  We could add somethin= g like an Indicator_ID in
>>>>> RFC5070-bis which would t= hen correlate to the reference or GUID
>>>>> identifiers.=
>>>>>
>>>>> Then the other question wa= s on how to include indicators that are not
>>>>> in the = base schema that may be related or have language with "and"
>>>= >> "or"
>>>>> to
>>>>> specify th= e relationships.  In some cases, you will want to group
>>>>> these indictors in one extension point, wher= e they may fit logically
>>>>> in multiple places if the = relationships did not need to be shown in
>>>>> the data = format.  If we have cases like this where you need more
>>>= ;>> complex representations, should we use one extension point via th= e
>>>>> SCI draft off of the EventData class AdditionalDa= ta extension point?
>>>>> Opinions are needed here....>>>>>
>>>>> A few people have mentioned w= anting to include some commonly shared
>>>>> indictors in= to the base IODEF document.  We could have a catch-all
>>>= >> class that does this and has an extension point off of it in
&g= t;>>>> EventData or we could continue to group items in logical= places as is
>>>>> done now in IODEF and then have the extension point for combined
>>>>> indicators v= ia SCI.  I think I like the latter approach.
>>>>>>>>>> Thank you,
>>>>> Kathleen
>&= gt;>>> ________________________________________
>>>>= ;> From: mile-bounces@ietf.org [mile-bounces@ietf.org<= /a>] On Behalf Of C.
>>>>> Henry
>>>>> = Adams & BIE [chatlga2000@yahoo.com]
>>>>>= ; Sent: Saturday, January 26, 2013 3:05 AM
>>>>> To: mile@= ietf.org
>>>>> Cc: C. Henry Adams
>>>>= > Subject: Re: [mile] IOCs
>>>>>
>>>>> G= reetings Everyone,
>>>>>
>>>>> Take men= tioned two types of indicators based on the :
>>>>> -----= ---------------------------------------------------------------
>>= >>> --------
>>>>> -------------------------->>>>> 1) If the indicators are something like an XML-based = alert/warning of
>>>>> information leakage, it could be a= n event that are conveyed in the
>>>>> SCI's EventReport = class, IMHO.
>>>>>
>>>>> 2) If the indi= cators are something like an non-XML ones, I guess it
>>>>&g= t; could be conveyed without using SCI draft.
>>>>> For i= nstance, we could use Impact class of the base IODEF to convey
>>&= gt;>> the indicators.
>>>>> We could for instance extend the list of indicators of the Impact
>>>>&g= t; class, if needed.
>>>>> ------------------------------= --------------------------------------
>>>>> --------
= >>>>> --------------------------
>>>>>
= >>>>> In doing so he pointed out the "Impact Class"
>&= gt;>>>
>>>>> Whereas, Kathleen stated,
>&g= t;>>> ------------------------------------------------------------= --------
>>>>> --------
>>>>> ---------= ----------------
>>>>> For the discussion below, I was th= inking more of combined set with
>>>>> relationships that= may be included in a single extension point, so
>>>>> th= at's why I was thinking about the EventData class, but there may be
>= >>>> better locations or a specific area within the EventData.
>>>>>
>>>>> Paul Stoecker h= ad suggested a "Detection" class as a consideration.
>>>>>= ; --------------------------------------------------------------------
&= gt;>>>> --------
>>>>> ----------------------= --
>>>>>
>>>>> Kathleen thoughts relate= d yet still with other indicators and the
>>>>> EventData= Class.
>>>>>
>>>>> Is there a possible= way to create a new XML class which encompass
>>>>> comb= ining the EventData, Detection and base IODEF classes to simplify
>&g= t;>>> this issue?
>>>>>
>>>>><= br>>>>>> C. Henry Adams
>>>>> chatl= ga2000@yahoo.com (Direct Email)
>>>>> chenryadams@biemediagroup.com
>>>>>
&= gt;>>>>
>>>>> The information contained herei= n is for the exclusive use of the
>>>>> original recipien= t. This information is granted for limited
>>>>> distribu= tion within the recipient's place of business for planning
>>>&= gt;> purposes only. Further dissemination, whether private or public is<= br>>>>>> prohibited.
>>>>> _______________= ________________________________
>>>>> mile mailing list<= br>>>>>> mile@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mile
>&g= t;>>>
>>>>> ____________________________________= ___________
>>>>> mile mailing list
>>>>&g= t; mile@ietf.org
>>>>> https://www.ietf.org/mailman/list= info/mile
>>>>>
>>>>> _____________= __________________________________
>>>>> mile mailing lis= t
>>>>> mile@ietf.org
>>>>> https://w= ww.ietf.org/mailman/listinfo/mile
>>>>>
>>&g= t;>>
>>>>> _______________________________________________
>>>>> mi= le mailing list
>>>>> mile@ietf.org
>>>>= ;> https://www.ietf.org/mailman/listinfo/mile
>>>>><= br>>>>>> _______________________________________________
= >>>>> mile mailing list
>>>>> mile@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/mile>>>>>
>>>>> ____________________________= ___________________
>>>>> mile mailing list
>>&g= t;>> mil= e@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/= mile
>>>>
>>>> __________________________= _____________________
>>>> mile mailing list
>>>= > mile@ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/mile
>>>
>>> _______________________________= ________________
>>> mile mailing list
>>> mile@iet= f.org
>>> https://www.ietf.org/mailman/listinfo/mile
>&g= t;>
>>
>> ____________________________________________= ___
>> mile mailing list
>> mile@ietf.org
>> = ht= tps://www.ietf.org/mailman/listinfo/mile
>>
>
>___= ____________________________________________
>mile mailing list
&g= t;mile@ietf.org
>https://www.ietf.org/mailman/listinfo/mile
&= gt;

---36511695-1834828720-1361338150=:43634-- From kathleen.moriarty@emc.com Tue Feb 19 23:50:49 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BBF21F882D for ; Tue, 19 Feb 2013 23:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[AWL=-1.915, BAYES_00=-2.599, FRT_STOCK2=3.988, MANGLED_BELOW=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIvvcckESX7c for ; Tue, 19 Feb 2013 23:50:45 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 788D821F87CC for ; Tue, 19 Feb 2013 23:50:45 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1K7oelJ001306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 02:50:43 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 20 Feb 2013 02:50:29 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1K7oPYk013537 for ; Wed, 20 Feb 2013 02:50:26 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 20 Feb 2013 02:50:24 -0500 From: "Moriarty, Kathleen" To: MILE IETF Date: Wed, 20 Feb 2013 02:46:39 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac4PK2wpxcw209oXRPKTnONCq+tVwgAEv6RT Message-ID: References: <1361338150.43634.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <1361338150.43634.YahooMailClassic@web121604.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:50:49 -0000 I'd prefer that we don't break the functionality used by a large community = (CIF). Instead of deprecating a feature now, why don't we go down the rout= e of stating a strong preference (RECOMMENDED) for using the tags and listi= ng a mapping in rfc5070bis for the numeric values? I'd like to hear from some of the current users as well. We can revisit this again before we finalize the draft. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry A= dams & BIE [chatlga2000@yahoo.com] Sent: Wednesday, February 20, 2013 12:29 AM To: MILE IETF Subject: Re: [mile] IOCs Greetings Everyone, After further consideration, I still tend to lean toward a simplified vers= ion of the confidence rating. Which in my opinion, has now changed to ENUM= or enumerated type ONLY. Furthermore, perhaps { low, medium, high}, should be altered to be {low, = minor, medium, high, major} This has a low confidence rating of compromise This has a minor confidence rating of compromi= se This has a medium confidence rating of compro= mise This has a high confidence rating of compromise= This has a major confidence rating of compromi= se << Not sure if the statement below is logical, just Brainstorming>> Furthermore, let's say Low was map to 1.0. Minor map to 2.0. Medium map t= o 3.0 High map to 4.0. Major map to 5.0 The mapping procedure is the value built-in the ENUM. (Please feel free to= correct me if I'm wrong.) Then, simple statistical math is apply in some form to equate an overall va= lue of analysis. C. Henry Adams This is exactly my point. I would leave out the numeric ratings. I consume the data and at least with the enumerated type I don't have to also create a map if I want to get back to low, medium and high. I will have to make that transform anyway, so that my SOC knows the confidence without having to keep looking it up ;-) I like the simplicity of the enumerated type=8Apeople can take that and make it into whatever they want as far as numerics are concerned. Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 2/19/13 9:43 AM, "Eric Burger" > wrote: >If the proposal is 0-19 =3D low, 20-39 =3D =8A, 80-99 =3D high, then why d= o we >have the numbers, or why do we have the enumerated type? Either it is a >number or it is an enumerative value. Having both is asking for trouble. > >On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen" >> wrote: > >> Should we provide guidance similar or the same as what CIF uses (was >>posted to the list previously)? They use direct mapping to 5 levels so >>that you can have ranges of numeric values used from 0-100, low to high. >> This would be the easiest solution... >> >> Thanks, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Eric >>Burger [eburger-l@standardstrack.com] >> Sent: Tuesday, February 19, 2013 7:38 AM >> To: MILE IETF >> Subject: Re: [mile] IOCs >> >> If there really is no value to a value, do not let people hurt >>themselves. >> >> If there is a proprietary reason for a value, we should say what we >>mean and call it such. For example: >> >> This is XML so put your >>NON-INTEROPERABLE mumble you want here >> or >> 42 >> or >> >rating=3D"medium">balderdash>gToMe> >> >> On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" >>> wrote: >> >>> I would agree that flexibility is something to strive for. However >>>there >>> isn't enough in the RFC to make the numeric confidence value >>>understood by >>> the recipient and therefore actionable. From the spec: >>> >>> "numeric. The element content contains a number that conveys the >>>confidence >>> of the data. The semantics of this number outside the scope of this >>> specification" >>> >>> Based on that I can score my confidence with 1 being most confident >>>and 100 >>> being least. Perfectly legitimate but would probably mess everybody >>>up. What >>> if my scale is 1000 and yours is 100. I send you something with a >>>score of >>> 100 you will think I am absolutely certain when I am only 10% so. >>>Knowing >>> how sure the sender is about a piece of data shared is critical. If the >>> sender puts an arbitrary number in the field I have no point of >>>reference. >>> It's meaningless to me. >>> >>> We spell out what the relative value is for low/med/high. I know those >>>are >>> self-explanatory but they are still spelled out. I would urge that we >>>do the >>> same for a numeric value. If not there needs to be something added so >>>that >>> in addition to the numeric value I have a point of reference for how >>>certain >>> you are based on the number you put there. >>> >>> Thanks, >>> >>> --Chris >>> >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>> Banghart, John >>> Sent: Monday, February 18, 2013 7:42 AM >>> To: Eric Burger; MILE IETF >>> Subject: Re: [mile] IOCs >>> >>> Eric, >>> >>> Well, I think you answered your own initial question, but I'm going to >>>jump >>> in anyway. :) >>> >>> Generally speaking, I think we want to strike a balance between >>> standardization and flexibility. We are unlikely to arrive at any >>>sort of >>> one-size-fits-all scheme, no matter how long we talk about it. >>>Instead, we >>> should be focusing on solidifying the areas we can all agree on, and >>>allow >>> flexibility for those that we don't. It's an age old clich=E9, but >>>let's not >>> let perfect be the enemy of the good. >>> >>> -John >>> >>> On 2/16/13 12:42 PM, "Eric Burger" > >>>wrote: >>> >>>> What is the justification for both numeric and enumerated values >>>> (low/medium/high)? In general such a schema is begging for >>>> interoperability problems. >>>> >>>> I suppose I can understand both sides of the argument. On the We Need >>>> Numbers side is those that actually calculate a percentage or other >>>> objective measure in the confidence may want to use those real >>>>numbers. >>>> As well, on the We Need Numbers side is the argument that three >>>> enumerated values may not prove sufficient in the future. On the We >>>> Need Enumerated Values side is confidence, other than 0% and 100%, >>>>tend >>>> to be arbitrary guesses. Putting a number on this value imparts a >>>>level >>>> of specificity that does not exist. Also, it is a lot easier to map >>>> 'low' to 'low' than it is to map 0-33 to 'low'. >>>> >>>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher" >>>> > wrote: >>>> >>>>> That will work provided I (and everyone else) has a mapping for the >>>>> numbers. I would prefer a simple low/med/high scheme. The more we >>>>>add >>>>> the more you have to be able to differentiate between them. However >>>>> for potential interoperability I do see the benefit of the 5. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, February 13, 2013 2:05 PM >>>>> To: Harrington, Christopher; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> >>>>> If you think of IODEF just for transport, could you meet your needs >>>>> with storing the values differently in a database (IODEF is just >>>>>meant >>>>> for the exchange)? The numbers map to low/med/high - for db storage >>>>>- >>>>> if numbers are used, you could store the equivalent value, adding the >>>>> 2 additional ones provided. >>>>> >>>>> Does it make sense to expand the set of values to match what CIF is >>>>> doing if we went forward with the approach of supporting both >>>>>options? >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Wednesday, February 13, 2013 11:49 AM >>>>> To: 'C. Henry Adams & BIE'; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> From a data processing standpoint it is going to create extra work >>>>> for the people who are going to receive this data if we support both >>>>> numeric and alpha characters in the same field. I can envision people >>>>> wanting to search, sort, store, etc the data in this field. If we >>>>> allow both data types then everyone will need to have a mapping of >>>>> some sort. I have a field for confidence in my threat tracking >>>>> database. Having both a numeric score and alpha characters / words >>>>> creates issues when trying to interact with the data. I agree that we >>>>> need to support both however I don't think both should be in the same >>>>> field. I would much rather see 2 different fields for Confidence if >>>>>we >>>>> are going to support 2 different data types. >>>>> >>>>> This will be a larger issue should Confidence be used elsewhere. >>>>> Ideally in future revisions I would like to see attribution expressed >>>>> as some form of attribution is almost always shared with an IoC. >>>>> Currently there are 5 areas where we (EMC) uses confidence. >>>>> >>>>> Indicator (how confident are you that this is a valid IoC) >>>>> Indicator_Set (how confident are you that all of the indcators in the >>>>> set should be in the set) Campaign (how confident are you that all >>>>> Indicator_Sets are part of this campaign) Threat Actor (how >>>>>confident >>>>> are you that the Campaign is attributed to this Threat Actor) Threat >>>>> Actor type (how confident are you that this Theat Actor is APT, >>>>> Crimeware, other) >>>>> >>>>> The threat actor name and the threat actor type are usually the first >>>>> 2 things that anyone processing IoCs wants to know as they drive >>>>>priority. >>>>> Knowing how sure the sender is that this IoC is APTis a vital piece >>>>> of information for us. Sorry to take us a little off the path but I >>>>> wanted to show where Confidence could be used. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. Henry Adams & BIE >>>>> Sent: Wednesday, February 13, 2013 10:24 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Again, I would concur that both a numeric and subjective analysis of >>>>> the Confidence Rating needs to be express, but combined in a >>>>> simplified schema as such below: >>>>> >>>>> 1LL .... etc. >>>>> >>>>> 2P >>>>> >>>>> 3AC >>>>> >>>>> 4U >>>>> >>>>> 5I >>>>> >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Here's my point, perhaps a set of numeric related or associated >>>>> definitions can lower the propagation of error regarding the >>>>>analysis. >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> I agree that what we really need is both. In most situations a low, >>>>> medium and high may be acceptable but there are times when we will >>>>> want to show that confidence in a situation is increasing or >>>>> decreasing. If we are only looking at a three levels, we cannot >>>>> express what is needed to show confidence is trending up on the data >>>>> being exchanged about the event. >>>>> >>>>> Kathleen included the following in a previous message. >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> I really think we need to include both capabilities as John alluded >>>>> to since confidence is not a three tiered item but something that is >>>>> indeed subjective and we need a means to show a reasonably accurate >>>>> confidence index that the sender is trying to convey. >>>>> >>>>> Kent Landfield >>>>> >>>>> McAfee | An Intel Company >>>>> Direct: +1.972.963.7096 >>>>> Mobile: +1.817.637.8026 >>>>> Web: www.mcafee.com >>>>> >>>>> From: , John Banghart > >>>>> Date: Wednesday, February 13, 2013 7:16 AM >>>>> To: "Stoecker, Paul" >, Kathleen Moriarty >>>>> >, Brian Trammell > >>>>> Cc: "C. Henry Adams & BIE" >, MILE IETF >>>>> > >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Paul, >>>>> >>>>> I agree that confidence is subjective, but subjectivity can be >>>>> reduced within communities that interact frequently. Prioritization >>>>> of indicators and response between tightly connected sharing >>>>>partners >>>>> might require a more specific level of detail, particularly during a >>>>> crisis situation. >>>>> >>>>> From that perspective, I think the guidance should allow for >>>>> additional granularity, while stressing the "high, medium, low" as >>>>> preferred for broad interoperability. >>>>> >>>>> -John >>>>> >>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" > wrote: >>>>> >>>>> I may have been too succinct in my response ;-) >>>>> >>>>> Confidence is a subjective thing, so I think we should use subjective >>>>> terms: Low, Medium, High. Having a numeric scale with a map that >>>>> essentially would say something like: >>>>> >>>>> 1-33 =3D Low >>>>> 34-67=3D Medium >>>>> 68-100=3DHigh >>>>> >>>>> Is just a more complicated way of saying that something is Low, >>>>> Medium, High...do we really thing that how High something is makes >>>>> that much of a difference? >>>>> >>>>> This is like when you get your Performance review where it is Does >>>>> Not Meet, Meets and Exceeds...your boss tells you that you are a High >>>>> Meets...your bonus tells you that you got the same bonus that all the >>>>> other Meets got >>>>> ;-) >>>>> >>>>> Anyway, I digress but trying to prove a point that I would argue that >>>>> confidence in this case is going to be basically a gut feeling, so >>>>>why >>>>> use numeric values when Low, Medium, High would do just fine. >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" > >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Both approaches will validate in the current schema. The >>>>> representation looks a little different for each, here is an example: >>>>> >>>>> >>>>> >>>>> Vs: >>>>> >>>>> 85 >>>>> >>>>> Searching capability is a great point, agreed. I'd like to hear from >>>>> more people to make sure we don't lose a capability that others find >>>>> extremely useful (need to gauge that). Other options is that the >>>>> guidance can also discourage the use of the numeric in addition to >>>>> specifying how to select ranges. >>>>> >>>>> Any other opinions? >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Stoecker, Paul >>>>> Sent: Wednesday, February 13, 2013 7:14 AM >>>>> To: Brian Trammell >>>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Cant we make Confidence a List that has only 3 values: High, Medium, >>>>> and Low? Any other value means that the Document will mot validate >>>>> against the schema. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell" >>>>> > >>>>> wrote: >>>>> >>>>> Hi, Kathleen, all, >>>>> >>>>> I think 3.10.4 in 5070 takes the right approach here: trying to build >>>>> interoperable numeric scales for assessment is a very hard problem. >>>>> (Were I charged with defining such a scale, the value "70" would mean >>>>> "we compared this incident report to N past similar incident reports >>>>> according to similarity algorithm S, and 70% of the past reports had >>>>> assessed impacts within E% of the actual, measured final impact -- I >>>>> think for most applications this is vastly more difficult and >>>>> rigorous than it needs to be.) >>>>> >>>>> Unless a numeric Confidence value is based on some actual, repeatably >>>>> measurable aspect of the Assessment report -- which I suspect in >>>>> many/most/all cases it's not -- then it just represents a guess, >>>>> however educated. Each team will probably naturally tune its own >>>>> scales such that each value generally means the same thing in each >>>>> report. Across teams, I don't know. >>>>> >>>>> On the other hand, Assessments are by their very nature educated >>>>> guesses, anyway, so I don't know that I'd find much use in automating >>>>> a response based on the assessment confidence. Chris has a good >>>>> point, though -- it makes searching difficult and sorting kind of >>> pointless. >>>>> >>>>> If we've seen a general trend toward "0 =3D 0%, 100 =3D 100%", then I >>>>> agree, we should put that in the guidance document (along with a note >>>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to >>>>> high, unless we want to do it non-linearly). If the _vast_majority_ >>>>> of the users of this field use a 100-point scale with 100 meaning >>>>> "yes" and 0 meaning "any resemblance these values may have to actual >>>>> fact is purely coincidental", then let's consider renaming it >>>>>"percent" >>> in 5070-bis. >>>>> >>>>> Best regards, >>>>> >>>>> Brian (as contributor) >>>>> >>>>> >>>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen" >>>>> > wrote: >>>>> >>>>> Please see section 3.10.4 of RFC5070 as a starting point. We can >>>>> change it if it needs to be changed. The value is for a confidence >>>>> rating on the indicators shared. The definitions may be helpful for >>>>> anyone who wants to work on this discussion. IODEF has various >>>>> markers that can be used in a complimentary way without conflating >>>>> the markers meaning. >>>>> >>>>> I think some people using IODEF find the numerical values more >>>>> helpful, and it would be good to understand what people have learned >>>>> from using the current structure (what works/does not work). The >>>>> scales I have seen are 0-100. There is of course a subjective >>>>> element to assigning a numerical value to the confidence and it may >>>>> vary from entity to entity. With this type of rating you may need to >>>>> consider who it came from and how they scored the confidence rating >>>>> to map to your own rating. It would be good to hear more thoughts on >>> this. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> From: C. Henry Adams & BIE [mailto:chatlga2000@yahoo.com] >>>>> Sent: Tuesday, February 12, 2013 2:46 PM >>>>> To: MILE IETF >>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> >>>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital >>>>> point. Different Confidence levels will cause confusion. It appears >>>>> that there maybe a need for some type of simplified standardization >>>>> to be established between all Sharing Groups in this regard. >>>>> >>>>> Perhaps numerical scoring set at lower values should express levels >>>>> of urgency. >>>>> ( i.e. 1 =3D Less Likely, 2 =3D Probable, 3 =3D A Concern, 4 =3D >>>>>Urgent, >>>>> 5 =3D Imminent ) >>>>> >>>>> Thanks, >>>>> C. Henry Adams >>>>> >>>>> >>>>> >>>>> I see some confusion coming down the pike if we start using >>>>> Confidence the way it is supported. If I am using low/med/high and >>>>> someone sends me an IoC with a score of 70, what does that mean to >>>>> me? What if I am using a scale of >>>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability >>>>> to describe something with a consistent language. It really gets ugly >>>>> when we store IoC from multiple sources. I have confidence values >>>>> that are numeric as well as text. Makes searching / sorting very >>>>> problematic. >>>>> >>>>> At this point we have to roll with what we have. I would strongly >>>>> recommend that we revisit this at some point. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Tuesday, February 12, 2013 9:59 AM >>>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Chris & Take, >>>>> >>>>> I'll just focus on the confidence scoring. Right now, the schema >>>>> allows for you to either use a numerical score OR the ratings of low, >>>>> medium, and high. >>>>> Different sharing groups can decide how they want to share the data. >>>>> If >>>>> people were to use the numerical values, I agree it would be helpful >>>>> to have guidance. This could go in the IODE guidance document. >>>>> >>>>> I have seen examples of current users that use each of the >>>>> approaches, so we'll need to keep the option for backwards >>>>> compatibility and it is nice to keep in flexible options where we >>>>> can. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher >>>>> Sent: Tuesday, February 12, 2013 9:22 AM >>>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> The number of indicators wouldn't necessarily drive the use of >>>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP >>>>> addresses that were used as C2 for 3 different campaigns I would have >>>>> separate indicator_set_ids, each with one of the 3 C2 IPs >>>>> >>>>> My suggestion would be a simple low, medium, high. I think if we >>>>> break it down to more levels than that we would need to provide >>>>> guidance on scoring, rating, etc. I think most people should be able >>>>> to understand low/med/high without having to have a mathematical >>>>> method for arriving at the level. >>>>> >>>>> Low - I am not sure >>>>> Medium - I am reasonably sure >>>>> High - I am very sure >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 12, 2013 4:21 AM >>>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Regarding the indicator_set_id, I agree, it is useful when we need to >>>>> deal with large sets of indicators. >>>>> Since indicator_set_id attribute is optional (right?), it could be >>>>> omitted if we need to deal with only small number of indicators. >>>>> >>>>> Regarding the use case, I like the idea of using the confidence >>>>> attribute for the reason Chris kindly described. >>>>> I would like to hear a bit more on this: is it going to be numerical? >>>>> For >>>>> instance, 1 means "no confidence" while 5 means "strong confidence", >>>>> etc? >>>>> >>>>> Thank you. >>>>> Take >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com<= http://us.mc1216.mail.yahoo.com/mc/compose?to=3DChristopher.Harrington@emc.= com>] >>>>> Sent: Friday, February 08, 2013 4:11 AM >>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> With respect to tying things back to threat actors, from what I have >>>>> seen and use this is a generally accepted grouping: >>>>> >>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor >>>>> >>>>> Campaign and Threat Actor are where having a "Confidence" attribute >>>>> would be beneficial as making those associations is not a perfect >>>>> science by any means. >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Thursday, February 07, 2013 2:00 PM >>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE >>>>> IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> Hi Take & others, >>>>> >>>>> Thanks for chiming in, I've been talking about this with Chris and a >>>>> few others on their use cases and would like more opinions. I'll >>>>> provide an option below from what we have discussed from a CIRC view >>>>> point. We are also wondering how to also provide logic in IODEF that >>>>> could cross over into SCI attached schemas or IODEF extensions (the >>>>> solutions may all tie together with this discussion - or there may be >>>>> better/more elegant solutions others would like to propose). >>>>> >>>>> -----Original Message----- >>>>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>>>> Sent: Tuesday, February 05, 2013 12:04 PM >>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; >>>>> 'MILE IETF' >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I like this discussion. >>>>> I agree, it would be good idea to have indicator identifiers inside >>>>> the IOC-related classes. >>>>> >>>>> KMM: At the class level, we may have several indicators listed that >>>>> should be viewed as a set and may have another instance of that same >>>>> class that is a related issue, but a separate set. We could as you >>>>> say, list the indicator IDs connected through the reference class. >>>>> The set IDs might give us other ways to group the values when we get >>>>> into logic and relationships between sets or indicators. This could >>>>> also be a way to connect indicators or sets across XML documents that >>>>> could have been shared previously. If there are a large number of >>>>> indicators in the set, then this becomes useful, for smaller sets, I >>>>> agree it doesn't make as much sense. >>>>> >>>>> What do others think? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? >>>>> (more details >>>>> on >>>>> this in my first message). >>>>> >>>>> If we could see any indicator of compromise as computer event record, >>>>> we could use SCI:EventReport class as the place for the XML-based >>>>> IOCs that couldn't fit anywhere else. >>>>> >>>>> KMM: That sounds like a good idea to me. This should go into >>>>> guidance in the SCI draft. Does anyone else want to weigh in? >>>>> >>>>> >>>>> For the non-XML IOCs, we could use RecordData class, as suggested. >>>>> KMM: Sounds good, thanks! >>>>> >>>>> I agree to have indicator_uid, but I am not sure about the needs of >>>>> the indicator_set_id. >>>>> I understand we could do some grouping of individual indicator_uids >>>>> and its usability, but I am not sure whether we do not have any other >>>>> way to express these groupings. >>>>> For instance, a Reference class refers to several indicadtor_uids. >>>>> In >>>>> this case, they could be, in a sense, grouped. Isn't it enough? >>>>> >>>>> KMM: It may be, what do you think about large sets of indicators or >>>>> subsequent messages that add indicators to existing sets? Would this >>>>> happen? Would it be easier to express relationships with sets of >>>>> indicators in addition to individual indicators? By using this, it >>>>> could give us a unique way to also provide the logic and >>>>> relationships in a new class of IODEF so we don't have to worry about >>>>> adding it into the current structure. >>>>> If there are better ways to handle that, and others can provide some >>>>> options, that would be appreciated! >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> I would appreciate if anybody could share expertise on this. Though I >>>>> think I have read all the emails in the list, I might have >>>>> mis-understood some points. >>>>> >>>>> By the way, I think the indicator_uids should be added to the SCI >>>>> classes' >>>>> attributes so that they can be correlated with another information as >>>>> well. >>>>> >>>>> Thanks >>>>> Take >>>>> >>>>> >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Harrington, Christopher >>>>> Sent: Tuesday, February 05, 2013 4:25 AM >>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> I think some sort of group ID would do the trick. We also need a >>>>> logical and / or somewhere to show relationship between indicators. >>>>> If >>>>> I give you >>>>> 2 >>>>> registry keys do they both have to be present to be an indication of >>>>> compromise or is either one by themselves an indicator? Both would >>>>> have the same group ID since they are related. >>>>> >>>>> Thanks, >>>>> --Chris >>>>> >>>>> From: Stoecker, Paul >>>>> Sent: Sunday, February 03, 2013 8:26 PM >>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> What if we added indicator group ID along with the indicator_uid? >>>>> This would allow you to group indicators that are related into the >>>>> same group ID. >>>>> Would this resolve the issue? >>>>> >>>>> It is either that or going back to adding a Detection (or Indicators) >>>>> class that will should be used to take all of the indicators put them >>>>> into one place and have the ability to group the ones that go >>>>> together. I don't mean a place to put indicators that are missing >>>>> from IODEF.I mean a place in the IODEF document where you put the >>>>> indicators that are used for detection and prevention of the shared >>>>> Incident. I don't know the answer here, but there has got to be a >>>>> good way for indicators to be identified and being able to group them >>>>> as Chris has suggested without basically recreating something >>>>> complicated like STIX. >>>>> >>>>> Paul >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> >>>>> From: , Kathleen > >>>>> Date: Sunday, February 3, 2013 5:11 PM >>>>> To: "Harrington, Christopher" >, = MILE >>>>> IETF > >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis. >>>>> >>>>> The list has already said they would like to see indicators added to >>>>> the definitions in RFC5070-bis, to be more explicit about including >>>>> indicators and sets of indicators in IODE documents as opposed to >>>>> 'parts of an incident or the useful information on an incident for >>>>> sharing purposes. It was written before we used terms like >>>>> indicators. With that in mind, Rosella proposed a number of changes >>>>> back in July, both for guidance and for format updates. It may help >>>>> to have the first draft try to address at least some of these issues >>>>> so people can understand the problems and at least a proposed >>>>> solution. >>>>> >>>>> As you point out, we need to be able to show relationships between >>>>> sets of indicators, where we may have a few sets of indicators that >>>>> could have a relationship to each other within a document. In the >>>>> July presentation, one of the questions was to see if we should add >>>>> new category attribute values for the System class that would connect >>>>> the list of included indicators. I think we should still keep the >>>>> concept of a Node to a single node, but perhaps within System, list >>>>> multiple sets of Nodes that may be one type of attack. Rosella had >>>>> suggested pulling forward the "FraudType" from RFC5901, this would >>>>> help solve the issue as NodeRole values would compliment an >>>>> AttackType (FraudType values could be included in AttackType or some >>>>> broader term). It may be better to have the FraudTypes, plus >>>>> attribute values like "C2-server", "sinkhole", "MalwareDistribution" >>>>> for added context so you know what to do with the received set of >>>>> indicators. >>>>> >>>>> I am proposing that we change IODEF to include multiple sets of >>>>> indicators, add an AttackType attribute (or some other name), a >>>>> method to connect indicators and indicator sets within an IODEF using >>>>> an attribute of indicator_uid (or some other name) with a string >>>>> value to make the connection points, and add a few indicators that >>>>> are commonly shared into the base IODEF. >>>>> >>>>> Back in July, we talked about adding Registry Key/Value pairs and >>>>> hashes to the main IODEF document (trying to see if this will help >>>>> Chris below). What if we added the Registry Key/Value pairs as a >>>>> class off of RecordData, using a similar structure to what is in >>>>> RFC5901, and also added the ability to include hashes in RecordData? >>>>> I think if we then had the indicator_uid at the RecordData level, we >>>>> could connect a set within that structure and repeat the structure >>>>> for other sets in the same way we would do with Node inside of the >>>>> System class, using the indicator_uid to tie the set together. Then >>>>> at the more specific level for the hash, registry Key/value, IP, etc. >>>>> use an indicator_uid if we needed them marked at this level as well? >>>>> Maybe we want indicator_set at the higher level? I'd like some >>>>> opinions on this approach. +1 if you agree, suggestions if you have >>>>> other ideas that may work better. >>>>> >>>>> We'll also need to worry about marking the indicators to prevent >>>>> forward sharing when not permitted. We may want to use these values >>>>> or something else. >>>>> >>>>> Thank you! >>>>> Kathleen >>>>> >>>>> From: Harrington, Christopher >>>>> Sent: Friday, February 01, 2013 12:01 PM >>>>> To: Moriarty, Kathleen; MILE IETF >>>>> Subject: RE: [mile] IOCs >>>>> >>>>> I think we have a bigger relationship issue to address. Let use the >>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In >>>>> that message we could have groupings of indicators that we need to >>>>> show are >>>>> related: >>>>> >>>>> Two or more indicators of different type that relate to the same >>>>> threat: >>>>> The file hash of a malicious file and the URL of the C2 that >>>>> the file uses. Either or both may be present to indicate a >>>>> compromise. >>>>> >>>>> Two or more indicators of the same type that relate to the same >>>>> threat: >>>>> 2 different registry values for the same registry key. If >>>>> either value is present it is a compromise indicator but both will >>>>> not be present. >>>>> >>>>> The problem compounds itself very quickly. Consider the scenario >>>>> where both groupings above are part of the same threat. I need to >>>>> show that logical groupings of Indicators are related as well. We >>>>> can't send multiple IODEF messages for this from what I remember >>>>> reading. >>>>> >>>>> The last one I can think of would be when you have 2 different >>>>> indicators that represent the same indicator. It's not uncommon to >>>>> send both the >>>>> MD5 >>>>> and SHA1 hash of a malicious file. The indicator is the file but the >>>>> IOCs are the 2 hash values. How do we show they are related? If we >>>>> use a unique Inidcator ID for each hash value there needs to be a >>>>> higher level grouping. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Chris >>>>> >>>>> Christopher Harrington >>>>> Consulting Security Engineer >>>>> GSO - Critical Incident Response Center EMC - Where Information Lives >>>>> 174 Middlesex Turnpike >>>>> Bedford, MA 01730 >>>>> 781-515-5862 (work) >>>>> 603-583-1585 (cell) >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Friday, February 01, 2013 11:28 AM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> All - >>>>> >>>>> I'd like your input and will refocus the thread to get opinions from >>>>> the list on options to help solve the problems raised in my message >>>>> and additionally in Paul's message. >>>>> >>>>> Interesting point, C. Henry. Our objective here is to have machine >>>>> automated exchanges, so we rely on encryption rather than obfuscation >>>>> to achieve the necessary level of confidentiality. >>>>> >>>>> Paul mentioned the need to distinguish indicators of compromise from >>>>> context information that may also include IP address or other data >>>>> that could be indicators. The question I raised was on how to >>>>> connect sets of indicators in the same IODEF document, assuming the >>>>> ability to have watchlists that could have several sets of indicators >>>>> included, as well as to connect indicators that may be included in >>>>> embedded schemas. >>>>> >>>>> If we add an attribute on all of the relevant indicators, let's say >>>>> 'indicator-uid' how do we mark the indicators? Do we use this to >>>>> mark who sent the indicator as well so that we can prevent forward >>>>> sharing when it is not permitted or handle that separately? >>>>> >>>>> Then for indicators not included in the base schema that may not fit >>>>> into a category in the SCI draft, do we create a place for these off >>>>> of SCI or right off of the IODE schema in EventData? (more details on >>>>> this in my first message). >>>>> >>>>> Comments and questions encouraged to figure out the right technical >>>>> solution to have this machine automatable. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of C. >>>>> Henry Adams & BIE >>>>> Sent: Monday, January 28, 2013 11:25 PM >>>>> To: MILE IETF >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Temporal Dependency sounds interesting. I remember when I first ran >>>>> across this particular craft, an experienced colleague asked me a >>>>> peculiar question. He said, " How do you stop someone from tracking >>>>> the IP Address to your computer?" >>>>> >>>>> I replied, "I don't know, how?" >>>>> >>>>> Then he said, "Cut the dog-gone thing off and the modem that it is >>>>> connected- which is constantly on!" LOL >>>>> >>>>> Here's my point (Hypothetical Situation) : There is a 1st Responder >>>>> searching a Neighborhood for Survivors which were hit by a Disaster >>>>> or let's just say "Live" Terrorist Situation. He /or She needs to >>>>> communication back to other Officials that he /or somehow is in >>>>> Danger. The device used to communicate has been captured by the >>>>> great minds of the enemy. It's only a matter of time before they >>>>> utilize reverse engineering to figure out how it functions. However, >>>>> their pride comes before a fall when seeking the location of other >>>>> similar devices to attack. Why? Perhaps the less thought of concepts >>>>> that makes the device function properly, saves the day by disguise or >>>>> cutting it off (figuratively speaking). >>>>> >>>>> Just a visionary thought. >>>>> >>>>> C. Henry Adams >>>>> chenryadams@biemediagroup.com >>>>> http://biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Mon, 1/28/13, Dave Misell > wrote: >>>>> >>>>> From: Dave Misell > >>>>> Subject: Re: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" > >>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with >>>>> DNS SEC a pemanent and temporal key, with a temporal Id? >>>>> >>>>> Yours Faithfully, >>>>> >>>>> Dave Misell MSc CISSP >>>>> SilentCircle dsm >>>>> 07710 380044 >>>>> david.misell@bcs.org >>>>> >>>>> >>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE >>>>> > >>>>> wrote: >>>>> >>>>> Serialization of a particular Lists of XML Classes in a unique way >>>>> was closely related to what I attempted to express when I stated, >>>>> "consider to a degree what appears to be illogical in brilliant minds >>>>> in some instances." >>>>> >>>>> However, I see Dr. Stoecker's point a little clearer. However, it >>>>> would be nice if the UID was in some way disguised from those who >>>>> study this Security Art Form in a negative way. >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> Re: [mile] IOCs >>>>> >>>>> Sunday, January 27, 2013 8:52 PM >>>>> From: >>>>> "Stoecker, Paul" > >>>>> To: >>>>> "mile@ietf.org" > >>>>> I would like to look at this from a slightly different >>>>> perspectiveSlet's say I get an XML document that tells me about an >>>>> incident. This document has source IP and destination IP that is >>>>> being shared. However, what I don't know is which IP address is my >>>>> indicator and which is just a contextual piece of information. This >>>>> means that my detection product isn't going to know which one to use >>>>> either, because there is nothing to tell me which IP is the one, even >>>>> if the roles are set it still might not be enough to tell my system >>>>> which one I should use as the indicator. >>>>> >>>>> If we had something like indicator_id as an attribute, it would allow >>>>> us to easily identify indicators from contextual data. I do admit to >>>>> being biased as I have spent much of my career working on the >>>>> monitoring and detection side of these things, so I am just thinking >>>>> of ways to make it very clear what the indicators are in the XML >>>>> document and the other data that may be important as I investigate >>>>> activity that I have detected off of those indicators. >>>>> >>>>> >>>>> I did suggest the detection class, but I think we may get more >>>>> flexibility with the indicator_uid. One thing that I haven't >>>>> considered is the UID portion of thisShow do we use that UID? How is >>>>> the UID created? Are there standards for UIDs? >>>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> Paul W. Stoecker, Ph.D. >>>>> SMC Lead Content Architect >>>>> RSA, The Security Division of EMC >>>>> cell: 302.379.3375 | e: paul.stoecker@rsa.com >>>>> >>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE > >>>>> wrote: >>>>> >>>>> From: C. Henry Adams & BIE > >>>>> Subject: RE: [mile] IOCs >>>>> To: "KathleenMoriarty" > >>>>> Cc: mile@ietf.org >>>>> Date: Saturday, January 26, 2013, 6:17 PM >>>>> >>>>> Greetings Kathleen, >>>>> >>>>> Your logic stimulates my visionary brain because I'm amazed at the >>>>> many avenues you review with this approach at once. However, could >>>>> you share a few advantages and disadvantages to the latter? >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ---------------------------------------------- >>>>> "we could continue to group items in logical places as is done now in >>>>> IODEF and then have the extension point for combined indicators via >>>>> SCI." >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> --------------------------------------------- >>>>> >>>>> You pointed out what you consider to be logical places, but if I >>>>> wanted to protect information from parties capable of ascertaining it >>>>> from your logical places, perhaps we should also consider to a degree >>>>> what appears to be illogical in brilliant minds in some instances. >>>>> >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> >>>>> --- On Sat, 1/26/13, Moriarty, Kathleen > >>>>> wrote: >>>>> >>>>> From: Moriarty, Kathleen > >>>>> Subject: RE: [mile] IOCs >>>>> To: "C. Henry Adams & BIE" >, "mile@ietf.org" >>>>> > >>>>> Date: Saturday, January 26, 2013, 10:13 AM >>>>> >>>>> Hello C. Henry & others, >>>>> >>>>> Thanks for taking a look at this. We have a few considerations in >>>>> this email thread I would like to hear thoughts on (and there may be >>>>> more once RFC5070-bis is actively edited). >>>>> >>>>> The AdditionalData class and the RecordItem class both allow for >>>>> non-XML extensions. Where you place the extensions should be >>>>> specific to the logical grouping of the parent elements so you can >>>>> understand more about the included data in most cases. >>>>> >>>>> The Impact class can be used to provide context information on the >>>>> included data of the report and also can include a confidence rating >>>>> on the report as a whole. Extensions related to impact would be one >>>>> level higher (at the moment) in the Assessment class using the >>>>> AdditionalData extension point. >>>>> >>>>> Take asked about including vulnerability information, I would think >>>>> that would fit under the Vulnerability extension point of the SCI >>>>> draft in the Method class. He did ask about non-XML. RecordItem or >>>>> AdditionalData do allow for non-XML extension points, we could either >>>>> have the SCI draft handle these as well or have the extensions that >>>>> are non-XML come directly off the AdditionalData or RecordItem >>>>> classes according to what makes sense from a logical standpoint. >>>>> >>>>> As for my question, it was two-fold. >>>>> >>>>> Indicator based schemas have a reference number or a GUID for the >>>>> various indicators they share. If we are extending to embed other >>>>> schemas that include such reference or GUID identifiers, do we want >>>>> to add an attribute to the various elements in IODEF that could be >>>>> indicators? Is this enough to make the connections or is something >>>>> else else needed? We could add something like an Indicator_ID in >>>>> RFC5070-bis which would then correlate to the reference or GUID >>>>> identifiers. >>>>> >>>>> Then the other question was on how to include indicators that are not >>>>> in the base schema that may be related or have language with "and" >>>>> "or" >>>>> to >>>>> specify the relationships. In some cases, you will want to group >>>>> these indictors in one extension point, where they may fit logically >>>>> in multiple places if the relationships did not need to be shown in >>>>> the data format. If we have cases like this where you need more >>>>> complex representations, should we use one extension point via the >>>>> SCI draft off of the EventData class AdditionalData extension point? >>>>> Opinions are needed here.... >>>>> >>>>> A few people have mentioned wanting to include some commonly shared >>>>> indictors into the base IODEF document. We could have a catch-all >>>>> class that does this and has an extension point off of it in >>>>> EventData or we could continue to group items in logical places as is >>>>> done now in IODEF and then have the extension point for combined >>>>> indicators via SCI. I think I like the latter approach. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. >>>>> Henry >>>>> Adams & BIE [chatlga2000@yahoo.com] >>>>> Sent: Saturday, January 26, 2013 3:05 AM >>>>> To: mile@ietf.org >>>>> Cc: C. Henry Adams >>>>> Subject: Re: [mile] IOCs >>>>> >>>>> Greetings Everyone, >>>>> >>>>> Take mentioned two types of indicators based on the : >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> 1) If the indicators are something like an XML-based alert/warning of >>>>> information leakage, it could be an event that are conveyed in the >>>>> SCI's EventReport class, IMHO. >>>>> >>>>> 2) If the indicators are something like an non-XML ones, I guess it >>>>> could be conveyed without using SCI draft. >>>>> For instance, we could use Impact class of the base IODEF to convey >>>>> the indicators. >>>>> We could for instance extend the list of indicators of the Impact >>>>> class, if needed. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> -------------------------- >>>>> >>>>> In doing so he pointed out the "Impact Class" >>>>> >>>>> Whereas, Kathleen stated, >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------- >>>>> For the discussion below, I was thinking more of combined set with >>>>> relationships that may be included in a single extension point, so >>>>> that's why I was thinking about the EventData class, but there may be >>>>> better locations or a specific area within the EventData. >>>>> >>>>> Paul Stoecker had suggested a "Detection" class as a consideration. >>>>> -------------------------------------------------------------------- >>>>> -------- >>>>> ------------------------ >>>>> >>>>> Kathleen thoughts related yet still with other indicators and the >>>>> EventData Class. >>>>> >>>>> Is there a possible way to create a new XML class which encompass >>>>> combining the EventData, Detection and base IODEF classes to simplify >>>>> this issue? >>>>> >>>>> >>>>> C. Henry Adams >>>>> chatlga2000@yahoo.com (Direct Email) >>>>> chenryadams@biemediagroup.com >>>>> >>>>> >>>>> The information contained herein is for the exclusive use of the >>>>> original recipient. This information is granted for limited >>>>> distribution within the recipient's place of business for planning >>>>> purposes only. Further dissemination, whether private or public is >>>>> prohibited. >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From kathleen.moriarty@emc.com Tue Feb 19 23:57:54 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8121F89B5 for ; Tue, 19 Feb 2013 23:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=1.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6PzOHf3S8rL for ; Tue, 19 Feb 2013 23:57:53 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7774221F8AE7 for ; Tue, 19 Feb 2013 23:57:53 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1K7vpXw006785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 02:57:51 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 20 Feb 2013 02:57:35 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1K7vZQl018291 for ; Wed, 20 Feb 2013 02:57:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Wed, 20 Feb 2013 02:57:34 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Wed, 20 Feb 2013 02:57:33 -0500 Thread-Topic: Mail fields Thread-Index: AQHODz/wwgzXX1a4vku3k5RaTnMVYA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Mail fields X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:57:54 -0000 Hi, In looking at the updated rfc5070bis and coming across some requests for ha= ndling certain types of exchanges, I am curious to hear how others think we= should handle mail related indicators and incidents. A couple of commonly= exchanged fields were added into the Record class. You can still extend o= ut using RFC5901 and include a full mail message, but if you wanted to incl= ude DKIM or Sender Policy Framework, you need something else. The IETF gro= up MARF already solved these issues. MARF uses the email tags rather than XML and there was a draft that embedde= d MARF content into IODEF (contains an example), can be found here: http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00 Since mail is already marked and can be parsed, would this be a better opti= on to use what MARF has already done to solve the question on how to exchan= ge this data? Other options would be to update RFC5901 or to extend IODEF = further. I prefer the use of MARF. It is already in use by mail operators= , so there is adoption. Thanks, Kathleen= From Christopher.Harrington@emc.com Wed Feb 20 11:57:34 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C121E8037 for ; Wed, 20 Feb 2013 11:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUhwAqbFxPY1 for ; Wed, 20 Feb 2013 11:57:33 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE921E8030 for ; Wed, 20 Feb 2013 11:57:33 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1KJvSig011310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 14:57:31 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 20 Feb 2013 14:57:19 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1KJvHLY009693 for ; Wed, 20 Feb 2013 14:57:18 -0500 Received: from mx36a.corp.emc.com ([169.254.1.8]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Wed, 20 Feb 2013 14:57:16 -0500 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , "mile@ietf.org" Date: Wed, 20 Feb 2013 14:57:16 -0500 Thread-Topic: Mail fields Thread-Index: AQHODz/wwgzXX1a4vku3k5RaTnMVYJiDKKoA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_032D_01CE0F7A.92BA4230" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Mail fields X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:57:34 -0000 ------=_NextPart_000_032D_01CE0F7A.92BA4230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm for the simplest solution as always. These are the indicator types that we routinely share. I would use these as a base: Email address (denoting if it is to or from) Email Subject Email attachment name Email attachment hash X-Mailer (from header) Hyperlink in email It's also very common to share the whole header. Bad guys routinely forge them and put extra header items that can be used as indicators. Although not an indicator sharing the entire email as an .eml or .msg file is also pretty common. Thanks, --Chris -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, February 20, 2013 2:58 AM To: mile@ietf.org Subject: [mile] Mail fields Hi, In looking at the updated rfc5070bis and coming across some requests for handling certain types of exchanges, I am curious to hear how others think we should handle mail related indicators and incidents. A couple of commonly exchanged fields were added into the Record class. You can still extend out using RFC5901 and include a full mail message, but if you wanted to include DKIM or Sender Policy Framework, you need something else. The IETF group MARF already solved these issues. MARF uses the email tags rather than XML and there was a draft that embedded MARF content into IODEF (contains an example), can be found here: http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00 Since mail is already marked and can be parsed, would this be a better option to use what MARF has already done to solve the question on how to exchange this data? Other options would be to update RFC5901 or to extend IODEF further. I prefer the use of MARF. It is already in use by mail operators, so there is adoption. Thanks, Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_032D_01CE0F7A.92BA4230 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY1zCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxDCCBKygAwIBAgIQXT90N24i2xwadZVlhXZ+sTANBgkqhkiG9w0B AQUFADCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEDAOBgNVBAcTB0Jl ZGZvcmQxGTAXBgNVBAoTEFJTQSBTZWN1cml0eSBMTEMxJTAjBgNVBAsTHEdsb2JhbCBTZWN1cml0 eSBPcmdhbml6YXRpb24xIzAhBgNVBAMTGlJTQSBDbGFzcyAyIFBlcnNvbmFsIENBIHYyMB4XDTEx MDcxNDE1MjgwOVoXDTEzMDcxNDE1MjgwOVowge8xEzARBgoJkiaJk/IsZAEZFgNjb20xEzARBgoJ kiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMIQW1lcmlj YXMxHDAaBgNVBAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxDzANBgNVBAUTBjEyMjc2NTEXMBUGCgmS JomT8ixkAQETB2hhcnJpYzgxHzAdBgNVBAMTFkNocmlzdG9waGVyIEhhcnJpbmd0b24xLTArBgkq hkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM0b9ETHWlRPJX2CZ5RSGjNkOgRYHwcmeBtNlGTBqVIGlFQUywADy67n 3XoOGuxzpvS9I2I5mcM+dFXfO7YIG6bYJk2igTfckR3HZVhH1WLIu5tk8De9VA30+vtSgDqw/GrF VOVV+DR5qrFqZ5Iumn3QnGiRjdcOU9NRpBBR2vZWVnIiB9jxn+o5hIXFfWwieLDyW96Hph25fZql Ww7rVVLSIDcSKK54MQkYmKhM7sUtczDFMY/2aUBMAYNdp5Sp9U7ZpPXPIOmZzR2QTrWbON6u6cNi 3bvsPkyZz3AXhpDjJFKb+EkR92mwpoTsuez113B4GEY5bVgmcfVuw2L3wPECAwEAAaOCAakwggGl MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwSgYD VR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8GCisGAQQBgjcUAgOgEQwP aGFycmljOEBlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJzb25hbENBdjIuY3JsMB0GA1UdDgQW BBRW1M3IzplvKoMlZigKQPkAVmvlTjANBgkqhkiG9w0BAQUFAAOCAQEAkX75qUhpAq/WngSOqN/f ykF7EyOqwrlNPjV/Ev4QwLKA+9JlouET4byWIxr66IRSV7YOu+zNdFfToGQ/8WKWjVBnrXunxe8k 97BRDr5TBdNdIYYpv4bUOkTHZchB1s4d/e4N3kP18W1xuC0i6bNfHpkAikOGIVvJ5Fi8gnZEDDeL IlK2T6udJFzg0DkBzg1AVt0DQ3cHxYIBowMAbWmqdgzsItbdd6kKjgEPdpf1YFXlV+e/N2oArHTN 6dTLP8K3jJMFHXrPxp4qA68O/wHKaR3qgfidIzB6XjomaQCchY6oCWRMrufqcZ/HDAq7z7vru+x4 tGE+yUqYqEkBgVnxaTCCBdQwggS8oAMCAQICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcNAQEF BQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRm b3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkg T3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0xMTA3 MTQxNTI4MTRaFw0xMzA3MTQxNTI1MDZaMIHzMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZIm iZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJpY2Fz MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJkiaJ k/IsZAEBEwdoYXJyaWM4MSMwIQYDVQQDExpDaHJpc3RvcGhlciBIYXJyaW5ndG9uLUVuYzEtMCsG CSqGSIb3DQEJARYeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtfexCM/OPHjt2B8L4hCnKUtcvGW7hhku6OYtYx1z4mfTGXbjP9bP nv5L+4A3lCxuOQhUKfLdXVfikrGhxlFx9f6VRq16wD6WUa5XJIkThry88uFZwG6G1w3LvP34ijNL vV+O1ZuNU6e+Hq/CRQm+TyEIbu7K1rDWyKxdOg9K52BYfaOn6GfBNnNch9p2q9EhBlpoab152mt3 +ncNv7TFkuWws8MOs4VV1CU5rWB+VSBGPeVJo9mX8+RkKTjHSlRLibNPwt8+Pj0ZKvJuwFL5K0MX fKST19kNbXjJBfWF7yH7WLmvfJWJT0oUEhkQWEOGW3ibhgy3e78r4wQZnk5A2QIDAQABo4IBtTCC AbEwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgME MB8GA1UdIwQYMBaAFBQw62v19Em1aFJ1ptu9rlvIrH1MMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3 DQUHBTB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQG CCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5 IHJlZmVyZW5jZTBKBgNVHREEQzBBgR5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb22gHwYK KwYBBAGCNxQCA6ARDA9oYXJyaWM4QGVtYy5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4EFgQU 5LsToi39CUKQ1y41KI1Xba78JFcwDgYDVR0PAQH/BAQDAgM4MA0GCSqGSIb3DQEBBQUAA4IBAQCe ryMDShgtoiUuMsRE+QGJOKY6qVOrZ9SDGnzxoIAZ9HE0Mw8mZdFccRKZOIDvR/9JMUgIMF//JRTD Eml7e6XYd8tDAqd9tr1VI/ukJ/pUnMJ/uDMY6azQH43cOVjdiaebQNWmZmYTDzvV+gvlpDPd8Sod HAc7ZOyfDe9ofyP/e8YPhkwn6TGrK9598bqSm7MNQIjN1y6Jzrk1TdbmyD76jgxUvLdTI8gz6aW1 wYoEeVB1r1BXhN9tVxbsh5FjUBy654jp5BT/f+6JcA7Q6UncdRtwNu6wrxoj5wgzWGpVmBBkomoI fRcNDadTU4wCwdG/mXSPdJaCqfPifbfQUGnRMYIEejCCBHYCAQEwgbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQXT90N24i2xwadZVlhXZ+sTAJBgUrDgMC GgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMjAx OTU3MTZaMCMGCSqGSIb3DQEJBDEWBBQYbd+eS5pEEn9R384qNZRCXptQzTCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBxAYJKwYBBAGC NxAEMYG2MIGzMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UE BxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNl Y3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIC EEBVs4BiURueYjjhnbUS+bkwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNl Y3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEGA1UE AxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEEBVs4BiURueYjjhnbUS+bkwDQYJKoZIhvcN AQEBBQAEggEAdsA4hvj6EJhD9Hgn+41cAh/bR1M4Cg8DJxSoO8rITxAXh59Ehopo4uGE9Sn4H94E pvhGU7ICG/RP63G8E9tSkaYC/ADHaDMSrPF9BkRAY0SH/d9xP1/Qz81mdbCTMvba1qsM7/0lAvEn lxGHFvh1lUyCdhzeQzT9BQbqKefGhAQpIRcjHNhsTiq4+DrXULqPT8hZHoufQPZvUz6vNJ/u9UoG 9Y3QvIHN5jCv7uPLe5HGtjnKx7dO+VybtZzPxZ+TH/Fb8L3ZLT3K8yDTyo1Q75eh4+xcWRcd4Edn u57RDgL4ESwUEnC+TUg97U/BOrzpuxV+QspTcJVJ/4i376NdpQAAAAAAAA== ------=_NextPart_000_032D_01CE0F7A.92BA4230-- From kathleen.moriarty@emc.com Thu Feb 21 02:19:28 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF621F8E50; Thu, 21 Feb 2013 02:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnlFKt3GgrLl; Thu, 21 Feb 2013 02:19:28 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EDBEB21F8E4A; Thu, 21 Feb 2013 02:19:27 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1LAJQru011582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 05:19:26 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 21 Feb 2013 05:19:12 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1LAJCCA004696; Thu, 21 Feb 2013 05:19:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 21 Feb 2013 05:19:11 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" , "marf@ietf.org" Date: Thu, 21 Feb 2013 05:19:11 -0500 Thread-Topic: Including Mail fields in IODEF Thread-Index: AQHOEBvuagQSHFBhb0e+qysbcbjrmQ== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Including Mail fields in IODEF X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:19:28 -0000 Hello, Cross posting with MAIL and MARF -=20 In MILE related work, I have come across use cases that would like to inclu= de DKIM and SPF information in addition to specific mail fields (like the o= nes Chris lists below). We would like some help to figure out the best app= roach. Should we embed ARF and MARF RFC extensions to accommodate this nee= d or should we look at updating RFC5901? Both take the approach of includi= ng an email message as opposed to using XML to tag each field and allow for= this in the data model (in my opinion, that is fine and reduces bloat, but= there may be other opinions). There was a draft published last year (link included below) that includes M= ARF in an IODE extension. Thanks, Kathleen ________________________________________ From: Harrington, Christopher Sent: Wednesday, February 20, 2013 2:57 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: Mail fields I'm for the simplest solution as always. These are the indicator types that we routinely share. I would use these as a base: Email address (denoting if it is to or from) Email Subject Email attachment name Email attachment hash X-Mailer (from header) Hyperlink in email It's also very common to share the whole header. Bad guys routinely forge them and put extra header items that can be used as indicators. Although not an indicator sharing the entire email as an .eml or .msg file is also pretty common. Thanks, --Chris -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, February 20, 2013 2:58 AM To: mile@ietf.org Subject: [mile] Mail fields Hi, In looking at the updated rfc5070bis and coming across some requests for handling certain types of exchanges, I am curious to hear how others think we should handle mail related indicators and incidents. A couple of commonly exchanged fields were added into the Record class. You can still extend out using RFC5901 and include a full mail message, but if you wanted to include DKIM or Sender Policy Framework, you need something else. The IETF group MARF already solved these issues. MARF uses the email tags rather than XML and there was a draft that embedde= d MARF content into IODEF (contains an example), can be found here: http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00 Since mail is already marked and can be parsed, would this be a better option to use what MARF has already done to solve the question on how to exchange this data? Other options would be to update RFC5901 or to extend IODEF further. I prefer the use of MARF. It is already in use by mail operators, so there is adoption. Thanks, Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Sat Feb 23 07:03:29 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3719B21F8917 for ; Sat, 23 Feb 2013 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7yy9tMEkgjp for ; Sat, 23 Feb 2013 07:03:29 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6323621F8C75 for ; Sat, 23 Feb 2013 07:03:24 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1NF3IHf012036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2013 10:03:22 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 23 Feb 2013 10:03:00 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1NF2xf8022326; Sat, 23 Feb 2013 10:03:00 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Sat, 23 Feb 2013 10:02:58 -0500 From: "Moriarty, Kathleen" To: MILE IETF , "tony@yaanatech.com" Date: Sat, 23 Feb 2013 10:02:54 -0500 Thread-Topic: [sacm] SACM parallel universes Thread-Index: Ac4R0ePme9CU32bfQvKIlpVqLhKC0QABMHNg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_F5063677821E3B4F81ACFB7905573F24D625C2F1MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] FW: [sacm] SACM parallel universes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 15:03:29 -0000 --_003_F5063677821E3B4F81ACFB7905573F24D625C2F1MX15Acorpemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91LCBUb255ISAgVGhlIHdvcmsgaXMgYWN0dWFsbHkgYWxpZ25lZCB3aXRoIE1JTEUg YW5kIHJlZmVyZW5jZXMgc2V2ZXJhbCBvZiBvdXIgZG9jdW1lbnRzIGluIGFkZGl0aW9uIHRvIG90 aGVyIHN0YW5kYXJkcyB0aGF0IGFyZSByZWxhdGVkIGluIElTTyBhbmQgTklTVC4gIEkgcmVhY2hl ZCBvdXQgdG8gdGhlIGF1dGhvciBvbiB0aGUgc2xpZGVzLg0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRo bGVlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2FjbS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9ueSBS dXRrb3dza2kNClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyMywgMjAxMyA5OjI2IEFNDQpUbzog TW9yaWFydHksIEthdGhsZWVuDQpDYzogc2FjbUBpZXRmLm9yZzsgV2FsdGVybWlyZSwgRGF2aWQN ClN1YmplY3Q6IFtzYWNtXSBTQUNNIHBhcmFsbGVsIHVuaXZlcnNlcw0KDQpLYXRobGVlbiwNCg0K T25lIG9mIHRoZSBzZWNvbmRhcnkgYmVuZWZpdHMgb2YgdGhlDQpTQUNNIHdvcmsgaW4gdGhlIElF VEYgaXMgcG90ZW50aWFsDQpjb252ZXJnZW5jZSBvZiBwYXJhbGxlbCBTQUNNIGxpa2UNCnVuaXZl cnNlcy4gIEF0IHRoZSBFVFNJIGFubnVhbA0Kc2VjdXJpdHkgd29ya3Nob3AgYSBmZXcgd2Vla3MN CmFnbywgdGhlIGF0dGFjaGVkIHByZXNlbnRhdGlvbg0Kc3VnZ2VzdGVkIHRoYXQgdGhlcmUgd2Fz IGEgU0FDTQ0KbGlrZSBlZmZvcnQgZXh0YW50IGluIEZyYW5jZSBhbmQgSXRhbHkNCnRoYXQgY291 bGQgdXNlZnVsbHkgYmVuZWZpdCBmb3IgYmVpbmcNCnBhcnQgb2YgdGhlIFNBQ00gd29yay4NCg0K SXQgbWlnaHQgYmUgdXNlZnVsIHRvIGtlZXAgdGhpcyBhZGRpdGlvbmFsDQpiZW5lZml0IGluIG1p bmQgYXMgdGhlIGdyb3VwL3dvcmsgcHJvY2VlZHMuDQoNCi0tdG9ueQ0K --_003_F5063677821E3B4F81ACFB7905573F24D625C2F1MX15Acorpemccom_ Content-Type: application/pdf; name="ISI_ISG_DELUTIIS.pdf" Content-Description: ISI_ISG_DELUTIIS.pdf Content-Disposition: attachment; filename="ISI_ISG_DELUTIIS.pdf"; size=409298; creation-date="Sat, 23 Feb 2013 14:27:20 GMT"; modification-date="Sat, 23 Feb 2013 14:27:20 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVWW48VRRAOwooMhNsud5Dx8jBDctqu6q6+vBqNiW+QTXwQn1DQhMXs+v8T v+qZc6YGziLuZDN1uqvr8tVXXXPae0fce322wquT7rsXuX/zT3faca29/p80KQXv+7cdi/iVrHtv uz+7X/p33SksJI+9TRRP+BELXtBwtabJdul/+Lt7jmeyHzxv7XMtO/tGVg1rX2qVtX1oLParsT+H 1zZPVpHj3FreqjVPz+CKen3O3kD4q9vubt/wPid69kf3+tnsLe7gUvEjnvbhFbHc8vHn46VmZ8Ca hwmlyYORz0HMeNiPWCNC/+KnWUDup11xQf/agpVfnfTfH+MwAf7UH7/GGeo3rSRJXIk9eXIZOyfd r8OFkcCvFIbPIOQSigwXx413KWdfwnBJZZ+EfOThYEzO58i8Xrb6n4/eSfQhCbSxLJV9pP36peb3 7U8nYiwro5dHghKF4QtYD1Q9DVfauSiSuQ4v302/YpZKRunqSOwoSNxpTPrXxg3BKfHw8mykiPxz wjFq54bLy/Z1mKrB1wp/EpJL/Nvxz92Px1oQF2JG0VYvrc++9U8tF2LxcV2xytr+JbsSwJRWshua SyleEPWBphgQ4E2ESinVEIdbGn+JwGO4PW7YsQBrK+4OHeoaip54OBqzS5ViBtqb4HLMyVi/3lym UApbT7v9K4vLxdAdMEo4x2gdCpgXAlAeo8u1BgHwCAK0IrFmtGKkSUercBXnwae2nVwGcZJN4mAM BftaYM21lmxNYtcV4eFuoxblJDLcw5rEjFzu2xQ0WxGUHB6BhnhJhPMMOsQ0PFDz5LPYbG+OlB1D zZ423ucwScJKA0arizXYLOfcLQ5N3mVvDRyOykmuiAN8Of4dBDGIXFuqbmJ5CPB9kIbY7N5U/dF+ JHbp/z+qTZibkB6PxbH3iVesevJRp1T+k4JfKtu0KBbJ/env5//i9LHKIaovm6GhgrE7AxdiNWTa eVj48XQkcsl/QJAtjVdtNyNti28bdNs65wVtbJlIr09MwV2S4pYq6/awzaMnDD5GvLW/VIdjqMVV TuoF11no2c/X2UYyucAYdMHFOHm+MLI4gUFMHr2bA4YfALuot3fNKeqQIaCQudjFAyQvlIOOGoQh gb1eJpgbwkDX7ONCdxxLnEuPICFOgyAkDV/nw+xgka5BKpVym0bZRcm16JjQjk9JMlDEleyr0OyV CDgsoZpQboAOqdSySurmyC4iZsUbUUUUvwJRD0+JqM2yxpP8Hi6X9sS6Urg9hSh6T21SRCniXECK IN0q8aMFkAWvO63CIWVCjmjRxDnrXanRCK2CXA6Z/VXmSqFacFUZ7O+NSgJ8P5gUVmHd12NRgqag JBLGz7Kl6gPwy2mbGTQXkw8VNjCeTAVNmubMo1HAvFDJzHIJ1SeM4w+ENtHP3f20uR768v5Y134o fc6OZDvVH2uwIRZuncj6ORO1JhG9qJji/hPHQT/V7mp7MyGFqRfRqtw6I7ma8FH1pA04TjnqtbjI T41sdXo1wqU2UiZFDyz6Sp0AUNaPNMG8RKhGUvYqXUjrKloXDm1ATdtfg4Ouer2sj9AG3uNCmYZ2 8pwDioRFCdI+RgADVWPmss45ptaNW7VlbdH7RocL+iuZ3W8/qO7z7l+Of3vgZW5kc3RyZWFtCmVu ZG9iago2IDAgb2JqCjEyMzEKZW5kb2JqCjE4IDAgb2JqCjw8L0xlbmd0aCAxOSAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO2dCVxTV973E8ImICDWgqImriQi4e7L1BJta10fHS2t taWC4jK2KIJ9XIFol7FaX2lrrW11xNqZcWx9iss4arXEpXVDxdEqWhRUlrCHJGS9Wd5zw5KLhrb0 fdOB5NHPR8+9Z/v/zvnfc0/u/eafDBEkhRERxP5tS6QuCYqfSYoWLQ/KCEJoWkrThKjt/yXtZwgU gkRpQQiOQx3SbflpQX8KmiVaGpQBWiQgkB+HIDgJDkApsr2Uoy8EEj2XHjQD/GVtgCEaA8YgFEaz BkkxioJQUjRzws/lZi4CxlJSlP3jEMFNpy4RPZMI+oFREUJKQa+JC4MgESyKg0EmDUlxmsZFBC6F UPB/4pKgV8UjJLAUgjGEEkeBFE0jNCYeCVIkhWOkOEASByygcYzCxJESCOSjKCjqJ4mDpSiN4rTY H5TFIchRlgLGUggsjpEghBSBcKqtPkYT4iRxe6shoCUcx1EM7tABaBWXEqAEJvZhOyAoFJzl1Bve ngJFwaiSJLDlSdAYguEwRYn7sLUQAicJcT+2XRqMGEWLkySs5RCKwATX8hAJjEoxFAIFlrJJiETw to4RknbdMSc/kq1EEaADZ3awBJFCCIZS4lESmAQTQ8KgCgF6b+kGzCtN0KBKS0EE2C9gLQWDgWCO McIRHNgHv5Y4OWh8IvCTjCCYoIBf4USrVzoOSYpqdT2YguHHDhGEe9hW1+Gno1odFaNEcazPgOZo EUHjbT76zKSg+GdfiJ854Zmg+FkgNyh+oggOin/mj8+KqKD45+OfTwuKf+6PY8bE/zFzwfzFqW+m Z4pgHFRJT/vvJUuXOyqAdHrmchGakBA06TnRqp2pFptS9cWwYpV1/kO7vab87UJhgW1hSoqRMZw3 5MnXb04vG5s0d1zo89Ic0bOJicG8gLiokKDxk0QzHJaCa6jVUhoBliKdWEp31VL6cUv5f+D9YOf/ /dgFbdgAo1nl36RV1TYHDBtRfuQvIRHRumZ1cEhYVV3jgH4RPB7v3zdu9YuKUuqYgc8nqpp0Q3rx tpwa+NBpN0G32w2uOYpwbTeCdtFutsJjdj/PO27nFxaVXK5lfHr5GgUBwSbdj0f+OgCfrAl7YsTA 8Ds/XCm/dqnvk5FVFaXhUUOB9RZ9Q111dXj4E+FTXlQ+bNA0G8HJBU+LvmWGTHVqINu9hKaABqgT DV31EsSFl/Cn8w7Y+e/tLgB29LZW94keqjZZwgJ8C08XRMZQQym0yay365jTX/+PQN8UN3b8nZt3 q6pLQeEBUUNv3ftpRPQQzQDhoOEDrE3GWo2uj59/4YOqexUxrzjFUFirGBICFwVJdiKG6qoYyoXL p+347tk/bt7AD0lAl2ttVnPzpfGL+05Y/fQPxekJm5YfVL18zKKVS3fv/9uXdyqDj5bK5L3nT5kU NGatbdzFM74Xcsy5nz3QKgxlssEnrD9N3aXSNMziLZGOQJ1iaKhdDAbEYK7FoFAXxbAVHhNT//KB 6c9NexgfEyYQnD37/nY/e04Os3X2D4VTNuXVFJ5PHmNJizV/krVw/gKeoNSuUGWtMagF0e/EDrug rbBGBmfTcPCNKcW7gpdZGJO2+GBJPv63KOEYYyhvJRrDlYS2SyJ/RhLcVUmwC2ebw/vCzt9x+QGP 3+vB9VvAi8L01SpBb3zahNoHVQJD88mL11Qan4jwsIfKRp7jT0gvQUWp8sXZ40FarWWqq6qvX72d sX6hrqH+xyp1VY0hPNBW16ApKlXRg8yni+vWNKImjra2xYCEwcpAwp1o6+pigLpaDObzdtj5f95x rO/oUXfvVQY1VAGLm6yCwVDcwzJlc01NxcPGiCEDqTGj9h260GT2Abkmk0mg5732GjFvHLs23G3Q BQf65O77kYIHGQwg0/qTUqusNfUPVl+53dygVo8bEaS3WkpiiBVOhTCEt0tERQRBdSIR76pE3IVH jsm26b8hZd/7mkrLVl/m+SuFOf4f5RXI+0b0UTBGSe4HYxceW6z+flj4HVnxnNsboq5Mxi4nr/S/ 8OKHETO29RmzRv/FybeqN6Qrjs3uny+zWWxni6erEjYGW06Ymu4U5Savv/T6nnv89/dAU13rI9ys j/86b5udn5V3atCwAbdKansH+GtNZjAx/gGCJj0vMkjwoMlco9M16+z1D+stfUJBlqFWF4sKv1hG nLxZ/cXRB+DMh+noXaU+Ilhwv9qgMVv8zTajxVheq1M2qrSapvpa5mZFhSjcT9PUuDUswcYRCrYM bULB1oDoZGuAkl0VSrqYyJ1HNMYvyy6HhITkyW3z5pUX2KuCBVEW23nxD4VZhrOyaVX2sdLYG/Yp uaVTmg7BCKrat2KNxa78boJsUdq3Ph9r/vnBonnW/K+HL7ObDMn2qDk5lks2u2pbgLDUYrSYf4gd cq6sWHiSMZo2bOJ9+c0WhDeglvyHS7EI4max/GW8XDt/4aeHB0QNuVfRNKx/8D2lzuIbAOZKozOF BgcYDMb7ais4tBtMdQxv8YwR7++6NlQY8VxcWIwwYjISPeil/wG5JNw/d3F8dZNRrWNMdkGTRu9j MWo0tjJlRZVaz9c3GzSakkpdsK+xlw9TfXKML1cu2S4XbEqITjZTaFc3U6irzdQK3kY7/+DJG8eV JobxNVotvQN5NWp7y3KqNjNh/n41zSar1Wa22ht15qjQgJWzY1569xKjZ+JjIt6dO+ofZ8v3brsO Cn93aKbFYtUaGL3ZzjAWnd6o0hhMZqOyTl3ToKlvUvN1zVU1DWa9HhTOSpkWtHdaqGvR1O8ievbG o5GiwTUq1hyzhZWrZ9h5Zew2P75PrdbErrkWW3Wj/lzuOI3R+trGy3du165JjfcR2K/8pFkwWQQK BAUIGIuNsdoNBrvZxorWG0wanb5BpatXqRsamurq1FaTRtWgMZl8/Kyqib2mXuSIRtrvpij7EYB2 LRrr6t0Uc3E3xTc9FfrW2PCxG9IC+a/2jZi3l9T4Dlz/9jIk+pVRQdHY7BUbig4g9fdfMX5r0Oz5 e/atXHJ2hmj8JyHfH1MfauR9cG5UtXTD9pT7xsh8075vy6TKf66d8YnYbHx5fNMGa589467fOLf0 s1mD6+/WZSBP9jky7ssJQ0IWvbYt+Xb2RLFrwZibBfOzeG/b+duP31JUWHQGg42xh/cSNBmsPn58 kAZzBw7vNxgMjM1ksRsZi4mxmc2Wf3804aaySW+yWmy8PsF+VpsNpEFhPwEfzDLrHgxTWKJ+MoQ3 Whh65U6Nrrm5vl6rUWnL6xrUGrVeDS5sFSg25Wk0mJzxjmvppJulp+6fnVl7a/qWlUIFBEHvZR5M WMVYGZV85/6pY6UxsdoT6YohaYGrjHrm2wHBonJlsv8M/icx+QUoCqu1B3zGzylgQoe/u/rOvU2G oPfVpTLD9VOb0X//V2VlnSG9NCtHXWUtWSmU5ZiNWu3eeGECYjOPFI8K4Z0aTmhdCsag32WuF3x+ vsrso25megf4glluVJu0Jmt4kB975zVbwerFXtGMrV5tPvFews3SuqdGRzbpbQEC3peK0rnPD5+4 +szfV5OgTERoQGVts2Rw2MjJ3yS+NKxPoEBvbB41KLRlrqvBha1WN6hA65rmJrVGZwu0N/9Y8/w+ 19JR75VOuNvNRydl2Zpv5CfnWD6sUBot2rAP1Noi+aQEwt//z7OSc6xGa9gFox6cTpqVyh9uWjV7 XknRzhO2T7a9f+SpSUVJL5watSRg4r8Kxz2zrrxBmVc0R178YoSxSX1Da5A1JqxmrCW5RcIExSqt reFErizhpK1Zdz5y991iuWW/jJe6adK3rmXT7pYdsivz8/XrH1R9HT9vTJpQbjGZlGW5ZfYKX3rd W7ml9hTe2xPyC/r5jqpcuy852zbkK2tFyVHZ7OMvrx/a91bZC59ULJ52zeerzw5U6RsjptialxgW rd113G6+dz4+XWY1N9VomemyHLnJ8vAKU6QqPZll1SuPppcVZKVadL3/4cd78/sJroXjyO8g3PzT +/FBZ3b67Lwc0yhPWTjPzKjy9kCR4DOv9WhZVMr9018WHdn4+ZrJz8ztF/CycdyhzHlJlp2jS5+c Vzw4i59ZvL/g+IGiuerGCYuXRjwlHXNiteHE9uP3ixT2PIXtgrGcubGoSJZtMTZolfHCUqsVXEUT /LfYk3n3V41x7eQ47m7Rm/+SXXXhLwaZ3I4mRhhtDUVA6Lq01XOnAScvKZJpMw/z+wPr1zD6RYv+ Zdv3hipTcDMHbNeYItmLkl1fmWaljzFpGgvj/aFVWnWkMKbvB/zEy0Zm5fJNGkOyfM7Ta68YGeU2 pii9dNWo+NN6daU2X/5pQrbx+1OXBLwD8yZ+41o39busa8v23Tx4tQqsXP3DAx/UNo/o31sg8An0 Zz8P36vRtaxoob189qx9JtjXbDIzOsbHn2/x8/UBC9mK7dcLTpT5Dw4DhZ8I8w/w89HqzHwGfErz xyX2CdiImtpGbZOWz5is6sai0oqrd3XDemv0eqOaCRw5uPcrryfYXUon3L1VSz25THuw+PIbCkXB rH6Rx6waQWxMcMCwaDImFvj5zVfzPk4cP9Py4jvHbpdmMyOKCm11QgEZM0wQEph5+NAB6DD69m1D nlz50GhnZDfsCkXed2DTfeP8Z2/Em+9IslbZG0uYMHA9rzaZG8ryhbJs6xVjXcn5dDmhf9KHVzx+ zFSX23ICc/O2PPWfX5VkMJUBM6RVxWU2BIKaMjMyIIsvsisr5er0awGIzbJgwVxb3LmzNp0heelL C1e8tNAfuj831aKpkz01bGJkbGxhSb48x26zqs4fnZ6s4I/fknRspbH6O96sytz8OfLVhspyRilT 5GTbPlxfbo/cPZq3Yi2+z7Va0t1q38xPylCWCzPm3NIayprUB7TLlmWZC8+cOpXy1bDd+0Xa8vOy HP4K0axN2xvqVPa7+zfv378/JEV05rSm6rzQP8poZQx5MnuO3K5vLCmarpI1ZRzYfzvzswb7q3EL 9kVO35VlNJqYE2R8GfKnKZbVVy4E8OqnIhddiiUhd4vdWaCeWHr57DTzpviE777VfT77vQahIOq9 S1P6104W9B99OWngwKnzktKEdqtSmbJgwYI/i8MXzl3FbFhfUyQMNCiLFAowq4bycnBrSsiyNNcV 5+Yly9NeO/LqpBc+yt1RfufG9ryErIfKeSZTXVHFT1m8Y9dQscsHCCTq7qcl83WvR/Z9aLIysbL4 80eFl8f6CwRvf7zpqz1v8T44fVZy6ozm1Y83GBi7vX7g/p1T7VEv346yWSIqqlbZdQGCKMi2wKiu KytTlPUvkK/WqZnz8WWKbNvlZm1hw4T85Kezvhp5ntGY3th9qDi/dPmhwz68eYeQra6lEu6Wuv/z g/996+9ngVdejb069EzI/AuxF7OsTN5ftkZfWKhM6VepNNnefzd368aN/6ef+IxeFUDGGJg8+foQ keG8sKpMLreadIzy/Mo8sIfRm9AbRaxWwWR1FpOlvpotKtd9bdhZv//IxQe82CvSSy4f85G0ux9j JvaOX6tvtpIjE/z9/ecOfkkkEY+YuztOpxUGx0Sj0dHRQlK5QWW/vep4VMrY97ZWWpVC++yX16Wd k8k/tVuMai1ZnJ8vVFjMFmvh3lwhmExL5dmndtfvzVf0l2evXW5YHygM5sXFxW10KZBCPF0g/rs8 qL12p3zx+u2XfiwP7GUJDWefxtYq9UMJtF//MIvV5t8rKDo8SMsL6BPoH+Rn8/f1NfB8+/haNEZL y6MwsJbaLIzZbDTpjA2NavBR32YymPR6fbM+2NcGNg319+6DYrfP/M36MbXH1TsFinLzO4XUzaNq yzLvXzPkKUy+q/pHRSVkLXxw3/JlQ71Ga4gXzdqVx1wpUgwcmLR5/2j2RnJRU8UIAxm7SibLyRIg txUFcmtNiSKvTJ7DnDOWFx5Nlx07Rg1OWHXVaEpNzRnO6/OsdL+rl1s07O6XWx9fz8iyNn1y6JCP QCDY8endHYviS7PMgvl2ZWVkv74VT0SY9JU7Pt1E5L9Tna8qo+RyppkBS+jmsX5yeY7PR/acnEV2 xvpDSf5Yojw/fezMd3RFXxYq14XwSirFM129fKQxd798/PFA0/G1ujHg3vCPkwPO5haFDDyZNVqR kG3qNZ93vKwgx3ZulP/Hldu2/RuB12iqYgvz0kOgJlVR+pxzyckFdp9DimyGH7EmaxD4RJby/DCO iPbXwSRNuvl1cGrIlFFzU1JuH8lGI0lV3fai46tXrUsS7cjdYL0hJP4szFNkW0fPmx/z9Tem2ovD wJ5Fqywqy5Ot32wQFlhstnKmqOz63bRvJ3/ESzktinDxVp6CIDe/lU+9u7wicdq0B3vjZcmKrKs8 /z0PPxpLkGFFxfHJ6/763of3VhKn7cLdh2TgXqXesN5kCAvcvm1refP1abxEaiDnQm8nICgIdTMB kZpWU7uDeOPO0fw8cJUfO7aatXyd7+1/1lMv764XyqM+ldtTKitSFqVeDF3B4/H/EHrMaSeGt9sJ 9gd0Jwsv3NWFF3Z1Z9mZkLpiedHl9GQZKuJLl85J6LNx+s63whuLkuV/Pd5/042+PEwb0stpGwq1 20aLSKiT6w/u6pICu1pSgG36d2OLt5StUVdr6F4ZfV7sLcgYlA1ugcNW94pFn+U1rwne0mIaC4Ih uMj5jwP+6nDmVwNfWAfaC4EJKVh0YIiQokgL69WHJbxwFEbFTzqgI4REMYxz1k8Cw1KIxBCW4IKk 7CdxsUCCSFEMJXFxmCQOkcIYBar0kkBSlIYIBGcpKikMt0BhLZURcbCjdYikQJuu8rm9B7CtYhhE PdY+RWMQS52xwBa4u9Edmk1ayh5ArUZEsVVRorWXVg1DHDUpgkQ4RjhTHA2REpiSOmr7OLAxGqNI lIWx2ktwbGs1GMZgcSxbGqMohIJBv0SruhFsvyRNUBTXrpHOxjgtcNQ5G/BnibaWMQ+QkFIcJ2Cc nRG8ZUY41bkmOpV1amEcKqURnKQ6mf5+EpY6wygWcAMOlDgfuEySxGlXUqZDGficg7maQrY/1z7S 9TlEEEenrD1xrQbFoQjosMUqp80sMefoBnXps5yew9kkTLKcoI+ElkKgX/gRE7jGOdvgDrLTu/pJ EFQKhpUWD2PPEThFPzIzcEutR/rgzEKHeQbicAp3QIK0lCYgurNxdWkygdNIJyZHSFAIWIqgHKSw 66wr2hn3yvKECIZxCUXHoRNJBHXQxw7bCUXHoUtCESVaVmzQHA5W7E42gTDS1RUb6YRQ3PX0oqio qMGKHJPuxtFcYakmOPD9SYE+49855jf8+3fffHMbb83WUA3nbke120f1DIKSxWR7IkEJ7MZ6OkEJ NLh7y/z7EZQIRkAeQ1ACMaiHEZRAEuGpBCXQRns4QYlgpLufzP1nCUOO0N/nCd1/GqUEQimvQSkR sGP3IpQSyHX368vuh1IC0e5+i9l9UEqnaNrdbzP7bTrY+wwUzmvwHS4+zB8RDPFw9JoIDr3Eq3/2 3U8FvtMHPpVTYpJH39g5be+N83XZN6Ufz5xhRDO2PTfz+NIp4dbx5kjp8DvHVtUZ9haWZ92u/9eg cyfTEiceD70fcfiJe/eT3qNe4D31am6pKeZ28Vpe6p8yBbf/sGig/INDLtlRINjdjFn3YkeBYHeT Zd2VHQXS3U6XdSt2FMEhd1Nl3RWgBNLdzpZ1Q4ASyHY3Wtb9OEIEh90OlXVHjhDodvfXALqrbnd/ B6C78pMIjrj72wCpOwu0rzRUMWlpozdZppLJ9nkpKfcrF2596HM9JNl+2Ga3aWuKZb0av5o28pCw LNtiMcjCoocJog4chIIyD/v0N92I97kYez5PuqN+z/Bzq6vPPDt+8Rd2hfxpOWMCt7Gw5BwzU1NY WBwPZrmpvHBvXrIih9GXl6dvmRj2Am+dLcHlrRtH3L1N647cKJBNeA83CtTSXsONIjiKeAk3CqTi XsKNAqlufwr2H+dGERyDPRGrbH/+jmOYh9GG7bdRzN1xJ1IToeB569avlNvsq7RVsnjFlq/rZC8R M5Z+ky63Z2g0VoupDtz/xvoNrb+cnmOzag3C556uy00vs1nLLbZy3YajUxWKbLOZKd4+PW1M1mZF ATymIDSRx1tSEPemi1dbjtf4HsVPtvACPZCfdHAXKEmKKApvAyXYQxSmiHbKgpNuK9YeXew3MGAo REmhjgxYkqSVcXIgJgMkCC3FKboDNOSEXFwyRb+J8aEwHEFccFqoeDRbEccQmuQiOpz+uPb+OnzL UbQFuIIpjBD7cgziNBwnwUBFDCfbyRjHHHERlyUdSBjMwYxy0o+RMLCI/Zu56DHCBsOh1uBwmQuC Fo7qGCuOcNAknPZaYsUhzlhxDjaIjQZHQiSEgqmVUg7tLbhgp7m/Ch0EPkN38BqcdJBWGCGF6ZYw cWJEkvh6yxCB3hy4lejxRIstneX+WozR4bEdzYGllAhc8QjZFrRuoMPZMAphg8ahCKgBnLGfJA6T gsGECHEoG0kOQRHCQTqiUgRmYa8+LfgaBRzRTwLU0QTwuUGsbxAIWCRp8WBOWshJO8uIRY4QcxRN sz0TwDAah1nSEJViJIGQwNVwKQHDOM1JsTHnECkJLm7gqjiwm0ZQcJG0ZQ+VxLEB4igKET8hQaUQ hOAke90QUgJCSJagBCfBJtFxzZDA/WlOMwEgBSGwg2xsK+Y85yw3DOSCy5wmOLnDXQSb64r3oz93 JYCbKcVlwthDLgRGIo8dcpgw9v23Kyasx98FHhFB9FgR7VwTjtM9/KsAYM1AetpXAYDNeHf+KgDa vgMlqG6F22d03F0t6bjxIhC4Q/rRTZi7YP3/3aj9ho0ajXSgjtlD5y0FhXDkscP2O4zj8OepYxrp 3tQxjfQU6phGeyZ1TKM9nzqmUQ+ijmnMg6hjGvM46pjGPJc6pjGPp45p3EuoYxr3EuqYxr2IOqYJ r6KOabcHTeqG1DHt9thJ3ZA6pt0eQ6mbUcc06WXUMU16LXVMk15GHdOU11LHNOV26rhbxi8Fwr2Q O6Zp7+SOado7uWOa9lbuGGVf5Hshdwx0eyN3DGR7EXcM1HoPd4xCsLdwx0Cqp3PHbQ/8gFTKE5Fc jkDE3cxxt4h0CnR6KHsMlHkYe4xCqKexx0BSz6fOgIieT50BET2dOkMhrMdRZ8Dmbk2dYe33Q0dI vm4TgNZ9UV5RsIEjfg4cSxKzYTEdgSg7QF2Ei1it3LCRnQfq5Ob8mkiaLfExCaidFWOxbG5YWFfx RTn0l7NotMsYqhzMraNpzkHgcmW+nIiZLuPGdjYizvi1UpAiwPaZ6BAGNcJpvevAsL/ccD9HEzBF 4o9gc6iUAD7NifDpeig4Y9lhOp7opHRbv/GtkV9RKXCv1sivrb22I4UoRZOdxcR9wpUYTj53/DnC RnKrdQz56rAkDqGkVIs1ENsYhMKg6CDQA4XiYFphUJ/CaXY8uBPhnEquRyHt1VDWoXAEnIuSkEAi GyG4E4yxQ3xeZ3BkR5xZoKbDlHKa4OodzhXZHvs1QAI7Ir4SYoztgqIxHO1kUjsBNjsJA+w6UnFX vNuV6zjoTJeu8zPRjikKVOs02nGbQY9FO2aj4P62aMd+DjfGIdBgewBjV+FvUaJDvFrHIQcVJTt8 N6Hl0EmOkp19N6GNHAXNdWtyFNjXQ8hRcHPrkeQosLvHk6NAg+eQoyjhQfFqgRhPI0eBJI8lR4E2 TydH2R2URwOVHKHeQY4Cod5DjqKEV8WrBXK9jxwFor2PHEUJL4tXCwR7FzkKBHsrOQqkexc5ipJe G68WSPdOchQI9z5yFCW9M2It0O2V5CjQ7bXkKOmdEWuBbq8kR0lvilgL1HoROUp6TcRaINVryFES 9XBylHR7tNruQY6Snhq1FijzNHKU9LiotUCSB5CjpAfEKwQiejw5Sva8eIXA5p5BjpJENyNHfwsV iuHIo+EEfxtAF/0YhYhwf16dw7b1egxBI6kOkJqjLEVjEMahx7isnRNe5KKHP0uEPcoodkbDkQjS kRNr5/A4LJ/r6IQdQh22/Ug7LqGllGMEXP7U/ABJS6zGtjCIEMVV1+sXKLbhrqC8ke0/c9+RWW3N brGSoLGO3Osvwb++LcAcSnK4z474Y9v4DmV/zp4NLt1xHLnQZmszHGiTOzjOhpDWhh4x1CV5PEoC 41IIpvFfRRo7++tINjpsBN7IxUFbhh4BI+Os5XKuO+/OdRRMLtncdhm1dIE9AtD+0mXwC17WCWSK s6dh/FFjhz/GlqIU1wSn2WHgmqNwlm7uDKHmqHWFV2IowcUrHYdOnhIMA/LYYTte6Tj8WbwSNNet 8UpgXw/BK4FD9Ui8Etjd4/FKjP3pB0/BK8FS4jl4JRDjaXglkOSxeCX7vRQPxysxlPYOvBII9Q68 Egj1HrwSwyBvwiuBXO/DK4Fo78MrwScg78IrgWDvwiuBYG/FK4F078IrMQzxVrwSSPdOvBII9z68 EsNQr8QrgW6vxCuBbm/FKzEM80q8Euj2RrwSyPYivBKo9R68EsNwb8ErgVRvwSuBVM/GK8GC5BV4 JdDpoXglUOZheCWGkZ6GVwJJPR+vBCJ6Pl4JRPR0vBLDqB6HVwKbewReCez0ALwSRykp9v8Dr/x/ oQ8xtA1dQ3C0I33IBp+EHfEpnTCZ6x9nduaHsEaBk45on+CDo6NgJ6EQO0fiWvE2R7jAoZIW0K+F dHscKHVCbY+0ALciix27caJqMSxC6EBBXXJxzoJ9QIrGUdAqd/hbzkIEl5/kzJQrzpWDbEa74ve4 zT8WxNERODOsNTQhJsXaQxNyZXcSU5LL4v1W/jFEAmqxU8v59ez/C3TT/VJlbmRzdHJlYW0KZW5k b2JqCjE5IDAgb2JqCjgxMTUKZW5kb2JqCjMwIDAgb2JqCjw8L0xlbmd0aCAzMSAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dCXxTVbpPmu4tbSliCwUSKNiE0vTuy4gNLggCDwat Ioq0UJZRi7XFx9o24DIo8qwbosJQxJlhUJ5FHAcQbBSUrWAdUAoWWqBLurdJmvVmeeembXJDb0D8 TTBtH/x+cO69557z/b/zne+em/v/zpcrgeQwIoHYvz2FrGXhqQ+TkqXLw3PDEZqW0zQh6fl/mesM gUKQJDscwXHIo9xzPTv8T+FzJM+F54IWCQhcT0EQnAQHoBbpquXsC4EkD+SEzwZ/WRlgiMaAMAiF 0axAcoyiIJSUPDzlRlfzlgJhKTnK/nGC4JazlknuSwf9wKgEIeWg1/Ql4ZAElqTA4CKJynGcxiUE LodQ8H/6svAnpYNlKbAcIXCSkN4pA71hOExR3LNBMlIO0xAsFclSINAAimCE9C4ZuEyTMC0lnGdp EsExaQhbRmgcozBptCwFkUMYDGPSec+BhmGaoClaGiEDZxEMpaSJMloOtEV43BUpY7vAUQyWkqAL jEJJIEAK0CBJIpQ01S1hV0MAtzTQ1aS7BO7B5QSFYxinx3lS0CQJTpLc61zp7nBWIHDEQyhO5TEy GJeTBIlLA1gNERRC0tIETrOInKIpBP8NvbIVvPQ6DlSAYAwoIB6UaBqhMecIkBQKOuDeFAdapWkU RTxUEAzq4hDk7IACVSFUmiRDCDkC4Z63c2SNlD2VPi0cx8CdBLCd9EXAVq4Tr2dUOKrgNDCWqxXQ GURibIsp3U2moKicwrra5Te8oWxvQD8wSkjnyVhgEIrABEfJkTIYlWMoRLPqBEUIWOENpSG4V+PY WygCDIBbVPewdVkiRsEkuIcAHdIU7sWSwcTAABYccvaII7gcpWEW6+R0MNFzw2EcBY4BJ7rdivOQ pKhu3wETBNzrEEG4hz33Oh3N+G5Pg1FAh+B/0BwtIWi8x8nc91B46v2PpD485b7w1DkSmAhPnSqB w1Pv++P9Eio89cHUB7PDUx/448SJqX/MW7zo6awXcvJAE+CWnOz/XvbccucNoJyTt1yCpqWFP/SA ZNW2LKtd3f5RYkW7bdE1h6Ox5qUycal9SWamiTEeNxYr12/KqZ40b8G9UQ/KCyX3p6dHCEJS4iPD Jz8kme2UFDjBbkkxBEiKeJGUvlVJ6d6SCv8g+N4h/PuBE7ro4SZLe3CHrr2pMyRxXM2Xf4mMTdB3 aiIio+ub24YPjRUIBP8+d35ofLxaz4x4ML29Qz86TPDGNyOuueUmaJfcwGlSBL/cCHqLcrM39JL7 QcFBh7CsvPJ0ExMQFmgShUSY9T99+dfh+DRt9B3jRsRc/P5MzY+nhtwZV19bFRM/BkhvNbQ2NzTE xNwRM/1R9bVWbacJnFx8j+QrZvQMNwbSZSXAXggK8oLhVq0E4bES4SzBXofw1R2lQI5BtobBCWM0 Zmt0SGDZt6VxSdQYCu2wGBx65ttP/1dk6EiZNPniz5fqG6pA5eHxY85f/mVcwmjtcPHIscNtHaYm rX5wUHDZ1frLtUlPuMEAf9ENBgeTgiS9gKFuFQzFY/LZW7++/4+bNggj09DlOrvN0nlq8tNDpqy+ 5/uKnLSNyz9vf/yAVaeU79jzt48v1kXsr1IoBy2a/lD4xLX2e08eCTxRaCn64KpOZaxWjDpk+2XG 9nZt6xzBMvk41A2GhlxgMAAG4weDQrcIhr2hF5iWx/fOemDmtdSkaJHo6NHXtwQ5CguZd+Z+XzZ9 Y3Fj2fGMidbsZMt7+UsWLRaIqhyq9vw1Ro0o4eXkxBO6WltcRAENR5ybXrE94nkrY9ZVfF5Zgv8t XjzRFCVYiSZxIaEuSOQNIMG3CgnmMbb5go8cwq2nrwqEYVfPngdWFG1oaBcNwmdOabpaLzJ2Hj75 Y7s2IDYm+pq6TeD8Exkmqq1SPzp3MihrdExDfcPZHy7krl+ib235qV5T32iMCbU3t2rLq9rpkZZv K5rXtKFmDjaXMyCAZyBhL9hu1RmgfM5gkWCrQ/jnrQeGTBh/6XJdeGs9kLjDJhoFpVyrVnc2NtZe a4sdPYKaOH73vhMdlgBw1Ww2iwyCp54iFt7L+oZLrfqI0ICi3T9R8EijEVy0/aLWqZvMwyI0Zy50 tmo0944LN9islUnECjdCGMJdEFEJQVBeIOK3ChHnsciJBXbDZ6Tiu0BzVfXq04Jgtbgw+O3iUuWQ 2MEqxiQrenPSkgNPa75LjLmoqJh/YUP8mWnY6YyVwScefSt29ubBE9cYPjr8YsOGHNWBucNKFHar /WjFrPa01yKsh8wdF8uLMtafembnZeHrO6EZ/PgIH+MTPiPY7BDmF38zMnH4+cqmQSHBOrMFDExw iKjDIIgLF13tsDTq9Z16R8u1FuvgKHDJ2KRPRsUfPU8c/rnho/1XwZm3ctBLakNshOhKg1FrsQZb 7CarqaZJr25r12k7WpqYn2trJTFB2o62d6LT7BygMOwCCpYGhJelAUreKlCSZyC3fak1fVx9OjIy slhpX7iwptRRHyGKt9qPS78vyzceVcysd0ySJ59zTC+qmt6xD0bQ9t0r1lgd6q+nKJZmfxXwrvaf by5daCv5dOzzDrMxwxE/v9B6yu5o3xwirrKarJbvk0cfq64QH2ZM5g0bBR9/9gYiGN5E/oMXLIn4 GKzweUGRQ7jk/S+Gx4++XNuROCzislpvDQwBY6XVm6MiQoxG0xWNDRw6jOZmRvD07HGvb/9xjDj2 gZToJHHsNCRh5GP/C66S8LCip1MbOkwaPWN2iDq0hgCrSau1V6tr6zUGoaHTqNVW1ukjAk1hAUzD 4YmBXLiuxRQJFiWEl8UUequLKZRvMbVC8JpD+PnhcwfVZoYJNNmsg0IFjRpHlzvVWJjo4KDGTrPN ZrfYHG16S3xUyMq5SY+9cooxMKlJsa8sGP+PozW7Np8Flb/e97DVatMZGYPFwTBWvcHUrjWaLSZ1 s6axVdvSoRHqO+sbWy0GA6icnzkzfNfMKH7Q1G0BPfe1/XGSUY3trDgWKwvXwLDjyjjsQcKAJp2Z 9blWe0Ob4VjRvVqT7anXTl+80LQmKzVA5Djzi3bxNAmoEB4iYqx2xuYwGh0WOwvaYDRr9YbWdn1L u6a1taO5WWMza9tbtWZzQJCtfWrYjJMc0IjraUqxrwA0P2jsVp+mGM/TFN94d9SLk2ImbcgOFT45 JHbhLlIbOGL9S88jCU+MD0/A5q7YUL4XabnyhOkro3bn3wvOF5FzcyWT34v87oBmX5vgzWPjG+Qb tmReMcWVmHd/VS1X/3Pt7PekFtPjkzs22AbvvPfsuWPPfTBnVMul5lzkzsFf3vvxlNGRS5/anHGh YKqUHzDmY8DCfMFLDuGWg+dVtVa90WhnHDFhog6jLSBICMpg7MDhlVajkbGbrQ4TYzUzdovF+u+3 p/ys7jCYbVa7YHBEkM1uB2VQOUgkBKPMmgfDlFVq7owUTBBHnbnYqO/sbGnRadt1Nc2tGq3GoAET ux1Um34PGkHOfpkfOulj6Fl75uY1nZ/1xkqxCoKgV/M+T1vF2Jh25bY9MybJk5J1h3JUo7NDV5kM zFfDIyQ16ozg2cL3kkpKURTW6PYGTJ5fykSNfWX1xcsbjeGva6oUxrPfbEL//V91dc3GnKr8Qk29 rXKlWFFoMel0u1LFaYjdcpd0fKTgm7GEjhcwDd2WsV784fF6S4CmkxkUEghGuU1j1pltMeFB7JPX YgPei53RjL1FYzn0atrPVc13T4jrMNhDRIKPVVULHhw7dfWRv68mQZ3YqJC6pk7ZqOi7pn2W/lji 4FCRwdQ5fmRU11g3gImt0bS2g9a1nR0ard4e6uj8qfHB3fzQ0YELnfC1mU+Yl2/vPFeSUWh9q1Zt suqi39ToypUPpRHBwX+ek1FoM9miT5gM4PS8OVnCseZVcxdWlm87ZH9v8+tf3v1Q+bxHvhm/LGTq v8ruvW9dTau6uHy+suLRWFOH5pzOqGhLW83YKovKxWmqVTp766EiRdphe6f+eNyOSxVK6x6FIGvj Q1/xw6Z9DTtye96H69dfrf80deHEbLHSajarq4uqHbWB9LoXi6ocmYKXppSUDg0cX7d2d0aBffQn ttrK/Yq5Bx9fP2bI+epH3qt9euaPAZ98sLfe0BY73d65zLh07faDDsvl46k5Cpulo1HHzFIUKs3W a2eY8vaqw/k2g3p/TnVpfpZVP+gfQYIXvpvCC5yAkNsA3PLL66nhR7YFbDud1KbMXLLQwrQX74Ti wDuvbX91fOaVbz8u//K1D9dMu2/B0JDHTffuy1s4z7ptQtWdCytG5QvzKvaUHtxbvkDTNuXp52Lv lk88tNp4aMvBK+UqR7HKfsJUw5xbWq4osJpadepUcZXNBmbRlOA3HBmCK6sm8ho5AeG+Br3pLwX1 J/5iVCgdaHqsyd5aDoCuy169YCYw8spyhS7vC+EwIP0axrB06b/su59tzxP9XAiWa0y54lHZ9k/M c3ImmrVtZanB0CqdJk6cNORNYfppE7Ny+UatMUM5/561Z0yMejNTnlO1anzqtwZNna5E+X5agem7 b06JBHsXTv2MHzd1W/za87t//vyHeuC5hsWEXm3qHDdskEgUEBrMvg9fbtR3ebSosICda++LCLSY LYyeCQgWWoMCA4AjW7HlbOmh6uBR0aDyHdHBIUEBOr1FyIC3tGBc5piCjWtsatN16ISM2aZpK6+q /eGSPnGQ1mAwaZjQu0YNeuKZNAcvdNjXS7Wsw8/rPq84/axKVTpnaNwBm1aUnBQRkphAJiUDO//5 yeJ30yc/bH305QMXqgqYceVl9maxiExKFEWG5n2xby/0BfrSBWOxUn3N5GAU5xwqVfHXYNF97vgH z6ZaLsryVznaKploMJ9Xmy2t1SViRYHtjKm58niOkjDcGSComDxxBt+ynIAxHy/Ls/75SWUuUxcy W15fUW1HIKgjLzcXsgYi2/Mzf5j1Ywhity5evMCecuyoXW/MeO6xJSseWxIMXVmQZdU2K+5OnBqX nFxWWaIsdNht7cf3z8pQCSe/Me/ASlPD14I5dUUl85WrjXU1jFqhKiywv7W+xhG3Y4JgxVp8Nz9a 0tdoXyiZl6uuEefOP68zVndo9uqefz7fUnbkm28yP0ncsUeiqzmuKBSukMzZuKW1ud1xac+mPXv2 RGZKjnyrrT8uDo432RhjscJRqHQY2irLZ7UrOnL37rmQ90Gr48mUxbvjZm3PN5nMzCEytRr503Tr 6jMnQgQtM5CTvGARyNdgt5VqpladPjrTsjE17euv9B/OfbVVLIp/9dT0YU3TRMMmnJ43YsSMhfOy xQ6bWp25ePHiP0tjlixYxWxY31guDjWqy1UqMKrGmhrwaErLt3Y2VxQVZyizn/ryyYceebtoa83F c1uK0/KvqReazc3ltb/kCw78iEr5fkAgENTXv5Ys0j8TN+Sa2cYkK1KP7xefnhQsEr307sZPdr4o ePPbo7JvjmiffHeDkXE4Wkbs2TbDEf/4hXi7Nba2fpVDHyKKh+yLTZrm6mpV9bBS5Wq9hjmeWq0q sJ/u1JW1TinJuCf/k7uOM1rzszv2VZRULd/3RYBg4T7kHX6ohK+h7vnw8/8+//ejwCp/SP5hzJHI RSeST+bbmOK/vJNwYok6c2id2mx//ZWid1577X+GSo8Y2kPIJCNTrFwfKTEeF9dXK5U2s55RH19Z DNYwBjN6rpzFKpqmyWfyNT8USGr0nxq3tez58uRVQfIZ+Sm+n/kIhPb1z5jpg1LXGjpt5F1pwcHB C0Y9JpFJxy3YkaLXiSOSEtCEhAQxqd7Q7riw6mB85qRX36mzqcWOuY+vyz6mUL7vsJo0OrKipESs slqstrJdRWIwmNa6o3fvaNlVohqmLFi73Lg+VBwhSElJeY0XIIr0d4D4bfmh9seLNU+v33Lqp5rQ MGtUDPtrbJPaMIZAhw6LttrswWHhCTHhOkHI4NDg8CB7cGCgURA4ONCqNVm7fgoDvtRuZSwWk1lv am3TgFd9u9loNhgMnYaIQDtYNLRcvgKqXTjyN9u71E6ebwoESvn4m0LWpvFN1XlXfjQWq8yBq4bF x6flL7l6xfpxa4tWZ0yVzNlezJwpV40YMW/Tngnsg+Sktp4RhzKOdoWiMF+EXFCVKm2NlariamUh c8xUU7Y/R3HgADUqbdUPJnNWVuFYweD75Xt4Pm4RGOzrj1vvns3Nt3W8t29fgEgk2vr+pa1LU6vy LaJFDnVd3NAhtXfEmg11W9/fSJS83FDSXk0plUwnA1zopklBSmVhwNuOwsKlDsb2fWXJJKKmJGfS wy/ryz8uU6+LFFTWSR/m+fhIYJivPz7+tLfj4Fr9RPBs+Mfh4UeLyiNHHM6foEorMIctEhysLi20 Hxsf/G7d5s3/RuA12vrksuKcSKijvTxn/rGMjFJHwD5VASOMXZM/EryRZT6YyAHh+hxMYKSPPwdn RU4fvyAz88KXBWgc2d68pfzg6lXr5km2Fm2wnRMTfxYXqwpsExYuSvr0M3PTyUSwZtGpy6uLFes3 GcWlVru9himvPnsp+6tpbwsyv5XE8nyVJ1g6lk+/ymddWl6bPnPm1V2pigxV/g+C4J3X3p5EkNHl FakZ6/766luXVxLfOsQ79inAs0qzYb3ZGB26ZfM7NZ1nZwrSqRGcie5iQBA46mMGRFZ2Y9NW4tmL +0uKwSw/cGA1K/m6wAv/bKEe39EiVsa/r3Rk1tVmLs06GbVCIBD+IeqAW07M5XhxsD6gvThe+FYd L8z3ZNmWlrViefnpnAwFKhHKn5ufNvi1WdtejGkrz1D+9eCwjeeGCDBdZJhbNtTlUnBaQkJe5h98 qy4F5nMpQDbDK8kVb1Sv0TRo6bDcwY8OEuWOLACPwMTVYcno/YLONRFvdInGMvkQXOL+x8ne8zjz qxl7mAddDwb6B04Hhgg5eM47yXqjZQgqJ2AUZZlIKRBL44MIBJcGyWCYJVgh0iSWoETiJAVLI5zM PAgU0S6uE8HSwiLZqjBfE06KFoKwFCmnX4BoJyEMknfXGOsuBslgz8pOSthd7goiGSlHMQRHpYls fwQBOSl1iBzDYAxmyWOonEaAmB69BXIk5paT2TJGUQgFc+T0QAJeuZ1N8AgPUxjBFZ5bxa0XTgXQ MNuuk0PXgzNJhjgVy7K9EAANJXFwcwosRwmWBemuOJhl6OEokDqKrQhhBPequ+lubaAU3kWVhIEG MWmYWwpO69yR9By1ePZWlOiStUcxEU7qHobjcthF3fMykNyWo8GYUTirQloOgQ5grl65qDmm5NLT LRkPlw7YLWYKAoy9S9SbqrqnL09VcKFwTI3XajlqTuC7HgI6xnEKp13m6xowhECdvMKuu3rPw+4W OGPKtWSuetzqc5e4ILxM5a5hgnGie6DwXkbBre1WIXc03DqMYRULkyz10l2VozOOJrk4+AfcbRoc 63brhNMXV8Sb6YEr+BiWdYrQBGgiucvKwRoGdVm5x0Rj28LJG+jGm7txe1Ne5wVskei2RY/p52HV XWJxrDqB6xx7FH0TA7+Jq/Eyj5NY43TOH68W5LRNkkK5E6FbAzTE93Rxz7jeDsEtbxifDw2RYTTJ Es85jFgEcX4I6WHEOg/dFFgE8yDIdh26GLHOQ15GLKtw9qGKAK8LVgheXjpg5FZXCIgXRuz2e5bG x8ePUhWa9ef2F4mrtBGhrz8UGjD55QNBY7975YUXNgvWvBOl5ayuKJd8ZN9g7CIoDPVFxi6QG+3r jF2Ageg3jF0Ahu43jF0ERZB+xtgFkPD+xth1/YwIwFH9mc+KoCg8IPisACg2YPisACw5gMBi0AAi 7wK46IAj7wLQxIAh73JA0z4GPXTj54OOQDGC1sCx0i+E4yIgAY7+KIGjTgla7n/lfVHgrBF3F1aa lQnnts3cde54c8HP8ncfnm1Cczc/8PDB56bH2CZb4uRjLx5Y1WzcVVaTf6HlXyOPHc5On3ow6krs F3dcvjLvVeoRwd1PFlWZky5UrBVk/SlPdOEPS0co39zHy1ZGUNzXVC//YisDwL6mefkrWxlAvz1M L/9jsCIo4XOmlx8yWAFsX1Pz/ZPBCoD7nJjvdwxWBCV9Tc73SwYrwH17mPn+x2AF0H3NzPdj6D5n 528r1T3RWs9kZ0/YaJ1BZjgWZmZeqVvyzrWAs5EZji/sDruusUIR1vbJzLv2iasLrFajIjohURS/ 93MoPO+LgGHmc6kBJ5OPF8u3tuwce2x1w5H7Jz/9kUOlvEfJmOuajdEZhRamsaysIhUYeEdN2a7i DFUhY6ipyXljavQjgnX2NP6nOOVzcr4fkpYBbF8HUPoRaRmg9XXkpL/weBGUhgcIjxdA9fkPYr87 jxeAJPs1zRXBIGgg0FwBTrSf0VxRFzLCx59PstKhiIXr1q9U2h2rdPWKVNUbnzYrHiNmP/dZjtKR q9XarOZm8OybFDSm5XROod2mM4ofuKe5KKfabqux2mv0G/bPUKkKLBamYsus7In5m1Sl8MTSqHSB YFlpygs837gwiO5nxF0Eg5E+T9wFIPA+TtwFEKi+RtxFMATuC8RdICfmr8RdIBvpV8Td30LKRcDa ksvIpWSIHIZo536WvFyxHkacm7bnZk5xCHEe5NgePlUvPh3Ey5d1UrbcJC1cRssp7/QyLtNtLB8l 8DfQysDbI+KFxhrolbvqhbDJx771xmKEeZmgd/ADuL5hmKS4I+BBe4UxJ82NS3jzZABy2Hgu5nVv 2mp0N0eRkhNYD0exSzcoRBC/iu8IyUkIhT3QetMGh4DYw7PDSFxCUXgPz449RGiMcO9g6y73VHPt ZvsbZgcKA9PzmB+/lqR9PUn4piRtt+K5uuOMZxfhEkZQTxvk0Hj5p58nudctMsc6fg3X9vptQJ3D wd01eJnHhsIYBXmWPTYXZhmOwO+Av3lLe21UjOFQ977DeYvDl4z33IaYcPIOOe11bUOMuLchdvKc 2Y2GgWsGlgYKlBNaVyCD16u/KqgBmAftYSA4ichxRIIRcpju2oFYisrSn+lSEeiN1SpoolehSxZv V39tgAUlh7DrxIGBvYIlIUL27Ic8wjm3MQpht7hF2S2MgT8byu7wCpQJbCKK3VYXQVn7uZONYkBg 1iic29aSJAVmZ5AMoKMJmpSOZG2DQMAqmpaO4pTFnLK7jlTi3PqWomm2ZwIIRuOwdDTbB0YSCAms GJcTMIzTnFIQuAeRkyhMgVkCDA6jERTYZM/lMSxVmYYoCgFOEQUGjHQRogk5eE6RrEsEJ3EUd7pE EsxTmtNMCChBCOzkZfdUc59z10sEVymaognO1bE82+B6eJllng4IuFKP8vXOyFcxNv/vsG7gsHy7 RTkYiesHA8PkFBgNGO8eDelmjm/4TxkAdL0T6OkWJdn/nEYQJQNLfYidfyLnoJAEhnCLQazGcQh3 7uPNLvsgkrV+1l0irJNwLoUQmoIxMO/AmOHsTtKskl3lCDZMCCOdC0NgK+z86TIhCAXemmbneE8F do4DFwARNFcEYGNAS6RTGEyOwySKchoN7FUigaMFXpwAawkEmJpLEE6T7HKEomES4TTUZTwoQWEQ xjnNuYuLiqOCse6zAAApx3CKRG4GgNsWtwuuEO7aOLuZOQ7eyrj99kbuocHIrk2/yeuQuYUJc0vA GUWPymHOVR1Yw8ldgSfOGY9CKO5dBbwS9NiOx9BztcBpw6OOu0NODfcA9l4M3vbJTFC/y2Tu7pYz me90bvkO4TDda8zZWCIY92bNY5zRPcBXkpwJn9gVGoYSnNnAN3G8tMkxBF6bod1Vw/i8xc0NzTWX 3NbFkWUM621QEmHdFSHHMYhAPbVyx/WzGVShPCarCwAOVIEQzq3wed3FHV7EctfgncEedj7cGfpJ 0zRJcrvp1igFHn8eo9TTy80nGVcRzpc0hM1BIHEFkrlQeoPEaz5hvNbjoQiPMLGuTlOQ7kQIboQx QLfgKniQc3y126Nx1OWuyTnZtSYApwlPBYAS+1vFrXl1jv+el+d8yScIsI5024S7BQ/QHAm47tul 2evGIwW8dIN1tUcjvObuTMLhjILuBkTjt4wIJoBVoZiHSnvmQyL7+o+DZQH/c4VFANbkGEHe7HHm 9AvgD+cZz7kjgfe56b6bUzWpy0SB0MCpuUy092Pfy5ODf7HhtgUeP9Ft3RjGcW6xMjAScgRBOYt6 NsibE8nnPHSH7qHsRvDXH7oi+ZyHvJF8PT+7gsUp3hfjz4Dcvv6J22fxZ24M7NYtfRNDz9cSgAHr NzF0AAzZb2LoUIz97atfxdABSGh/i6GjXc6A3RCmX2e9ABB9vl3c7xkliGKEr3eL848oQQAU7/+B c64VEnF7MiL4UyQZipHwgIskA6B9vcmuf0WSAcC+Drnwr0gyFKN8HW7hd4BvT5yF/4XOAeg+z4Dg V4k+AGBfR1f4a6wg+5l0AMYKAtg+z3/gl7GCALivw2L9L1YQxSFfB8T6a+AYgO7zoFh/DBxjf6If gIFjKA77PCWC/wSOAbS+3qrEf7JdALC+3qLEX6LkAFSf5wb1kyg5FEd8nRnUj6D6/Lev3z0gEID0 +X5uv2tAIIrfpg3dfq+AQNcCAr1R6vM+GDYHEN0o83lfDJtDcXZrtj4eNgdAoH08bA5AIPpa2ByQ me4LYXMozm5a5p9hc0A2vM+HzWEIu2W6B9E+1UlER0iWZ+Ut/Ik3Ps3NWueEmd1gx3L+yLDe25Kz wS0oTdLAZCGWk+px/KsYqag33AgCXpK7cQtZgSiUZuPkAjhlkUdgHyQnCCcZjZMqI5itAeOuaIPu GwESjJQjBMHh+vomWqIbDQpTcqILzF1chfbkTPDUuTsckROz4Bm+wBPR1ytRBlv1P5UooycQY4wM d0bXod35SlghvW3539MFV1xvYSEcOT3iOmGenAme5s4JwkhBYEQOFrqcHAJ3cqaML9TSNcM4Ma0J 3OHtiUCNk7Hjz97SFWOCENcP+c0TUETKAEp2gH83fjqboQGcut389J5uOfx0mFU3DJ7snoRYflbn deRSJy+TQzpO4C3y0lS9BFUksWcRmDUxXoazm27MYfIOBtcxnGDjx9isN6B9Z16InjZ/TXQDHzD+ iJowDw42QEN5p6A77RsDr1Ncad0QvArmlSruEsitHBfL1xu12SvinpiCsbxMYA7k7ow+4CmCufi/ vy3ooBd2HKIIWDpcxraNQbA3iNdP19xwDGX3PHExf52Hbqovm/ul16GL+es8vGEODwyFYX/O4QHk w/pGDg8gKdkXOdQYivg6v5/P+ccAg69fO28f/xiAIfoN/xiA8fn+RreZf4yh6I3SkvRN/rEbW//N TwLA9ev8JBiKDYz8JADowMlPAsD6Oj+JP6XswFDc11/9/Y9oDUDfnjwl/kS0BqB9TQLwL6I1AOxr aqZ/8Y4xlPA1IdNfeccAus9JmX7FOwaAB2qOEgwlfZ6jxC8JuAD4wMxSAoAPvCwlGOrzsBm/zFIC cA/ULCUAus+jZ/yRcQ1w+zxFiR8yrjGUDaAZKIxrgNbniUn8hnENwA6UvCTs57V+TkN2/eKHsREx /ZihCwD6OieJX6TswDA21qVfpexwI+unyUgAsn6WjAQg6m/JSDAM6fvJSDDn5m99mlUNIPS5ZCQY hvaJZCRATr9KRvLbqMs4Cp4RntTloc7d3mGKxKUYW6RoDEd5yJLXUUe9JLz4VcxRnq3DuymyFM3h RnfzMDEIoVDEk+7Mw0P9A0vwwlGnOD3k3XgZhiMs3Y2zEfj/AVrLinllbmRzdHJlYW0KZW5kb2Jq CjMxIDAgb2JqCjg3OTYKZW5kb2JqCjM5IDAgb2JqCjw8L0xlbmd0aCA0MCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nOVdCXhTVdpOutIFWjZb1oa1Cdjk7otgw+LCNqBYFxQp0AKj f6G0KIKUhOowMoKUURAQtW6jODJWcBxAS4MgS9mqg1iw0EBbWrrRJm2SZr3/d9MlN3DL4m9/oaHP Q8+995xzv/ec73znS+773qbJECWKyRD+p7WQtDBUNZ2WLVgSmhaKsaySZSlZ6++FbWcoHEFkKaEY SSJe5dbrKaF/Dn1Stig0DXqkELgeh2EkDQdQi26r5b4XhsgeSA19FH7ABgRDSBSMwWiMJVgoEAjL gmXTH77R1fQFYCyjxPl/bhDCctJC2bgEuA+KyjBaCXdNmB+KyFBZHPQko3ElSbKkjCKVCA6/ExaG PiOPUCBKBqEYlJYHKuJQJc7iJCsPgbMogRAILe+lIJUkhTOsvDd/naKghrBqJF9EWQTH5GEKDFHS CMHIu0B7hEVQFJMP5K+zNE5SXl1RShZlaUreTQGtUZLlW8dBa5IgMEouc5cRCsPcZsEI0jTGyIMV tJLC+A6am1Gs+zKppBho14KFZihSPnORB4GwHKZAMZh9FAVjUH5sEVLek78ZhpKMV1HQbzB/liVZ mmXk/YQj09qDoK5gOLp7qvaAIksjGAB2F2G8GWErwX37K8BAgkEwAcYB196UQAnhHHhqRipwlAJX oZ5NmBSK40qGkCVMCU0Y8UzrPBCI1+yEewwTzLmga0EzQV3xIWupwAi76gtwEJRBWGGngjbNeFCA HcfjxhlcOG5CnxDcXjghUdABiSMMJXQUj6fFKFhwGRLDBNMVomCUNEagXv0IZkPoML2gPQPrmPcC FEYCJYUTL7Ba2JfAVM/UuAcFaoLv8UNBKDGKRW8+qN3F5r6nAmcZJYu5p/nBBIgnaaEoQdGwtpGW 6OU+pBmsJUTBEmOvOwRXERy2tnXHsxEtAY1gZHF8bEEJGiIh0xbLxk0MVY1/TDX94XGhqidlKBWq miBDQ1XjHhkvY0JVD6keSglVPfDI6NGqR9LnJT+X9EJqugwloUlqyosLFy1xN4ByavoSGR4fHzrx Admyd5Mcroq6D4cU1jmTSziusvTV4zF5rvmzZzfZLUcs2do++y8W7dYfeKX/upmOMf/Zvv0eieu5 6PDQByfKHnVbCrG21VLAwlDtWMrerqXs9ZZK75Mc4qSf7jnaENG3yVYXVN9QV9UYPGRY6Tfvhffo Z2o0hIVHSCSS8uqrfXv3+On0L72joytM9v4PJdTVmwaFSFbv71/isZtiW+1mMLAbEbcbw2/Tbr7B dXY/JNnLSY8XFJ2osvuFBDT5B4dZTT9/80lfcpIxotew/pHnDp0s/fFYz3uieOvLiiOjBzvMtdVX rkRG9oqc/HhFSa2xsQkuzbtftmvYoCkeDDTZhgH2F5puBwN5uxhIEQxTJF9z0jUf5HV1Xuneb7DB 6ogIDjj+fV5ULDOYwettZs5k//6Lf/mb6+PGPAi2njtzvvxKcd/owb9c+HVYv0HGvjEDhvZ11jdV GU3dA4OOXyo/+nrs0x4kDNqGhAEkRDtI6NtFQov4e8q2feMfWfdaZuYlHKfr9DnTcmZupNI2Fj6W 4Sz/mImyr199XM1V+B17+r53pPnHoxbt07qenjT94rmGiEn3DB/z98+4LX3iuRWcs3RnUc7JMqtS rwmUPDlpGO5BwyKtaFhURlGMOBocuU00fIPr0NQ89VVWZubYB6aWqGILDq7dHMhpNPa3Zhw6Pvn1 7MrjRxJHO1JG2t7OmJ88T+JfzOkyy96bVhevme2PJQcsfz+Xm/uhKnb+nJcrf10iXa9Va133LbV/ 82mv0leD9dJ5VKwQE96GibgBJvR2MaEimN5dWT7IPxJJj8994Q2uaK3lRO6nmqs5A+OTXK55Bflh dWo0JKRe/bJrvTR8GbM1s+ytFQXjhzyr1ricJefWTq5Y1Iv6dOVKe/mxr7MKZmmiLjZZbLWfNViK nznmum+Zk5T8eQ5u9QCDlK8NGURySNPEkRG3i4wQWUULJFs46V+37el57whYJOcvXA6tLa93+g9E 4kr0FY2VlWUlV3sM6s+MHvH5rqP1Nj+oY7Va/c3wW/Lss9TcsYPP15rCuvhlff4zgw6wWOCi89eK hooqa58ww8mzjbUGw9hhoWanA+qndKGWClG2xgoSUmWKwtpBebuxAheJFUmjV7rMX9LqHwKs0dHR xfrl4UML1I7woeqV3PChgzUWw2MDB2WeWHy65G8PR++/WPBNlHnQQ2MO73jgoOPFBQmfPJAwLyDr /ZXyHJntUpFq0ROHq7PUOq7edPq7aSV+3KL4DHND6ZNrHpK8dEWlFMeHdzA+6fOSTZw0I3v/gCF9 fymqgrHuGhzUYLUFBfvXmyVRof6X6m2VJlOjiaspqXF07wYVLFWmkXjMh4spKOeeufLh7kt/T8XP V5h7hPlfvGIx2hxBNleTo6m0ylRxta7BWF9TZT9TViaLDIT6Sx8fLQSKom1AITUg20kN8NsNlbhY qHz3G2PTx/oT4eHh2VqX35tTUs5b9BlSTMMlbSyZl2e/FBPboJVt3lTJ/ePhumHLzkVv3WpJGHW/ i+spX1b3U0GfbV8ue/oovtNV+HiPPZzDnqMNV6k18zjOcuzViFRNhsZZsimytK46onilw+G/Pf7H hwIl/o/Q28XBsh0MVrpYksVJ52/5um/0oAtl9UP6hMHYX6gwOQKCjSZrt7Bgi6XposEJJzmLtdou ee7RYWvf/3FwTI8H4iJiY3rA+UlYvwFP/ItG+2Q9p7pS32Qw2a2cf73R7OdoMhpd+oqycoNZam60 GI1Fl01Qv1dQw8/jRgUI4bYmUyR85KTIdpIp/HaTKVwsmVoq+Rsn3Zl7em+F1W4PaHI6unbhw0yl gYP/DTZ7RFBgZaPV6XTZnNxVky26W/BLM2KfWH3MbrarYnusnsMHsO0HSz/b9N99u6Y7HM4Gi91s 4+x2h8ncVGe0WG1NFdWGylpjTb1Bamosr6yF+jazOWP21JqHp3YTB012MOikdTXnlV/KLEYnHRT0 10RttOxiUZ1Ox3FJ85JfNlljN9gbCnRRdXkDql9yNJamplRs3UbPenxYNY5ywZPe22dSnJmcufY9 K6TFOs7FuZxcjlabp7Ebau0F0xJ1+1ZyppP2rFS9ZpnTVqrPzl5VlTjafsBmuV8y6L1J+eKQmQ6G POD1nV0PIJESfciER3ZJh4UhEhL/UYZ2mysxfzjuhPSV2MPr9UtdzuGLL1SeqjlVOGOUdFVC2Zkw R/7M8oVvHMr9m3bEprVPZys/O+laNiplc/WZV95c/9yvY068Hr924/N9+474Wv7wC6+G9crY8/GK 0aP+/fYKtWvAff8oiFr69hQhXqw1ISIxtH28xO0mRIRYQhS+bUVltaWO03BRF5Nd9U6Vv79/z5FD /mK/WGup03FORwN3pE6t1nJ2U3XBoYlXn8zWNpkb6rK14a+c3zHmkJZz+qfP2NoHfkeUuVxOe2Nt 1tzR4fcZMxak5jlsl49vo7PV+zhHk6koKzver3fuSkf0hJeL+vpLkudM/os4ZuL/A/OFIyqI0x/N 3BFRrAnG8jjXkfxjP+Qfc1wtSpW9Kg0amOfM+/Kw39Em6+axCasu54/cMHf+8OGagb9srhuTMmfW 0t0l+w7MzbUU7COQ0ikvPLbcanMC0sTc5Zz5whEe6RlAusVQSI99dI7kw3FogzhU2meg4kgHQ5Uu l/yVk07emG9otHcNDvALlF41WCGINlidkaGBFpsTojKfINpdNQbbd2vizxRXj7o3qt7sCvaXfKwr nvPQULg6YfmBT5fTPboFX65qVAyMGD7py4QnhnTv4m9uahwxoJupsbGmpuFKTZ3BYKitM0D92tJS o8nVhWv88sGxn4vjxjt6iv9dyRgvH4mZqFlfoOYkfWCq1Zxjc1nSCtPlwiw9t+p8qnrsK9XP37tq aIxqcop965JC/a70nUtjK6UPniADd/x36Y7q9A2RF5fZrRVfF+pf3BQQn+FodDizvptWrOHMpQ2v FaiKc7X2q6VZETmZVdn3r7RWVqs1v8RI8ueN/1YcM9Xhbv1+uq38C9Xc0SkxWofVWhHj738QsJYF sAP3cd9LgrJmrRzZJeGYZbrO5hifYM/fnaoFzH4PDt+hC974+Ntlz0398Z2vys1Xe0x2NS60LFjx /l7OBsskVe201Vc22KepNVqro+SkvaCuODfDec92l/MLep0uT9pHMvaVB9oBzXY06J93nMuRnVDs z88ocQXDEoU9GfZVReiSC1r7G7COR9tmbtv++WdDez2Rtmp1dph8cOzhQwX5fsnLnlnz7Ir6eSer toXZ+99Tp9lYPnxn6YGvt72kW7E1zOWwc9bqrHXqPPVKs+P0kSx9vDbon1yT0dqQFd6f00kk456j xF2buEHS9fsgTrhXD4mSevywzDq96zygzMyUHt0UVZ7rdOAqut8Gu7U6B6Z26fzq7G/NSvqR2ooc vY5zPLap5PN3tL3lK0rzN7+UqJH2SY13lZQm+2GrXoeNatHUR12u6oIvFuTAQW46Zz3Zb9rlYWM+ vX+FzXj6tWnhO0ZLerw1/ktxyDdIuX7HKDbope8gTvWJ7HKpqnFYn64QaPz9/boE+V2oNDXHr24h fh+tGBcWYLPa7Ca7X5DUERjgB2Fr6eb/QuW87/RBAyN6RQQFB/o1mGxSO/9pi1RwDxPDKquuNtQ3 SO1Wp+FqQXHZqfN8Zt3Hv8pg7zJ8YNcTcQwnjvsGedfvM9W98s8dO3z4o6MFLzSYVEHIxcvz3yqZ 22TLNnGW7Gk618TFT76I/d3ZdLW0QsctPxs96PmzT0UH7p0xqMZRGZXTX/ttyq61b0ZXfBgW0fsf qyHXNDlqKzbn6NUZ1sq6z1SqRF1T46WDWarsVa/rdZCB0g9/8ppCcvUFRjwFITs87do44lervXrF 42mZRSr1V+m7EARZjOxKW7Jr1j7TxImPDz2U+OCatbUXdicac2t0LnTxEgzbv0pGj9yQPGfO/AXz 4fPhqKgjnJ7b6uKczpozu3dnx5+aueKngqmXDtpf0hdDjnb5+PHCVE7j7JLAWZ2wrF0pNXEBkukq eopoZk3eIOv6fT5MvJAzM62iNCZt1i8NFn294SscQeoXL86wHZ/7zyEf7JA1lB5Ra6QbPuilKirU c3tn9JkxY0af/WP+8mrghDyrIfiA02m3ZKs5jZYzXy0qmFanrk/7asfZ9K213DNx8z6PmvZ+RlOT 1f4dLXt2h3YWbpRKTjgR8Q8R5A2yrt8H6rt5hgnFJw5Otb2uit/3remdrZmZY9fUxmzotWkz9vOm IOypLXsZZssPe87Gu+wFBd8fOxY63T/gwL0yY21M0Kdq7ap1ANTlslv0WVl1amdTveF0TqJao3Hu fPHMomF/mhi/aP2CaYkaW33I9nWvrp6TvjBe8s56RC76RQCFdPS3Hsmm56N6llid9pFqVTDsw7tj Toz5z8bX//nRK5INxw8q9h8wPrPxNYud42r673h3Chf91Nlol6NHWZBCw5mCNyQ7jteXFup0Wh2e wRmrSi1ZiXlau2NrZcXmoqxZupebEv603nK5oTB8dv3l0ijJ+HjsLXGceEfj3PHOzhd/+fRgOCI7 NfLU4AP35gxtMNVpl05d9EGXUcFfyNUFlsR7M96dMiVlx5ju/9Gq93w/vU7rCtyldcxxOS2F2Yk6 rSbDYj2SnZqtxp0Oo7OI/sDv/dRsVfHeiORcjWnghP/MOySR9KtUHhMH2OFfX/0hAD1fRFJsR3/R mtBVtcLc6KSHxwchkeVzem98E/nxbZs1a/Vbb2x94403srY1HLRoU3Jnwgj8kO83VK91GbJXrzYU xJSr1RqH46SpuvqIShev5YyVpUcApdZa3217+elCPaSG+/baJUeDJLIDcUmi6Giso9HlLm5Im1/a +NiTAyGyLl7sutTz4gqTY9ubW3duH8pl67izzN5PAvfE41+FpX+VttOVlDTHemr/4KPG4O1NpyMi raUVdVqthrOZSisKY1L1Kx1NlaW6bL1WYzfXHqcXva3V5zmXLbFI/aMlkpq/UklijwRImuzgRwJJ 60ZU6dMvRkKcsWTrrAHL1BnzL110fFxbY2ywqD74YLTasi1byzJ7omfMiIbdo+cPyxqcERscnL0g K0a/KtycU5eotZnrKizZ+jzU1WSsLYpQKte/FvE+rnGd3RITkiCRrP2zcofIkxySZjr6SU4CEjZ3 VeZLWhe3rKFcrdKt/6Ja/QT16KIvU7VcmtHodFir9TkxYwIH15wYYzxZoNO6XP7YU9oMu7kupsIS k6POnWdz1oJD6vIy5pZeSnKY3rhkePEDP8lMPO4FkQduJNPhD9w2/jctefbsZc76t3ft8tu25fy2 BariDJt/L2vBcdWI4UcVQ43gXWjvhbNCfkrU69JcrqCNtka7XqdfB97ot4tzOk65LPa1uxMzUw4n ymZ0/0Wdpcz2xyQ/9JBPF3kgSjJERz8Q/fmr+r0rTLnbc/sezCoI75+bca8ufqU1JFmyV5+ncR0e cXj//v0jR348b25A8ujlDZsuF9BBSJOlglaV5qj0Wuk5WEeSkPvzuv3sJ5mwZogARNszdpKhO/gZ e9L5JWUJU6de+kylTtRlnJIEfVTy5hiKjigoVCWu+mTN3wc8Uj9q20UuQhao1jqthtcyrZaINXOf mLr+9ORR0gnr+n8kwmggwa06ltGQlFJZtY36n3O7c7L7REfv2bOct31V6Nl/1zBPjVkXo43eouVm Xy6bvSApv9tSiYTb122Px06iLRTDiqbYdkIxeruhGBULxe/GJy1dUnAiNVGNy6TKRbNk+bGDDX97 LPJoE3zUJujxaS/7SdBB4SEe6/C2JQlW0QjajnW3uyRRsSUJ1plXjyxcr3/ZcMXIhqR1DwoKeryr f9qAlUOWh4zEx0sM/wpb32waTwHESJnnPzftz+vMrVH9cBlGePH8UBZVEvwGqYSd0U3y664A1CSO 4vJ7eGIRidE4QQjOBvLUJoQmMMG5mXIFosRZhMJI+VBP0c3IIhGagSoRClrJkJBeyP0UrBJBcBbl uVOQSVEIS8j9FZgSJ3Ca5DlauJLCMZ4ZxdOheGIW3NN9S0w+M51nhtE0GNVyf5QVNZSQ43xzEoOK A6HE4CQrLMW0lTz1POc8N/RzU7WajWwHpqcyypMKwbFp0s3gEhkGQbNgng9GECiBCnq48ej/FlAD 2s718AxdoALDKP6WbZwwnueKAkjemxiCJ48iSoJhEJxu4Zi2d/WWHA+8DkOV3hRTDCWUJAW5NdHi e/JNioTnW61BGAyBYYD7kPCZEeVJrRSFgP80m9P+5VtdCCgjag1OA8LmlTDITUJkKBqD8aJaJqgf fxKjKYT3WbrFZ0kFo0Rpns0omFSebMhSFErKY/k2BIswPFm2rXkAuDyDkSTfexzclYRhhZ7ADobA GXA8tHmdyKN5T6CauxJUhdXDKDGWwGiwBCrw93ezbWFMWIwgGC/fDecNwzAEIYVFgbniFQJ5DixN IGw7rSJ4EO5lLUDmQR7WhhGsBQfgqYvXwOGthdlsIcPSKOM1iO1A8L4ZCcPAtgfGM3WeAQ9WEHCV xCj5EAWfpOAEK2zdXLGFT9w63IIxjlW4GbM0xXsMIktIBmdpb9wF/tJPbO49IxQBwZBEGQyH9iTc CiFpwah56gkMgYDU1iXPE8WVLEYy18astipDm4sYzXoHgLgWKHHNa5SH4xmhWDAGpSHrhhLmLjLi DiBmq+jwCk1qzwFhe+Bj/x8ZnkhaSd854anFGvHwNFwYlNq8Q7BIPHPjWQ4xPFkYMjAahR1ErChw fsE6vt6f+OJN3VgkVEUpsOY4cWfMN80q8TtnvlusEcz3cNFVI5wPz1rs5TkpiKvCuOCJ0X15pjhJ kWg7szxYQdC8wAIX8Me9NC0LveQuBIN4l72kLzxVHJXxPzAw18poCDfLj1fFpM8LnT/CWyRDuQnm gv6aRTKYRyRDkpB78T5BI2Atr4dh3JlW8xS1e/VWPYb1miCSxiA7kxGUEmWb9TFyQuAvJJ/kuf3h mkKzLe1dvVVvYZQIcY05kOXJaPAWulWt098dHwgG4/cGHIMWkEn2VsQR/GwjvNogDjZOHKPcuSau xFA+J+/enCTC9getAB3brCnht2wMPtG7RR5t5RhB2VOHV+SA8zCsO5GmwDDI0vlwhSsJGoIQ7H4Q GHghj6DEb1+QaeAor9IgwW4WIkhY2+XBijiwBWEYXpuBQ16ENYcVSkkhkCPzEUSJkDjJazNQGkIJ K+gmGEoIhro/UrRW85zz1BsCVxmWYSnB1aEKEnY9GBmh91Ne6gn3oUcuATPAXnfYpp5wH95QPQFD eJeoJ8DSu1I9gVF3v3oCMHQS9QQg6UTqCV6o1dnUE4Cpk6onAJkPqCcwunOrJwCfb6gnAKjvqCcA rC+pJ+ATt++pJwC0r6knALJPqScw2vfUE4DZV9QT/NfJPgPVN9UTgNvn1BOA2ffUEwDax9QTGO1z 6gmA7JPqCcDtS+oJjPY59QRA9hX1BED1HfUE/xjSF9QTgLNzqycAYOdWTwDATqyewGhfUE8Ays6r ngBwnU09gdGdTT0BiO5+9QSAuAvVExh9d6gnwM47WD0B1vmGegLHyd+snuitwHAlxmsChvDnKArB ruH1oc1SAZ7mBF0hbWqDODfNl2bkMxUe2USzsADF8DYeNE/sChBID24kovitgoM7VlyAk8wdJC5o teZm4gIPd1ZAkxUQOEUZ5B6qNs/yJdyCGm9xSRsxvCM5/G7m+02I9eDUpNuncS9Gsqe9xxQPvpur GDwWCpQW1zKSWYb6zcT6Vhq0YCoElYeKEnNF5R3CCebFI2C8cKBaZQUII2uRFYhOgxc5F25I4Qh2 C3Rtz+B6rovbLjpPggEfybcnSMRLjzLE/cp3N4MzxCM0CBA1xUsm08oCF070cDFquZhqoj2fvFbe AEMqkDfcRCHRMu1tbimsIuolFMRJvjpK4BguvowFYxqrQCEeICzqzYZvnWmBl4nhDBOsfIF44o9n 0BOw4985iolWawQxVyXY4USFWF5r1jP7nrDqCSCEAhyMwL0jQTt+EsnPNwN7fbtx8+ZaLvGFKliT ntUtFjPExQOC1esdhX/zNkRB5BXfhjw1rxmE1s2pe/OOyIeybvxtm4tCu37v7YtlvBReLfGXYpv/ 5Ic7UNz6Nnb9CkyDvhghUdx96GGG4wzKXnfYRhR3H96QKA6W3iVEcbD0riSK4zRy1xPFAUMnIYoD kk5EFMdptNMRxQFTJyWKAzIfIIrjNNapieKAzzeI4gDUd4jiANaXiOI4jfseURxA+xpRHCD7FFEc pwmfI4oDZl8higNUXyGK4zTpk0RxwO1zRHHA7HtEcQDtY0RxnKZ8jSgOkH2SKA64fYkojtO0rxHF AbKvEMUBqu8QxXGa8QmiOODs3ERxANi5ieIAsBMTxXGa9QGiOM6/aa2zEsUBXGcjiuMM0smI4oDo 7ieKA4i7kCiOM+hdQRQHO+9gojhY5xtEcYKklcxvJIrPVHi9MV9ABRe8Yz7KTZ6iaJT1et28d/1o nsKEu9+t7+Ect5LBKRq/3iiGpMhbJoOPEpDB/0gaIh9L7hwaYos14tTv3/hW9lvgAqOskkBo4Vu5 e7VHAWzj13m9Kvh6pvT/mR1+my9gv4Y7Lfqi98H8215xir3u5cYtVVtok1D5tgjUXi97b6OUt/eO 93YIpB5e4S2Q4hkad491MwUR451F5M3yXizQG9P+b/xi9pu/RF78ffyir5gWY1Pz3G/P7QS+K+jX 6y39XoTt5gEQELYhSuFQFaNuDldgWDt83ACxYRA4gtB/R/NlAqdQ1ov3KrizoI92iLFtVdvpzOOu gr48gG4aDnoocIQfnT+S/E1ihBK9Y6JuqzXiUVdsaYSIu7PY0m4vvIn+FRBhZ30VOKEkGZbxnlLU TRtuTxLTT9wwTwQWb9ZuBGuNSu3RrVvzgt+HbM2/VjtaQZD80qLb3PPR0P8FNYdSi2VuZHN0cmVh bQplbmRvYmoKNDAgMCBvYmoKNzQ5NgplbmRvYmoKNDYgMCBvYmoKPDwvTGVuZ3RoIDQ3IDAgUi9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V0JWBPX2k5YZREQteBKXElUktmXagl1365a i7W2VlRAb/ujCLYuBRKx9WrdsK1WLWq6Wtt6S7WL2iKxWlfUtLUWvSgRgiCbgUASss5/JgiZaLDy PNJr5crzyJmZs3zv+ZbzTfKeQ4oAEsOIAGJ/mgvxi/wl00nBwqX+Kf4ITYtpmhA0/17UcodAIUiQ 5I/gOORSbn6e5P9P/5mCxf4poEcCAs+jEAQnwQWoRbbUcoyFQILRyf7PgB8gA4RAOAyEQUiExmhQ wCCaBpJNH3e/p6kLgbCUGGX/OUBwy/GLBCNjwTgwLEBIMRg1doE/JIAFUaAnAYmKcZzGBQQuhlDw O3aR/4vCYBEkpiCCgkmhtygKFqM0itNCP3AXxiAMIoXdRLgYJ1CKFnZnnxMEqMGtGsIWYRpCEWGA CIHEJIRRwk6gPURDMIwI+7LPaRLFCZeuCDEN0yQhDBKB1jBOs62jQGscwxBCKHCUIQJBHGKBGSRJ hBL6ikgxgbAdNDUjaMdjXExQoN0dLCRF4MLZi50IuOUAEYwA7cMwEAZm5xbChV3ZwRAYp1yKnH59 2bs0TpM0JezFnZnmHjh1OdPRxVk1FBRpEkIAYEcRzDfFbcUZt7cICIhREMLB2OfuQTEY4+rAWTNE hMIEMBXipdiJ/igqpjBB7GT/2CEvNusBg1y0E+gUjKNzTtecZpy67qfsTgWK21VPAAeCKYjmdspp 04QHBrCjWNwohXLnjWsTnOG5CgkDHeAoRBFcQ3FaWoSIBiaDIwhHXX4iSkwiGOzSD0cbXIPpBtpT wI9ZK4DBTMA4V/Ecqbl9cUR1qsYxKaAmsD12KjAxQtDwn09qF3e67ypCaUpMIw41j4kF8STFH8YQ Gvg2dCd6OS5JCrkTomCcgO65BKbCuWxu64hnQ+4ENJQQRLGxBYDEBAQ7aFMsGznBXzLqWcn0cSP9 JTMFMOIvGS+A/SUjp40SUP6SsZKxSf6S0dNGjJBMS01MeDn+1eRUAYyDJslJry1avNTRAJSTU5cK 0Oho/wmjBSt2xVvt5do9Ty0MDw/vq5SZ9JcOZUUUeVy1ehyfH7p65DWP0JKRT/4wkbcyJkjnP2aC 4BmHfBjVIh8pICi6FfmItspHtCLfhwMKtLaEEoap0LyRH5FnXzB3bqPFeNqokPc4dqPwkPr46t4b Z1tjvt+37wme/eXwQKekYC24IykG5poiWpGUbquk9L2S8p/knWT4ew+fqQ/u2WjW+tTWaysbfAcM 0ny3OzC0l76hLiAwmMfjlVXd7tk99NdLf3QPDy/XW3qPjdXW6vv58dYc613ilJugW+RGgdyQe7kR tI1ysw3ukXss7wjDz1cVnq+0ePh5NXr6Bpj0v3/3SU98oi6426DeIVdPXtD8cq7rE2Gs9KVFIeH9 rYaaqlu3QkK6hUyaUV5So2toBI8SnxIcHNRvshMDibdgAOs5SbaCAW8rBtwNhsm8bxj+ug/yOttu denVv85kDfb1yv8pLyyS6k+htWYDo7f89OW/PQ21UTFjgKxXL18ru1XUM7z/H9f/M6hXP13PiD4D e9pqGyt1+i7ePvnFZWfWR77gRELBLUiAt5NYK0jItiIh3dh7UvbRUdM2rs3MLEZRUqvOmZozeyuR srXg2XRb2cdUmGXzmnwpU+5x7oUn3+efzQ9bfFRuf2Hi9BtX64MnPjE45u3PmB09opk0xqY5UJhz odQkVsu8eTMnDkKdaGioGQ2OCAiileiCQm1Ewza4B031819nZWY+PXpKiSRSdWLDdm9GJrO8O+tk /qT1ior803EjrElDze+lL0hI5HkWMcrM0t1TtdGyuZ5IgtfKPbnM/A8lkQvmvV7xn6X8zXKp3P7k Mst3e7tp3vBV8xOJSC4mtAUTfh9McFsxwW4w7coo6+cZAqVG5766iSncYDyfu1d2O6dvdLzdnqg6 G6CVwn5+tdLX7Zv5gSuonZml76apRg14SSqz20qubphUvrgbsTcjw1J27pss1RxZ2I1Go7nms3pj 0Yvn7E+usOG8f85DTU5gMNTiRTgFkCGtIGurF6FuvCh+RIbd8BUp/dnLBJaDIvXKwIEqqTVwoDSD GTywv8xY92zffpnnl1wqeWtc+LEbqu/CDP3GxpzaP/qE9bWFsZ+Mjk30ytqTIcwRmIsLJYufO1WV JVUytfpLP04t8WAWR6cb6jUz143lLb8lEbvFR8DtjI//Cm8bw09XHOszoOcfhZUgDnT29ak3mX18 PWsNvDB/z+Jac4Ve36BnqkuqrV2CQAVjpX4oGvHhEgKUcy/f+vBQ8dvJ6LVyQ2iA541bRp3Z6mO2 N1obNZX68tvael1tdaXlcmmpIMQb1F82YwQXKNwSRAiwqOOtLJpoW4MI6i6I7PpO1/ix+nxgYKBC bvd4Z3LSNaM6nY/ImPitJYl5luKIyHq5YPu2CubTcdpBK66G79xpjB3+lJ3pKlyh/VXVI/urFS+c QQ/YC2aEHmaslhx5oEQqS2QY47k3gpNl6TJbybYQjbYquCjDavXcF/3LWG+e5zRyn3uwZDuD5S/h ZTH8BTu+6Rne73pp7YAeAWDur5frrV6+Or0pKMDXaGy8UWcDNxmjqcrCe/mZQRv2/NI/InR0VHBk RCi4PxHp1ee5f5Nwj6yXJbdqG+v0FhPjWaszeFgbdTq7ury0rM7ANzQYdbrCm3pQv5tP/e8jh3tx 4bakGSSb0rWSZqBtTTNQd2nGMt5bDP9A7qUj5SaLxavRZu3cCcjEq6hjwP91Zkuwj3dFg8lms5tt zG29OTzId/msyOfWnLMYLJLI0DXzhoBq+05oPtv229GD061WW73RYjAzFotVb2jU6owmc2N5VV1F ja66to6vbyirqAH1zQZD+twp1eOmBLkHjXZE0EQ7g47fWH1N/JXAqLORPj7/ipOHC24UapVKholP THhdb4rcYqlXKcO0eX2qllsbNMlJ5TuzyTkzBlWhMOM7cfdRvejypMwNu00gS1YydsZuY3Lk8jyZ pa7GopoapzyawegvWLKS1bIVNrNGrVCsqowbYTluNj7F67d74ln3kOl2htxn/YHOx6EQntpv/LSD /EEBEA9HfxHAQfN5hg9Hnuevjjy1Wb3Mbhu85HrFxeqLBbOG81fFll4OsJ6dXbZo08nct+RDtm14 QSH+7IJ9xfCk7VWXV7+z+eX/xJxfH71h6ys9ew75Rjju1TcCuqUf/jhtxPBv30uT2vs8+akqbNl7 k7l4kZb8iEJax4u1NT/C3OVHG19KNRSulUvD7RNSDigthmyQ92ly1HFKpjgh0ScVBF/GGDFtY/Fp rTRm+qxdP0LPjxn7Zr09P3l29fmYt5OlzEEERVb9pFUymau1UlmaxVSgjYhTpjO22ye2hyVLM2RM seY00LLc64uVlkZ4S3XUZC8e3GWk0D1gvL0BB2anVVQZtYyMCbuRYK+1STw9PbsOHfCm5UaNEaCw WesZgFUqZyz6KtXJCbdnKuSNhnqtQh64+tr+mJNyxuaZOmtnD/A7uNRut1kaarLmjwh8Upe+MDnP ar6Zn00qpEcZa6O+MEsR7dE9N8MaPv71wp6evIR5k950j5lqZ8z8lbx/MfxJW8/WNVg6+3p5ePNv 15lAfKk32UL8vY1mGwhY4NJksVfXmX9cF325qGr4sLBag93Xk/exsmje2IHg6fiVx/euJEODfG9W Noj6Bg+e+FXscwO6dPI0NDYM6ROkb2iorq6/Va2tq6ur0daB+jUajU5v78Q0fDXm6c/d4qbh9tb1 txWU7ubpiAmyzSopw+sBshEpY91eGp+mv1mQpWZWXUuWPr266pVhqwZGSCYlWXYuLVAfTD2wLLKC P+Y87r3/t2X7q1K3hNxYYTGVf1Ogfm2bV3S6tcFqy/pxapGMMWjq16okRblyy21NVnBOZqXiqQxT RZVU9kcE72ziqB/cY8ba3b73pJrLvpTMH5EUIbeaTOURnp4nANZSL7rvUeYnnk/WnIyhnWLPGacr zdZRsZazh5LlALPHmMH7lb5bZ7xX+vKUX97/usxwO3SSvWGRcWHaniOM+fppSbLUZq6tqLdMlcrk JmvJBYtKW5Sbbntin932JblRmcfvwXt69ehWQJPtDfr3/VdzBOdFx86ml9h9FwweDJYrsOSI/Jde l1s28X36jjDPzt73+WcDuz2XsmqNIkDYP/LUSdVZj4QVL657Ka028UJldoCl9xNa2daywQc0x7/J Xq5M2xlgB7HPVJW1UZonzTBYL53OUkfLfb5gGnWm+qzA3oySxxv5MuHWtHHoPknYw0EcO0wNcgjp qEGZWrX9GkCZmck/sy2sLNdmRSVkry0WU1UOUO2yBVWKHwxiclpNeY5ayVif3Vby+fvy7sI0zdnt y+Nk/B7J0fYSTYIHsmo9CGmLpzxjt1epvlyYAy5yUxnThV5Tbw6K2ftUmll3ae3UwP0jeKHvjvrK PeT7pGAPMYr1W/4jiFM9QjoVVzYM6tEZBBpPT49OPh7XK/RN8SvIz+OjtJEBXmaT2aK3ePjwrd5e HiBsLdv+G6ic96Pap29wt2AfX2+Per2Zb2HfvnARMw4bVFF5u762nm8x2epuq4pKL15jM+0enpV1 lk6D+3Y+H0Ux7nHfJwt7OKrudvbquVOnPjqjerVeL/GBbtxc8G7J/EazQs8YFVOV9glLZr6GvG1r vK0pVzIrr4T3e+XK8+HeR2b1q7ZWhOX0lv+QdHDDO+HlHwYEd/90DUjD9Naa8u05amm6qUL7mUQS p2xsKD6RJVGsWq9WguSMHPfJWhHv9quU28UKh+6TgT0cuFuH/MdkqUqbkZJZKJF+nXoQgqAl0MGU pQfnHNVPmDBj4Mm4Mes21Fw/FKfLrVba4SVLEeTYKgE5dEvCvHkLFi4A74vDw04zamannbHZqi8f OqSIvjg77VfVlOITluXqIrCa38zPL0hmZLZOsYzJBtzanlQd5cWbLiEnu0s6cfg+SdjDybO//aIw xXLT9xlxWYHajqziS8LCfE+oIiN21HdtyLwmlc+atUO+oe5ruc22PXvbzt3beny0ce2mLuNlJr1i d51k6ND8why5DCTY2tOHQGLNP5k1+/DyxltHeTNvZuXMka803tRYyqVKmfd6JVPrPd6DN/sQ9rl7 qPdJvx43qPfJuh4O1F15deOLzp+YYl4viT76g/79nZmZT6+ridjSbdt25PdtPsjzO45Q1I6fD1+J tltUqp/OnfOf7ul1fJhAVxPhs1cqX7VRIWXsdotRnZWlldoaa+su5cRJZTLbgdcuLx70jwnRizcv nBonM9f67dv4xpp5qYuiee9vhoTuPgPBEbi9P/BJ0L8S1rXEZLMMlUp8QcpxKOJ8zPdb13/x0Wre lvwTomPHdS9uXWu0MEx17/27JjPhz18Jt1tDS31EMkbvuyXBml+rKVAq5Uo0ndFVaoxZcXlyi3Vn Rfn2wqw5ytcbY/+x2XizviBwbu1NTRhvVDTyrnuc7f7B1v73D7z2x94TgZDg4tCL/Y8PyxlYr9fK l01Z/EGn4b5fCqUqY9yw9F2TJyftj+nyvVx6+KfpWrnd+6DcOs9uMxYo4pRyWbrRdFqRrJCiNqvO Vkh+4LEnWSEpOhKckCvT9x3/feJJHq9Xhficu48ocYRs749gYztL0gwNNnJwtA8UUjav+9Z3oF/e M5uy1ry7aeemTZuysutPGOVJubPBDPx81mOgWm6vU6xZU6eKKJNKZVbrBX1V1WmJMlrO6Co0pwFK uak2aF/ZpQI1SBKPHrHwzvjwBMej4t2iQ6H2Rpe7pD5lgabh2Zl9UbCsLLEXd72Rprdmv7PzwL6B jELJXKGOfOJ9OBr9OiD165QD9vj4eaaLx/qf0fnua7wUHGLSlGvlIPyY9ZrygohkdYa1sUKjVKjl MouhJp9c/J5cnWdbsdTI9wzn8ar/RbigRFpQgkyJwFtBibUVJebupX5IpTr1RghwQ6NCafJaIU1f UHzD+nFNta7eKPnggxFSY7ZCTlOHw2fNCj8W82bXn1fU24K3WBmLKitCvSrQkKONk5sN2nKjQp0H 2xt1NYXBYvHmtcF7UJn9yo4Iv1geb8M/xfvdfPuBo0R7f/sRCwXMX5W5XG5nVtSXSSXKzV9WSZ8j nln8VbKcSdHpbFZTlTonIsa7f/X5GN0FlVJut3siz8vTLQZtRLkxIkeam2i21QCDVOalz9cUx1v1 m4rrXvsALBVo1KtuvqTCUbq9v6Ta+ltKwty5K2y17x086JG941r2QklRutmzm0mVLxky+IxooA5Y F9x90Ry/X+PUyhS73WerucGiVqo3Amv0OMjYrBftRsuGQ3GZSafiBLO6/CHNEis8Ed7PocLpbr5E xDGkvb9E/P3r2iNp+tx9uT1PZKkCe+emD1NGZ5j8EnhH1Hky+6khp44dOzZ06MeJ870SRqys33ZT RfpAjcZyUqLJkajl/KvAj3h+T+UF/e7BG79uAAdEy3e6OIa383e68YGThlz9LgMNI7VV21VHVq4I Dw9flRTd1zBVfiVclm436L9Z9/bu/T8Mnma9/O44sDSVqxRKqdyjhxbk1jbbaeB7nx65+uq2gfwZ kYJQN5QAHKPamRIQn1RRmU3839VDOYoe4eGHD6+MU6ZfXOV/5dtq6vmYjRHy8B1yZu7N0rkL488G LePxmKNBh93JicOPspxYi0ngLFmllfUDbqtJwO5MYld0/LKlqvPJcVJUwBcvniM4G9m/7q1nQ840 mqqyMHJUyusePLhfoJ9TOrQljoD5JCG4FenaGkdgd3EESGdYM7Rgs/r1uls62i+li4+Pz4zOnil9 Mgas9BuKjuLV/Ttgc5NoLBcRwQXO/xz8Q5c7D8Y5RAUg6eISDmFgKQS7qotJpIlt2EUEUOMojAqf YBlOIIlBMYxz15vlWEEkhgi7ixBUjFDg3gD2HkFACEuxQsQYBmOwcLZQBENilIYIlq0FuoLYMuKg 4qFiGsFJSugjAsKjGErioCUixnEKp9naICskIBpr7g6ihMFNNC6auLs3B/8Mh0hWDk/QR1NvYPCm sR3jEQ6BEeHsVJbgRpIA0p/gxIQoywrDgXDCvqBEoTjNLSEtpVBRC8GLJa3CQGxWIxTGMkEhMUZR EEreIYy29vSBlAc0h4BZdlEfAtFiEugPxu7oT7hNFPtKszQQhUAAIBgHB+9SMMtQBUqCcaJJnNYf P6gxgdcyd9KgJEDYZE0+7HxCMIRxLSOQLSIIBOFArYiYAm+yhIMkCLQLsxoF9xAcR4SDWXUhJNFq c2+H6mgEw1hCYUtlTxF5xw5wlnoIhkfYqkAsHMw7a0CUGKExhAQ1AWiShCjUpa9ezr6AXDioTOPc ugOdz/2cRScYjrQskdBh7hQHGDDPllacvpwVgoELgLdeBBV6iHAwKoST94pNkTAM5EOaJq61efFw sB6b/KmVcTlz8xBmEVQgEJTkDuArwoBkOOJwXmCsrDTgpoMBS4O2wHhiExxU5+YZZOuJCZZz6Trk nZvd3FoGp6pTbZznXi3z6zKrToFaat47OThFcGAMELEZGYrRd0U83BF0UI6kgSKUZvml6H8zTKCw GH10wsQdaThhojs7WyxnSYiJYBBESAR2sdsmyjYJUy6u6VRna9GhOfBzDDSSbY/REEW7eMmfG2vL CO6M1Om5nKG43sYJAxwwrkPdY9ruIw4HIclSk2HHxHFs/05Iwlxnw9VPWoBzI41zwt2349wdweqJ 5W+DmzApBmt5ONucaArhLvri+AQbMMDLNRcYp6qL6mBETGKQIxtgPQeDgBtgzXGilbDtEmBBB8C/ UfeuGshmLMApUbc67M9CQgmaai1OYDTJbtTgULuB2Fxqt+PSyeUGaQR0z2ULtdtxeV9qN4LAjzS1 G8j3N6F2I0Azf0dqN5D7b0/tBhgeE2o3QPIYUbuBaT121G6A6TGldgNkjzW1G0GwjkHtBkA7DrUb gO1I1G6Q1Hc8ajcA3fGo3QB0R6N2A8gditoN0taORe0GgDsctRtg7pDUbgQhOxy1G2DueNRuALqD UbsRhOpo1G4AuUNSuwHujkTtBnA7GrUbQeiOQu0GUDsKtRtA7TjUbgSFOgS1G+B8vKndAOBjTO1G ULgDULsRltPwuFK7AbjHjdoNID1m1G4ERf7+1G4A4u9O7QYQ/hbUbgRF/xbUbiDnI0ztBtJ1DGo3 QoHW/z1qd5AIWABIBMlWaVeOdhTGHvzJJXE3UbcpGoMwYX8Re8YsCju6hh86i/spDou7pUtvEYI4 eINcdhdKEAIax5vZXewlDMFU8znD3HJzteYzh/96uicKoa3SPZvQUDj7FHNAAWWUPdbkjvjcsqOO E8dfTRRtxsEhikaLUDGEERT1qHG8m8cdxlbFMYQmhZEimAJGTbtSWXuKUEyMUzTF7SDK2cpJWnXP wXQK4OcC4B7yvJPYyGVmckS9m82Mw3c7+YOwmR0GhWMu7sFePsLugbA8zvu4B/fk8EUuh4pjFORa djlgnGVtwgL2B8h292HlmOOcEfbs8dRE/wVDXI8iJxxcSk5/TUeRI86jyB1bY9hpICE2IIIC5Qi5 TZPU6tMHnSTaZYZwEgGhVIARYphuOoUcOJmTMI47rEJwb6FJltaePmgUoICH3yUOCNMCkGMiZPOZ 6L0dJ1VjFMLGaxQBLUDY7y6KAhaNExB7pnMU8GgUIRwLA1jLYGC3YF1wRHkKYUMFQEc3ndzNegcC EnHHUdot5QhOmVtH4HA7iqbZoQkgGXAcYT92EIwEPiL0YinD7HnpnBLL/kbEJAqzh2EDr8JoBAWu 2vy4vygKCANRFLv/AgQ4CGkiHBNisPCSKOt1YghHHSxvmATuR3O68QUlCIERilPNec9ZbwB4CsIO TXCeDhThCOvkMHet43rporscmCBdyo+AM//ZWteyji26a30jKJfy/9a6/611D7bWte4eJEa6lB8B 97jvWvdfMPM78nDMPEhEkfd/UbhnfwZ3Y01/thFYkhG4Tft92rCVzGk7kcBKYJJ9u4kUIY4i9eAb g1rbMvYnWxzdboppFZ9TZpjNAcBCgTn+TgHi+JMbTmHuzC9Gt21+/8r9Uo7NgcCB2L8D49j047Jv qqX31rY3Pgr77lCQY+CPzL67Zmk4vudIiFCKVa77LXbc1aJ5DXJryO6V4zauPoAZ/5Xb8hDHYDhn I+2fbQ51tzD8P5gv9uRlbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjY4ODMKZW5kb2JqCjUzIDAg b2JqCjw8L0xlbmd0aCA1NCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO19WY9u x3XdQywYaRsBgjgJEGT47OShW8D9UvPwGtgJkDfJBPIQ5UFombqKu6lQwwX471Nrrb3rnL4iLymL TuLgiBC5uurUtKfatWv4vryFe0y3gH8cPL8+/Mcf99vPf/3w5UOa84b/vxK1HMLt5SHVGt5g5L08 vH/4b7cvHr5cNbSw8t6VGuL6o4z1n/XFfc6musftL3/58KP1D5qMYZbVdhplov17GSPkfvvxf/lU 7q9+vvo27hn/Y5/P+Pn19p8+W83E1Wy/r0Y/+/wh3OLtHXozw73OWW+t3Gdc//3s9eG/P/7R00oN PZb0+I8Aa06lnVN/8PSu3tuopTz++VOe9zR7evwnT/EeY5v98U+e3oV7X7mpPd6IQ0upn4udKvvj pxhX47U//tmqIfW00L99erfSegnj8Z+hghTrqOfyf/EU+z2FEk/Nnr7801X97CH1tqpfqbPOPsc5 WcVGSI//eCXGEkro5/xT6r96Kr2A+P/js//68FefLUZREMhA/+/rTvmEUDCfgvHDJRnhPmqsbTHp d8DiZywo762MVc/KCrdf/c3D5z+UKNSRKAotgtFLFOYSu6NktX7FUsb+c/2xejj7+Q+TxAf+uYiH HjvONxZfqN5YL9HzQ0mOX4Cz8EJVpRwFfVt3My/+p7rAst45Vup/PC8yMaGHYiMp6dTfF/1p/bX+ lMa+v8H1GNObfvAzr/zl4fOHVJZi5hA7mFkycB3gXunASbhAeccgG1cHwsqZgyXmwjHzq5qBwyRm rc1K1IScTgtSy7zlFPXVWDgOYdQay7QSHV9VlmhhLEzrkhpLd8pXi8DJSrTViZxLYInaFm6VX82+ cBbu+CYGK4E+5l5Qoi+y5EKKLV1Mq95RSR/YpzFLXZRZ0pbyIvECIc8lipGCN9sS1bTqWlI3Ul6E 6h2UnnNVEwJJE1f7KeWEKn/4EG/4Z5VNoaeVPkj8EAowvw9h1bMqIl6jXbiq02FxOC3qs0RZXy36 8SumOx7Ay2gHqGBe1F8oAcUlYgsX4IzUClSBUH6xm/nAa8SOykZd+ShVWB49QNNqaXEH+aUvXFG+ 4Es0HUpSGvOD52f0FEVh0Fd5tZ+r14qmM4qGjPK5Kj+irxhf5vjwJf5cFpv5qfuok1FlIdQUm/JR V8SoQKQlv0D8MjE/ZuGFgqPQ9eWzcSpHUA2z2pLsW4QZYpvP4HxXXyLN2JJXIIwpJ+UX0dLQGp/l l6b8JqosRPpkb6lq/JCOXDtS+SXGF9B+Ff3Z6zpvB/qAVOMAJCRG54DKgVbBeMEWmri5EPvFtor3 0HpQSIHksiBk5cmt4am5bZSP8ml4/ZRAUjiJA+xVQv/Ya/Iy1kOCyS3lWynjZVL9KYgDC0WvX2gc EpApIVm9Mgmx/lNuOL5kcplgCzd9KG3kCyUQCiEJrdIQyi35QrkmLzLKNJWn5jZqSFOqaZBxsG4O U+8qNXAcGoSi6lXb9G8cicq34hpMxPG35BK66pquAbQFcfckTE5C1u4yT8uqwfInGEpYtYHxjEQp YtkR3TKtnBKHSqyxlMQJaK6JZM0ZsonLrC/cVFPDN2bv+gmjrIw3ZdIx+O/fQLRKkn3M/P6U7tMO ubA8BPUILfe8x7A8UtWa9M1uYVIqUOdMZkHKzFtqyqTdQDtQU9qKMjv1dpFlzXxDbaxR19jUK5bz XkG3ai2y+avF2kRNyHylTKDOSpmAdNd6WK1aXVKrZBLlS94yWyFkhprnm86xlGQeNUGwqTM11a1T lbMC209uHarpHPQfM7mskqHs+ZISlF+oqFajQprM78jPsHXd+rcQ+y+r2Tmqnbok3crQ6lldS3AX qqLUaj+KfrSapFo2q2toCD07rV3GmrCjafZHfZVUKDWSgm5patYMQ7qRwkLTUbEZBO2W4qVoP1lT OdW/7a+46nIB/XMaS3Y5Mrqd9CqID/TBaV+L06aCyoOlwkG70p0jZfOmpENyl/IY7zLzm8uOtAey 4xyft6OHshcc/dIv9BceSzV70ZBOGxHhGB0Y9QzwiF8P8L2hxjHYIryqOsHjhhHNvJHmSNi1tcS8 OWJ+A7L8caPnqPpbxJeQsBYlrZBBYMmYEKigfHGoRbMRGXUl6XVSa27N1DJGZqgJuUSjnEZrKKnf z2YZ10L05qhbfp2SeOHoGjGGa8SoB9dIw2GUlR8BxDFselOi0Fs5yJQ1YLe9TXM1KKG5mqjuubhR A5i6daWlvn2Fphm8AkHqMb8388Yw7zfaBfZAqAqRU13fvjjXoixoSyccj2/KVHvESM/iRmU/xSXM lRqfyYfjdnwD/cG4XszjApZUG7L6nm1OAn6DrG3mE5ed2uhxCfddat4OLpiWY+wzUGsycTrG1dU3 VOsYxMX6hOkJ2L5Z/e9BYyRtLRgjivYqOwJKd5+Jo7BkqzdoPOS5mzWFHeh1mB3osi0oX8a29l12 hCh6frZ8lJIdQU20+7A4PYc9G/Q0vH36yOxTalv/O+eQFh1V+xL58JZUvrAltA83qNNCL4x8+th5 9y+z/6qfFKs7tcL+sExT/1hXw6hLd0pVpml87EtD+5A1oRaOfNI6H1IN/AbNo6+9OK16916TF3lu 693LpmApG5nfgXa5XmApWn/WZDMn66+bwpxDXS4kh+x5LpQSjUyyBA8P+EAfnPashbShlMBZ9vZI O4RRDAVH1l9MjBoFeUfelHnITqWcNOc4KeM9tP4ivTdJNWoeRukqbPQf1Uc6xHXMBX1sSsiiAs24 LW7nXCNUN+rbYiOUqZpGcJ6OULfUjtBtrjKUhZ7Njlkqy3OMUzU9m90anEfg/A/Ob/DEu816pAdn BPKD/Rcyrcg+aiy6O+cGcmtIq0nlEZxzfTrnuiQNdqf34VrD/FyP8jk6fdP09uFG9SlbDqeyc0ZL w+mTOVJxFjZrcK5FrSNm07oRTWuT6EObNp1CuYvC0toRrC/FKQTUOXuyr1N15U0r6vqYPirzMPKU XNiohdIhK6W4rJBCQlYT88mXTcsJrSvj4FWZm5eb65XjU3nwbcTkvI7FpSKaLGVhk6Xosuy0ogRG l1VRtZeD1r05/XoX1czqTsufW9Y3L2k1htVfXQKoId2lGnpnWoh2S5QWTuEX71n2kiP3jQ6/Zmgl gFR6kyxjtp11JfcIh2YBjCapZ6QH4yvsARE1x/IpceYhQGKHeRGJdJx7JvVvYjowVjnDPIqUTjge 44OUbzyOb6Cdwz2Q6WOkzgvZuDd3czb/FejDg+OyU+tG7VRquFUhjZ0L4gkiPgj9gifB8OrPgN8x qugAP07YPYRR5CHEuUtMeI9egtSv3UugR81KYMzdSiDdop+knWHWSknCGnMM0ILfmqSR/tQvBCIG NZXjmKIVPNCB2L2lTvtymiWAfz5pa1D/pMyjzWlWN0Vhcd3QOPKhfyjlnuOY4+DtnIfsyLKljaLQ s49xgjNxvEXiHKnJ+UQob6SZh9+SBog9DNlY8HjEbVlFw2yUNcvZTWc2vd+b9KFLrzaimcQJ2JdJ rwlSaSgBzS1fk/oIHs8cNop71TW31M4tnzP3o3xxqZ/0D9m+zfyYy2AkZQlhImU9Z5nbc5hFFC8s 12wGm/QSYEm9LdZAvap7LCxjVgBWezJKwe2LOGymmFEcSaRRdamIW2qi6o9FNJTUge0RApNmkhUL 1VvFamfSAw1JVGF+9F4znyOB5s0qWkI7J+Ox0s5puoZ5ZVbxiyOj5wbbMumlkp7maZHK1e3FpOfX 2kHPZrSXfQV5DZln2UnPdnPkNtnlgd/KEk9R1upMafs7UANrn9Rmn6K1H5yGLpEfKJ85qbZXm6cn bXwe3lqekln3SYy72WWynGSSfKZMCtWNDm8TquLSlUxzkMHZYtOIPaF05njQMJEfwfRRiHJisZVY XZJj8pooMaVu66VWyX3abKaZTRcuXoo8oHWz8cWtk5RIUiL2gz7sC+mX0kb10IM0nHMclVDy/M+v XahrF+rahbp2oa5dqGsX6tqFunahrl2oaxfq2oW6dqF8XNcu1LULta33tQt17UJdu1DXLtS1C3Xt Ql27UNcu1LULde1CXbtQ1y7UH74L9b3cLkyJMXRc5mq45jns6uAnb5l+p3ukkPnx5hLpmonuDGa2 e9IN0v/8FFCy1fn407/9m6d36d5aC+nx9hTD4+nvDwc8pX7x5Og3K/Hx1+vPVdkcq3iq4XwLs4DC MSZewEtmfzZJThjf7Cu5f4ch5tDuisTdl5RyjD95xM1SG+Vf7y7/Al1+xb9+u9Ne8OdPORhm//IY 4U+eTrW8HR9Y1WrIExfuPga4b1fX9FLamrkQv0K04bvcDlUhBeEREyReKKGquBGXD8A1TzpThuuN pRbqN9ZF9PyQomNc8lvzInGKa7ZkKUcMzwCzjZeNlyagFHvDuogYytRfk5uy0Xv3Imy9s9a5bWC9 MuytGrayTjr09vNvu4mLWE+BO16WZtc1y5zI/AfqUbkvL+mNKiEJF277fTVIOfsr6dJoA+qy2iit lgF92fiLJ8CUe4XGrBpqyumQpncddb6LS4Rvn/1sVfkrfBRbGOlNNT9FMpb3j8+n1FONvzjgL/e3 p8aPFvO9nRuEPtT7ot/4qEGr49dHh377NO5zuWPjm3r566fF23sI6fu+jv0JrUltTac1cDMttWj4 xbE2u/TNvul7KlFPJeqpRH1TopxKlFOJcipR3pZY4ymY/1cJ3oDGPuaL0mtk6c9Fn/OQX99Qo2DJ fsa/Q5njku5HVC412OMGPrd8qVvN9kQC4CdauX3NGwllJfONhKMfH7+RUOuo1LoeeuBl5LHWCmuC 5RsJ35j7nXRyzWLzjT4uq3evMDl3xnGXQj62p8/+p+RutZZnoLn4GKgv35T73d5ryCv5I/NQe1wq 1fs9Vn+s4V/jqYRc1lL78QdPOa0SpTz+c2pnbQEPHbxbs3NOLT/+i6ellymu6ePxn6JU7yPhMYc1 uokHFP4NtKyl1svECwwb/7sTPn9zQyVYcKHptnq23OPHP0cjpbfUH//oqd5bXF09oR+sMunecxyP /3Il5rKcuMc/2dl/8fRudSasJenjnz1laHntjz/54qnd12TZ8+OfIrHmOlZFcZEhzlM1f7xQSDGN 02dH2vHdv1+5a0E42yn3PzzVZaEWac5W5Q/Rmut5h/+3nnf40cmOIZadCn3jDCv27TP69/D+ytc4 lWWJ/XItM19lgTL/+PCbT/7wT+k/HpPrmlpTXCU5tf7+3vSaPreQf9rDXNPb8vKirPx39TBVKEhl Gtbzgbt5iIwG7uYBRW65Co9gr1gQY6cSpQZ3L1GXgvk5OX554LMZxDlhtYtSjgK/BY6sVxgtqxR6 o7qCCaL+iqu2V+B8lDx6p286hUm9cuytOo4+Gqvz2z3M1BFLj2vJieM62Kz8e/QwlyeJpGVtsGaj 1P01PbhlE6I7WsTPJ/zb4xNzy9KaRcwfjMvW/+aAX53KnYQWQn5yCf/XdiBPFZ6b/3DC5/Qvjq6c Gj115eyaLl9yrdL70Y98z1/rmY7xppGPPVN07re7tm/o8e+tWnn19/dWrYwTTaZaxFScVVXYKLlq lcR1r+Mi1VqoSbWITLWITbWIqTgs5Si5arGNl42DVIu9YV1EW7Uyzl2Zau2SR++s9TBcbTb2Vg1b WSdd+06qhYHgDMn/gcVbznNVcluycG/lmxZv30Ge3y7e5kcS+7Mt3udaTkW/SYe/fSH3O9oC1zJ9 eiH3/anLpwR/INygbRThKSur6F6IG49qxx+1P+Elms588KumUyGG4zyXYMSMJRCy8BLE8Sh9lECO l8BxcS9R9BDSLn2UQI6X4KHypK/OmN94Cf7VtKaNPNLJGAuPKqemNd4f6KteT199+umrw3P8xqjq l6dA4+tHAcgx3+JzMPLvwav8vxKq/EMl8B90gIUmaS1Smpunkrl7SZP0BuMbMwTIOZUop6/OOL8p UU4l6umrMy5vStRziR6OEme8S/CvUmlsEkOtVcbG0m3G/dQzcJkufGKEObdFuxyo6Bl75jlQvTI3 tTIPpJ+fgcvcksmdnjj20BduKosD8lRHhFCAM7ucsXudMg3RwjgmHlQC6Rvj4HlYNmDwqDlsycAx ucKjH2saQrnlJGTscC+UN2rKx6FyWBoh2AblJ8vHkXrYzcFj7cvQWEvc8rL2M8rjmNji70I4+lF4 8HDh5vmdX6J/OKJasurnkX3Wig3AAhs7Go/cZ+Y3O+q/EGqCyzZwKKPIZRut+KibUWUh0qowv5IW GBU2hDkbYJ1PxHx+i1ZL2yirDPIL80E1HvjHumxwjW305cH/iPqzUXWhqCsJzOf1BJba4+OXWf3L 2amCLUHMRBmnWBbKR/sF5XFgqBRwulQh5redaugDUqeoDgnhZQlygOVWW1892Bgzy0Vxw9ryfrEG jnu6BOgqhI17SEYcFf8yxaPfpAbrp9yVIlnc/Q7s1XAOYgva6VqT51eWAt1qPcqTm6R77S4X5LXJ tTBrnS7XLepaB+Um+fha9vE3k1Dmb24040bGORTyYsst6U5pLpTrJsR8fku92PmjHXwb0/lKbWP9 s4pT1LvuvZqkf3LErdjMLX/qLTf3Ta+NkizfXG5hAfJkT8yecPmidlugdcEmbuHlkMznLQsPAZv1 aNPtEebewAXP4BUOLmYyToHZpYE8ePXAMC9/0KeTvGlhI/3BRQSmlwPXeHzDKxpR9TS7mrLTzajL ZmDDy8eAqxpsmXu2Jv9T3+wW+jBrUEcwu1GHtL1OHXOX1GECkIXQMfg8ePVgqieRB/GLejh1sUC9 gqa2kralb5oZqH/AqrNRJiqPjB+2qknm7Di3etdy3DLbktu6Rp3TcXXLDzrGbjVhFU2daTFvnWqc C3iwnTrFPpnOQWfpjdIWGbIrDc9GVZVPTEX7pEKUTHMVDl94xN2/GNVn5gcdXbdU2iSWMVvHuqhT OO5EXxjn9Egzt6WtRrOghqrQs9Pa5S0JS/KAaPXGphC/nTYbtGT8r97v2nTtwNJyOPJpNViK81Y1 Xj2brLXis4l46dIgrcsW+nv18RTJfprCCw2hr5ziJW2KoL44dYmCFLNrFEY79kxp4cinlSbHEuvP h8Sk5lQQn/vt6KH6yxG3yP7y+oVZCYYwTcN4acUx6unoMS9udNCS33ZRiEFQrH4GL2sMfomxDekA ry+M4akz+pfT8kERrHlUP2KfanNKhil5tHaxbjSPfErAlN2iFk7ppr6R9WAMiS1zZEJJiG0cPZuq wdBQG4xcDfaRqG1kY+C3wfWgN9eDXg6u9ei8atN8CiBKYXF6vzdriusJr2Zlexrb4nbynseL6YMI mWfBKw5uA/rWlR5l64SzzeBdPs4Ucg/AUttG6cgPWdilpctjxZngA/f9Dc6Ssz1gXdmI+sb6SVyO 8YVwwml/Q01ynJOPkQe3hay+5027YD7XGYnTwmmn5o3KKb85DWgvnB/PB3ca54LOixiNM0bnpYFe 9vzZx6FLnRIVh456Swp07F1yCjJIIhGpl050yXdvdsQdbdThh401O6Ii4q5D3k7RoTkXp9GJRX+Y lNx1DJzWpvfsqcrHlyP7MXHZkD5lf3V8f6oNHupWe8PGrZIdlkLc7qR45xUeyH7nZR/mw1OxfHGv R5P9UHWI+dXkBAxXG0jNuH/AQ8zsfdXh5dx5FLxwHDziVUQ5HKtFlEapDeV5fFxap/KLBFbr+tMo xkPqGiWOxebOjc/ezYZZPu0VS1HrB21kLLt+WnC4neIxJnZZ7VFlOXkEuGZPLW7ZRmnbagzOIKyJ sxDr97ki6XC35G1w7nL6SVYDj3fLb2FvVRtbc4kb5ZjrrQ9AdY+mWm+yeu5oevkWtg2FGyNrCCfc +tVkfTDXYMkn6YYLaP1rfc8TWCjKnhhqB7ewmgXOUCZDlAvLp9yyFLnZttQ3SQOvNDRKS9XhdEvj NrJjSm/XQfaMGwxpyP/vI4oz1lKhtFRRkvlDtDa5ESp+vF6WkdKqkRafB8f2JHjoV9sP5NaMzq1J z03H1vPBe82FUYfDjdo2o5Hae9bFQsX0aVhvMbJB2bfD9DbaUQ/LwFLUIsQ9Ow/y81j9wtla7Tw8 jlm7t32sXlaLvWY+R0ILqQPSuetYNS1Lz3YI9cX6PdNhRWc0H5w2A61vyzCzy8rMTlX3KQ6asJ/d pc58Bh6/ZmRAKFn+DHX7JKK5eAKpmcYRtwxT1rJqHJIaHQ/PMIc8Hi7LhLO3ouPUWleUCNNpEtpG qp/HpNErQ9uGTbN80UYlPs3mUj2Ne93pQ10Qygf3qDczuS5Nt8nKB7WxslQwUZI/e9tz+pSlxHho PSHlOO39bL7AlG5DApp7g9OsCA+50+YJBc83mxfsqLnVROs+qx86Vy9x+Nnaz66FM5tcBx3oFj1m 3pTPooxfODAJxYql8wpHEWVqUV9yr96/Xu2gPPM5qp3KOYVlmjjDujjHURtIKXLW5hQeiu/NZqLJ 2YXSIm9atC7mPyVh8Q7oK7MzRiG7JiHbqGsSRi32WyhtJAqQW7R+LEWLyJpa3nYMt6SMruDllgbJ BimrWUXj0UpBdKYFptQ2xqVE8bbtA+0yD/SbXSbF2Asi9kxI/dWVheQcK9Sa03h1ZaGYhogy3kP1 l6MftKudB9qH7A4P58/Da8I2FYLGV2T3iuxekd0rsntFdq/I7hXZvSK7V2T3iuxekd0rsntFdq/I 7hXZvSK7V2T3iuxekd0rsntFdv+hRXa/5Thw0dvgOg5MLdUvQRe8o58Dg3QlMoz6O8eBS8Skj5eh X9f3DFvypevC1/MLly4lwgnQi9HvVw7fWw2ZJfgib4wswfSo0jBOwAshcIGrSLjfwYDL86oxWLBm IYZh8PSDXiuOyucbxbiuJ9Q9P1t+0WvECyW9p2wtkciF9yFxmrrg4L+jKIR8vu7LVL4ju5i0UDvK MxDFWvmmMFoKetl5KB8hm4RSneObQEPBKOTz3d9lZheqotBCqImBkIWjglsl8AXggPr5/i/f8i18 uRx3qQrfLVc+A0pB9dfs5Rk8Yv1lqE3kIziAvhT+HgGouhDGlDR+BssyU7NeP7b8rP6xFKlSSJ/m LZVxtF9RvjIcB07XIcT8qaDbgT5gVORAoYS0IGzlhIwXrMG4Ufjmei1sK9/s7WzJJ95vLoEhN3JI SBQQTp6a5kbtKJ92/XF4+7EdIyAH2WuhclCYLzPjqp/4JjSO8gzYkQMMIUpCwpZwSYAkKJmEB4Ye s8ZPueH4+qYEpaqofUob+UIJLNMlVHfGJbfky2jOC38z+9k1t2JU1FuhuTkovQKHpXeFGtq3BsUY jCsxktLQUL7xnVVeL6rXmyFqOL+ky7LqGibBsgWUdbcsvLuudnktq/A3BSrf8V0Y4+H0b2W5yH1v Wo9QJEow3BUlawzxcWkqe9BS8hJJ4a1X0wmE2fCVQmpVljAogPpieoUAon1dYSEUgJXcw3VspCWC F612R01c4YvHjflEzJ8eeLG68AKP6sfrQdRABW4Wxre9miwbqkLketW36OtgMK1pDFWtuWVXyxwZ Eettkly21yBZHG2rZkVasz4wOJRvjqLn18N2tFrNIrXqOtiK8tkXSi7DycU1p5ltnpve7zWHMXQE DvWmAI5kvgfKPPKDejaiwnBKxc0a6UybaesUQn+qFWEz6XQbarlaCE2WRohjsHxKxdg8HWiJwUyr n0Fjtpp3TxiyCMpn4IhWm8ELjkShLVn1yLFq7mbIJol7ei9aXOV7pbEbdRicn5J4jmSiTr4vPmmx pnr0bJRss5nFQYhTc5ICl7I+PcSbo2z5PVj57DQXT5LZvu4W0Tgli9ppUflirFlEhfsoV0GlREeF 84wSrF+ob1S27oCSjoLrjvWfmwscFfnEkVJCbfyUZlKF0k5KURfmMeOAk7L9Qk5fWiT+ngFebAa1 4Zf0bLzCeIt4FTd+7zQz+8KXzM2+MOBm9oWvLW9513u7VRapKRTnWtvVZ4x+RtMfvYMs7ndKLHky gsmB3q6VhmGdZqnNZV+vn8vjgB9s9VefT/XCtfWFlo3BWtm4duRTzlkqNa+Jo7T6EVLqtCWR7U9H Ztngw2LFb2hgpAxF2vjgp2J1aHQkJahPxj2FA8UDvs88qveFVEF4Um86W79IISK8VGZIY0nFacVS 7CvrbP0YK8fCoG/bktzyIektme3utJWkpeXrvXH3eFRTZehW3hXff+/h5ihtVA9NY69ZiiPhm9k2 vrplga2SEi5XkmS+1JyTvH6G7YLNJIOeCGob6bCKI7kvh9igIbNaCghnk8cRXIaG+bKsNbi2jeC+ qh4SUc8GtRl0MxT1pc+pKqVXsbNZ3eF2oaithVje7euIcUuG+sdXkmmBEkeifL55m1xyRYlkoV6X lkFPkgFSoXDkMyxKXzru8kRJdolBS1JVCHzhG8JJ4yem3WRYlXaRYVd5SmqLHj57EoP31NYSDLYH rcH4Ui9tJHsVirdq6wYG51gDg6Jsi2E66wuDsvDalKqxBA/hWvm8x5Jdi4etGxQ4ds0y1ITIiyHs PpZqKNW/Lf34ljLKVL4mrhVA8QClyVU268jebBkjchmXxOd4SDzfEybH8pZ9yo6t7oS76bfoQYlL x0wljuXNMY4sHl6gOFa2Ruid97ntg+SUIxfqN3vH3HoefG0jfnFcJtE1u0QLtY3GXtsMrvlYPm1q pMPDw1it/bT7l8OeSY0+zSXe6Wf2w7YtXr23DLnIoxzbtxzNPdXRjlUZAvSGqq9gFdS3uqp7vXwJ S32sefuegx4le0BEypv/rbfA5elH24TxGXrj7N9k/pqSYwaem+IX2giQToVwjC/0Ex7HN5SOJrlm fzhG0rFte2ZrgGJ1mxycUDrGKP86i3IfXGbkldvGwsEF8YQ2rctzoB5y9cDAPNcJ3Irhrx5k/iYL w+16HQ2BeT53YQFb/uYRTgAplQHhqYCz2YmgMLIoO2W9mDb2bD655uVL5ELNw+2Spkm55QvEW4O8 foxsBvfgJi0a6TLHXmMM+XJEHt8YYxwaNtxbwbkk08oRDg3mDEpd73tO6D5D0qoOedaUfdZGe8B1 Q25Ha3l4H9jG3PZg9lP+NHsx5bk235wwGmhes6C/LNO0GZTUoj/MF7xpGZKF7Gl1q7Cs7tQMEQ5q xu6peuE7mFxsbg4vr40GtMRwuHn+IToPtKkxN2o7X6Om3pAS2t6w+qtoZfpD+lFTbV2l1/D3vCjf bwg9+6zGVP6GgVD3/PdGYbwOjQgoA/Hatucv9SA8T10fCrsTe9idFoBhd32rzTH+lg9Dt/x1MQa1 DQ3lFwv9CuGgkPIVlpf+1KS2PHAvxFKnALnhglQLE0s/p82pemu925w9GekiR3Pd6yKN671rXtWK g9xumiGZTp8zWkDdZMRW/dRTWu5kwXWTph62TzzpiQrVnd+3l4Sf6LHy4hHqdx4PBb2tJ8N9iGn+ Pd/8Vn7aCH0aZVt21Uoq0Oel3JpPzA1K+uzcsmP/g20YPNsMoPGTnrSvlPEWD4vWgtO+TrONs84T R2Enx86nlDSTmKz6M3+niBsM/JUibEkhv3N7CqWIxv5y9EOiJuUII5nZZXOeJGqYJAdhk1nVhVI6 ZKh+4fiPZBKbOkrT8R9926OXb9NHpU0jtduaS6xQcVkxOVVqE4VtdmhGqyG5MVp2txyzH/bCeJlc FsifYRLPjZDkHJ4+j4kWJjfT15KG5pFPCZxuLybtEWcfs9fadKluTzU7sH/jsLfdVwymC+NmW1JW l1a41O1+O/QO78tfuyrXrsq1q3Ltqly7KteuyrWrcu2qXLsq167Ktaty7apcuyq3a1fl2lW5dlWu XZVrV+XaVbl2Va5dlWtX5dpVuXZVbteuyrfvqnCZXxAdwE9DtNX17++XZn73Z8Pw06c9r6r1Aw9/ +RTviwP9/Ltfv8Gv832c+Pwt+T97qoE/6zD/7r8xZrV+/PMun/7RAL5p0PQTXBViELtdFMdvAAV7 CAW/5cNoypsfDcDiJ+NBAlxZwh03/cjrwrjdFPSoARybHoJdj+SdsqiL07yNnXSJjOnJLuFPYV4z y4jF8WoZb0I963Jf5pX3zpufya7Yrmb3tUF1x9BwZJfnWIrXsHmftEZvqepqWefdLrus6CgJ2eW4 jEgMr5LxXh0vz+3yujuGCnnvjtf0cM+42+VA3DbsuvKHmvA0k1Cyy3loP1VdMCOFrDk9HoBmFg3Z NErxWieH45dWUTWvffJeYtxEsOv0JA3L89Y662cnkq6ypXHzf/X9EarT01nqGi/8CTXP13MpKkWq pOmDYCWy7jZ0ttqdNCUIsf9hk86I+AGpWWR4ebB0kqRsXmTjBVswbrDLvCNpo9aDLeoBr+hRUkk8 IVFAOO/U4EjPrah83vVzmNkItkcg4uSN6kFhNqjU4cRjd6x8Dc4BihGZo0GkQwJycTKzaZHDLivu CuumRLWPmL+zeKOxBWdDs4u/dSd050U3rjy75vIj3gzVNcx4cJB6xaqpd2yOd7PrfrLABsQ7vyTC LCKXXQ410hKRvrz9q+cv+E6FJJi2QE9HmGWxi8FNnYOd4YedPipUgJ16cTsyqlumoRcvWIJvIMgO 8i0webLkyyi6RlrtDR6Rjw8kkBD7WQd7OUw84pMEVJVhWsAX4fQ4hV6Lkb9BisM/f9EFa77u9WJa 65hvMZH0fENHiC/gqW6+kEQzpvxm4ja68Y+v0Ykina8KhW23faxp6vUSK0lpT/aKnFsBPXvhb8tJ JD2/24t0oi7IY2sGSueUfYPjlsw0LCT7AcGZ0S7lZ11QhzDOuC/1Z7u0T+TCNvW0HuvSVf/Kd8zc BPi1c74eQcHim0/TFCdrhSXTplJ8y4I18c0oe+qESxlOaxBRrCXFHa0gRQX1L7PX0eyfX7vHm3Yz uWKLEmmIPs+68Eusqc9QPuWzfDN+qDxfZDPtiJuqMP2T4s80PbCjb2Py8rzgj89nsPqLxmI9CW7J ZzDrGkSfF5cCXvFPURSytuyBhci62MPkbUXy1/oaxHdL1Vg4VpNk0DXvsUgegxD7im9p2tnX7ObC L9JjpphZ2sSFpUz/cMTFpH0LGVEN0Fhd369ste95eSbTfqQnt7uGNo/euxSYxFM6NIVW8clkR08i GfYZUfTI5JjNN5tjZXOMIzOOcRlLjpWtERytcax0l1OOnIiLZHvIgSNXavHy9STR1NjgGoVIhiMr XyXdVp66yzqTaWTUWK39tPvn82He9Jku8U4/UZNfN/mNrNmeMyLN6UsIBe9DNV+KePNUMyG+NF+F dRX3pSZnIvbRru2Tcpyu2QOheORTVovNLWjBHkUI/YTb/gZbohtjbsR6ht+gdj01iM3gPT7qh+N4 fEPpcG8o+RiLjfYrp5gcgfYWnUZW3XfUgwZC0jx+yzlcKN8OLpiENy3wX52Dc1NP0zqXun3b3DmO 1OCt9XG01t1jmnQwKOvdNGQImwZ1n3c8HysRYNKPi3E94kVb67h4y9Q3OizUtxEPLWMqWx7JeT3y oWV0bYTaRuOwNXRNWH5ml+d5eKVzNm9/7hnC55WopTstGBfutGpcuJtdJqatNRT7ztcmfMiSs6qQ zot4w5CO2UB+r1m5WAgJPxjHEECy0lHL8Rf5KY614Z+56LMArZXTyqBxy5grcQYgQQZD6iGDDxBS S20bzWME3DlwzEVl9VJKO40W5MWregzMZTuwIGprkzJp5mGYgTMHx2I+uo1rUQK/TcmNLfvpPGL0 gkE6PT3YGLhuTjsdghPtRj9KMNShEpA4btSqBA/AzaAHPqbwi+ZTHhdz1DYqh1xIWnlgZHq+PdbC urotinmghPMyD0RsuaHusAdEPDCifB2t0apfnG9mn8oJ5+ObHg/MIN8QfRjacRz2+EQdx2N/03mM z3ST/RmbR0I27mennVKzavjqwXG+2Ripm0qr7h3w0KmXn7eDCzavgIt66rrzAODsbl95RE8oytsb OgJr9ogHY6nVPD4niYjuA1Yd4aOG8wCeeBb15GnXYb0oelIWtBLo1oZrXjS9DVVH/jgj8Jif6Bfl 0zUE0KJ8E/In5r5lK/oDVk3fS/ZVB446RnvuqRT1T1ZCvS92bNhsNPvmKNwO+iESd8WDrniQj++K B13xoIODVzzoigdd8aArHnTFg6540BUPuuJBVzzoigdd8aArHnTFg/5/jgd929GjAk8bv9e2iJ1x 7j1HdrhioFlLEAhU1q9CvTl61NAarhfj2BK0uuoQKprLVYdQKyxqtcOaGTdXM67uogQWPFVTrdK1 +MFNV+LMH2uqWDnwx5qqFsL4uaaF8S9IWUXn+GNNVb8OgJ9rWkVRQCh7frd8JrA8egDVVkuaMtQ+ pgwVxbpY1em9/IoFoPIRVKoQ4IpFppdv2Wttu5HG6sgyDQhRKg2SRTHnVy3U8QNXVqAWz4JLVBUo wH1nyyrDs0oVQn4hXcmCnZ+Zr/rJKZbPwetPQ20iH/6+BpGMqhn3tskw5ifR0hDHx3wpuMqTKomU pGDgT025ah9TLm6uu4B0IeaPnUo0EWrSqGSwcGffOKByQeLGVlmDcSPjbvlC+IitWg8pnxQJoeS0 GKIAMUcoVDdKR/m266cEZmP4HgE5WMJG+aBwKTu1Sa4X6kd58pUcKFu4yHWTcOHpbKaYVnJI469b JeqmRDWpZn53vlAC5+6OFtuS27mFc04frpwiaq6UH6QxNA4OUiTIYXaC9Y9T+xSOsVk3DjVT+WnS Zp0kffml3GAV1SCTk8YtC6cQtotjqLAzWKQ2/bYQXi3Iugyvsi0Ft0zIqZx0cEs/43L3C+wjbK9+ sajS+hrGwqI1s3co22TJuOrUL8NRJhyD//4Nj3IaZhwuHOnC740L9ttOHIP9VhLHYL9xVIt5pt4C /W/KD73sWi0o6lJDf5tSR5+dWmUB1BrN/+dI580DuxRPXeNFr7hC5wVsSb8u4kkTua+gOikzbMdk Sj8zkMwgdckk9xPSllnuMhiqnm86p2f9p7Gb8XzqjIU/qVOMTal96pT/eINbHUahauob2ZccffPy nNEp+PrZDckkV/KUybD7x9W52QzOwWOnUlxZxqwe66JOxeyUYiBQzgttKfduaHUNtSOfsT6XtyIs yev69QTJAimkHzYgLxgPFv/1o0fV6UaF1Y6LKKAfrCleigrLmsyqsv656UpeujRI60hZ/RIIx6Or 3EZnWgFGURb6yilOVafXw/oYl7P2gu8hGSobxUNeOQpyjCPTD6mIYox4cOJmX0gv76H6y1CjrETR j8ll6XzXDy1RE+oJJ4WjZRVwTdK/pYzQl8KVwoWyhWcNNeWjPCYvpRbmg9va4ij8QS8or+qn8dfP 15qMFWFZIiH9OGrYHLKwcfWfH6TFOGH+VA1WyBqZUBFyObZUlqLEM8RufQh7DAxGd89XwE6laHv4 A6Spmx7ocrX1l44Df6IyufegC7mSvbGtMoPqfKxJsoZgultcBtNpYxlMN2Q+BujTXVbH1pWhCx2q S/M22uZcy5+5NR9MP0WcTWLG9oYsX5xWCEhckx9b+ONthjHL+Tf8QTDH3BRI+qafcNNYX1xSus1A ZX9DTRr6fVb1h2OknRCycT877ZQ6VIP8sGH6IZx3atmonvL7Lj9uBz+eN3cmn5/JRRsEnDFK7TvA WxiSpLwQUeaFJPP8tjCf4bPVy8JbSfJ2VS+yCu8a4c/C+zfGCd7q0QKF+Q0IAR75SoV3hcB/8kOI d40sH3rPUpT8Kbvfdv1Vwb5oVorXoCi59itFnJknfRGG8OmQpSMYSdvDy26Ucv5KETmnADaoqG2C w1dBaP3F7COv7Km9svugDUXD3awmw6TqrVsLp6fGQwcxlE1Zai1DkLRhDDuKMgrTil4Ybxl1o3Dk 9+qlyAO4moW3wLTOKLwvBRslzpXNQ+O8cPZUykjjdoDldwWoaQmKbltO2WoGz7rbat5FIv94Uyrr 9bC4ZwneqiK9GIqT7zbNVxUuO3VTeZhX5AFG0ZYOJwPJ47DJvHBGy8ffaxI9e902n6FT6jrDqXhx LtuvPJXeFHBdKFkotLS5A5yiIoqKSpPyzwClUSlZWLLohh+50EQr5vPFAlCZ97ui6QfpRy4nYWoK by2yp0TPDyYRI29LxIAx7Z+htvsqidI8nS0Yy1nGgrGiGykcPCBtae2UP1VKwdTKW8Kh+NzCu3LU WnF1ywV1STQeskgamewp72kGk2Cir0R7SyVtgskyqfgsS61eiCOTX4bdX8PZeQfjL60YpiEY5dgc H1sK7BqvSW/Rxa9gt7vN6+CdbkfRpTpP90YZ4HW0v9SvRasurgWoFVx+8xa2eyr2wov1IJlV3PnN 7gq+PJg0ac1U/JUb4nF8U9qBs937tpngwHWPT1LrOB/fTLsp/uIan5tkjOgrp1jeMpC7UqcFuQ1N R/Ja9C28GkP5dtDeJMeCu5AcBf9sVs7CCw0FKanTDGGaz6Zwp9rrm9J964R+7UuI8xO/dE9iKBxt NbkV5msfz04R2G5pJefHYe/rmIzxRQmTYdnboS+3fWB5vT2B9qu9v8P5l2/toNa6+8e39eRF4Mfr GdS2VCztVWbY/F0tiCvZIKUoPdPs1xA2bZrbElk+aW1r7WEv7Zi+CqWjr6M5rRgeZ68VHC9uq5zC 9haYpcnjMVy9VO9ek2y5KDyS20Lp6w76Q0q6vQr06iMbJsNd2LRlcLtPtGctpA2lhBph7fH1KNp+ UpE9q+3oL3GbzjuOjK9nmOw0e63R+tIOKXB7CJrHrBUOZoJYZA9h+WJ2e4jAtMYctVFDWY9wiCl/ MXWjWUzJZzWGsC2V8wvL2KwzqgXgyUm8WkjL6KF69UuzVnUEGnl+LV6qBq9JAW7Vj+0zht6LXmRs CmLzdddns0Ex7VSuyRhWt/ExmM5R851H+adZ9HGpjtlsXhK2vpAqLJWsL90pxB7CubO0eORzXoUG qa98Z1LHLTRWjqV2bS5IcmIM7gFoC8CoNuXr7vxuL00araNbCK+ffGWr5Eqczmvrn3AxXRPVKBVp HPWTgmyVlHC5MilDvXy40uposuDCxfvTds9aOFquW/bq7oPZLo6nRu+PrBx6o61JrKqIrQdC8cgn x7UeLtxIKZq5uD3kuB3f8P1dw9jEjdqRKLmccD7GRylrsgCUQ/sG2hhtFcj+yEvOG9m4n512Sm2q wT2TSPtHJM0miu41Lry1Susf44J4kniNnJ5F4WvEOtZW8EpTNH8ubewzIC6eowQ2Nb0Et6usBKx1 HLbdSqsU9Tu7km3OjqQE/VTSzXylxG8xImyzJbjNBVuBSQfI2N9Ei8JULJsKNtpTsvKr/kQpRK2J sRXodjppdMrVtNRQPfIbUzk7Fa8JfPL6waeUfHZK0bUsmRYJR08NztEULB/9px2jbsxh9fv4aefg QEu3OU86/cQxWHtQ6NV7G4L3NvismsJeG1kfOAbZDKTFfORHn49EV5Y3r561JpYitaPNLMnsO9tP 7jUkWodKbtRtsxItBayjoXBQEzYvySaWjeKRn7vqMm6y/pzUk2eTOfGAfKf1Ulo65VMa+EQCqJ3J Dau/uIxBvxNnEmhrCnFbBtGXdoFyWUxCOb7oqXXnO3/ELVK4SFuwUZ7Mm4XdSHoIR/LrGC3SwuFt qESN17dqERvHiRYSb0MlajT0NlmcAgcmEhbaSuWKkmW65aMteJ+qn34a2xymX0V4oe6ItBsnjmvj nxKautnHqNZeTIfVMkcmVITYRlY5WZYzEtVxjCDBFxaiZyOkMfBb0oA10f6xt7UdXK+bq/SFSxby mVL0/vzanb52p6/d6Wt3+tqdvnanfT/o2p321Gt3+tqdvnanr93pa3f62p2+dqev3enbtTt97U5f u9PX7vS1O33tTl+709fu9LU7fe1OPzvtrt3pa3f62p2+dqev3envbXeaP4yBPR78MEaL+NmL+3L2 Fv9+9fMH/uAQf1nnVTgHbtPop3QCfw+COOm1kfcP/JmoHLzEwtFLENeNw5sS0UssficvQXyUiEcJ 5JxK5FOJ7CX4jZdgTmIJPq5Uur5i6VRJClxNr2vNujyHwGvlEb9wlejNzBsCxt/fb4mU++rym58T meHOHwRL+A9/TuTHTwGlRxv4kY/Vxvpfi4+/fnpX7stJmPHxF4BrBZPxkyELLlGqj7992p/+dCe+ HF/ennK7L1qMx199bU2n+v92l789LTrgZ0TexXtaPW73oR8l+ckjuvY13fxwwuf0L47u/ebcqTjv a7YZj69P71K9Y2Z4/OVu/mdPBs41vazEtYJp8/Hdk3Vtvunb8+/Vha+nxrmORYR+772PN4P7etKd Uo9hnBr+ydPTItr+YZYfPfxvUZn+0mVuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKMTM3MDkKZW5k b2JqCjYxIDAgb2JqCjw8L0xlbmd0aCA2MiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nOy9Wc+mSXIdBi7D0fQMhuuQlCjRH0VKrI92f8p9uTJgyDDgOwoD+EL0VcmjgVEtgTRQwPx7 5zknIjPf3mbE7h4R9luFQsX7PJn5RMaWkRG5/P1LeIvpJeCvA+8/++Tf/Yf+8p//n0/+/pM05wv+ fUao5RBePnySag0PMN59+OTnn/wfL//lk79fLbSw3n1aaojrRxnrv1Xibc6mtsfLv/+vn/zt+otP xjDL+nYaZeL7b2WMkPvLf/jfvu7tP/znhdt4y/hDnG/4/Wcv/8tP12fi+mx/Wx/96c8+CS/x5VNg M8NbnbO+tPI24/r/p5998h/f/fbrehp6LOndbwGsOZV2P/3e66f1rY1ayru/WE9bDy3Eu8Afvn66 sIx1VJSNb3nmOt/9q1UgllBCf/fj1/gWY5t9F82pvfvRKjB7SL29+z4ezzr7HPfjU+8Hp7E/Wg9T j+/+7r+cZ+uzi8S9p/Hun62nYYYY07t/8RrnWxy12sMY62P7V6t/+BrTW1sYPOBytXtwuQv82efx SqG++yEK9EWv1cmrhfsT/a2lPOaN7YWMupZHjvEu8UM0sMTise9/+JrneJup/Z8//d8/+V9/uiSL kkuJ8/8/20++Ror5npL8N0uUl7xAWFqYUI65xCZC8lIJ4yWXtsRrVca/f/i/PvnZ31CeR+txjJcv AqtezDO9xNz7S0l1/ZvDKlL7VGI0lAgLW8K1jbTwiSPlB5hlgGccsb+ATKgxlsSz/Q+Ca+tVcF9w g44ShwOPXQaw1xWeq80Pn/zsl/VJ3/+6PhlWwTG0fqRUxgO8+7R+Je9TSrk5XoQNX5bxftz9E6Ws 36JU9zK7T9+KdCSQLLWaUBlwbo1oLrF+gFmGHWsLidRaQY0G89TqYKkFrxpRcF9wZSdLqAe+ypSr LsqwTXSMgl9yWoZvNfOZ4FxC9l7cMMu42Ra/ltX9Fezqomp5C+XBruZQ32J7WUaNb2BV//j10/QW FppxaXt8GznFd7/7ipojlqXrC0o5vvsT2Ms+Sy2wGjAgPRSod1wGYlmoP4UpybX0XJYpWeqf51xG x2r/Fj5Se+hjmeNd+2rofPFPX0td1if3bSX+dqk4/kJMlz1+ib1BVuf6V6IL8jcchRZnvkitONvb Ep443noTsX4DtrW2kN795kI4jWWzV99AmJAxFOW3UTEOrc62xdV3v7Oh738JdMotopS3NtdQvMzo JtUPSNzM92p50XuRbLTZ2gMui94jLStNg74sYQ4gtHHhR1+DxGLhP6DJugpiGPP3v/taw+p8/rXZ 6qVCfUlmWkZ7bFu9zZM0t8fgWrxkJEkP5wPMMqbFS797ot630NX8B8GlGrzKLDi4hm54aa6XoUZb XaHJr20txttcpMWrVpnDe3/DLPMFLd79+wbqvB6VMt4W3Sihf0HxGTlfKnW0dGvm1xe7FPPS3L97 5+r8vSOuv7Eks4+4nIlLsX9zDfoZHtdd6Udr+Idnki/F/s6FqlQ4AMsctPSFMc8EaRluE6oKV9OG gxtmmT00rCa7Dw1s3oaGGsf0oWHB2QVmw1eZctU1NPvj0FBaCj401DCa9/6GWeY7Eaol7rWWNxsi fh8sHHPc3PwrBx6M+JKuOiss0nL04igSqsWVvjz1S5T+5DXWt8XI+qVSsc19yquD6x2VOLUhOKXl xMTVpEEp9Zf3nxz4QB+vpx8c7muuxLbWSPeiLwB6/8mBD/TxerpaWMpvJUos1pYg4bDhA328nn4w mLizLfZn9/L91eMDffyc1PJ5ktRGwpQIqMiC1dPJutSZNUoBpgwmfZNmKWHMi0XPawOs52WNrLFu /23NJeT9rbF0Ya42MQzHrvIJz4dRGG1SORe8vpuCwQufJCOalple1Lie537Kl9MOkPL2l++k76JM L+5nxiTdIp5pxu2lJple9isHlW/wM2XgSYcc1cdB/oZNt5zU5oSHkapoS5i45UiY7ecczvNCWLwo c7ezppi7/dzg34oOubeND1zehae+NePGP8+++wWf0PuLuc2ig7mcadOnRNCkmqSNTc9y0VlwvMqE vuvGaXAGT8f+Vuxz42AywLlIbHnjbDKTB+Vq7j6ajGXp79g0iRwSF3xklTSMF20l2z+H1FttSD0l sVgNfiGpJX5ZWMBHNInOjRItLDpsh5zyPCjdwmL0q2fsZd8cWJZMvUebMwmGhAZzHUD1YNTqh7rk Umrnea6nfCmnnZp3+0mjgjjf5sZnjcvCc2wpIP5pHEqnWXd/bcTMLW0NIH2y8CTd1rRdlIY1jGoz za0ZmXNCg0PaZdIsu27iXFhtpj62FK9py8aBlsZwS3VsnFNNlwb33Udps/qe4OcbTaTxotXqAGhY tzXCyw1H4ZNBtzBPXcMHbRofZeFG3TgY34mbW7vat5zIalbrb9hyxb6b1KdRtxwmypLJJ2jockvL bdoQp8M/+2+a4kFcHsbuNJZ7tzpaytuycGvwfveXrz/9v79FB36JFqaq9JlyKwZ/cJhejJVpmrbm BqfZasCR8hqCrUaoV42KybXVwEOvIVg1VMZrlBx2jTzCriFYNVTGa+Ry+pHm6Uc6uFsZr5Hq6UcK px/p4G5lvEZspx8xnn7Eg7uV8RphnH6EfPoRDu5WxmosBu1+LLXc/TBY4Y1582MNcbsfS1B3Pwy2 Gjc/0jj8WBq6+2GwaoybH6kffixXa/fDYNXoNz9SO/xI9fDDYAvT3PxI9fAj1cMPg1Wj3vxI5fBj jXCnH+XgnsrNj5QPPzgeeY18cE/5gR/p4ke6+JEufqQHfqSLH/HiR7z4kR74ES9+hIsf4eJHfOBH OPyI8/DDYNUINz/iPPxYc5bdD4NZKs6bH3EcfsRx+GGwaoybH7EffsR++GGwavSbH7EdfizP4/Sj Hdxju/kR6+FHrIcfBqtGvfkR6+FHLIcfBluNmx+xHH4wKus18kWrS8Z+9rmIVnxZ7lO1iNYaon9p ROtbyLp8ZbxrOWmln3DCtxvw+r1/ugGvH38h4HVYNApZhHEVTk0N32XQEY5N6cqIfVsc+N2rm//E OPD7+/0f3BwgcVIw4ny6Bo5V6mUERCZ++p8WWf4Q9UpbSP0Rgk2zr8GBKSgDf8JsVCuj9Xd/jBzU TLOjV7G9lZmLAtqtltWFP13dyn1Vugr+c6JY1wTy3b9gaHuuKVB992eAyyJVHuv5+cQ/X7wpCH+/ +5fr6RjLpJR3/4qkWd5jSA+FLzT//IB/8ponpCF/mQRyHpWVP+IcG65t5/wFExpCy+98ef/JgQ/0 8Xr6wWFMe9lWTusnvwDo/ScHPtDH6yksfxpWYsIHZluChMOGD/TxevrBYOI+NbPLL6eX768eH+jj 5zJWfJ46adKaxz6WfhBWnomzwxwJc9bIOefqN79puShgUvQ8JvfiOW4t776RYogFaK67YM4Ooyi5 58YLLj5nXnDwufSaT+w59oKbzw4XvCNT9jyrbsdMqJx2NJ9fMGYzNiqO7vN/4ZM4Q10wYx9p46+c v/qlmZn6q9mb6KB4hOijOJfollPxMdviGovO1WMfLg9qn7NAez6bx0TiDKcdjXFqf1LuRIeZ08Zn MobCmNGC+8Z/1rz7NRE7sP5Oziy7yre56TMR30nVJK1ses6LzpN0TtfzaHD12bzaiXPs9hW/XTBk Y4SNj8nDZASilY2/yQ/7tbyG3V+Ttyldnps+MddNN5dbRiCczt3lHB4X55l5ykfjPFNYaJ6Z1Sql W1gg2uNYMIZay8GoCovMqI6wKOX0jFHBPjY3NGdeMDCa+laDtAaVR9xBc2/jklGXcG6nTKmnruFT GftIm6Kph41D6n3j5lKQKfWHumm23cds+MQdm1gwYxNz0ypHaYziGpJ60NY140TtVq/nKVPDqcts uNocuWwpHoheGg7UPMNtMCYsnAfjROrLYJRPfaTVsb6vwWfTpM+0adURsUziL62RonwGx3nKxHDq hrTbNN7RcsTRNg7G66HoX9w4m2zIata5+2iyxL6bjJEmJnuklcnkqGPLKmmrmIhb+vnyzeMgab4l hkEGcxjv/urbDYMo+NktHMkVBgqxaSXBgVlmp47WeBc8dRS7AoBcYVAVduXKgzp3WmjDV5ly1UUZ tvmQOiLdLXWUCg2oenHBLLMXg32jRFFK8deymODHr8srXg3lO734b73JK/v4/dcy+/Ld5peuICgp eiA5KjDM6KeSGBbNj0lOyIYP9PF6+sFh2opmaQF9IcsR2vCBPl5PMTHs2UpUDABsS5Bw2PCBPl5P PxhM3NkW+7N7+f7q8YE+50rZ88QpbzQYuDHgLZdJIX4ZbgXOpbSZ39Rwljksyn3KHBhsIkzlZxB3 tYbyjX1n4Dlq+IbIWaBd5DDDlJm0k8Gix5miwdD6ZDDTG9fzkk/5erXT8m4fOSB+l86wcMvdg9PC M8mFI/4Koqtf5q7kVvbAkMVHPR9xu0ykm7lJBSm6bLSNhIkPUzJZdMYqgv2c800rTxysnbZTTQue 2y0vvW+3qmgAIz5l7iRALHIRLYxRdn9rmJsONeZNHwRanW6VqTvRs150FpyuMjGfusFgpgbL/pY5 EMRBQfdY5GbPjbNSj+qLyRL7aDLGvpvskSYmk6UeWSUN40VbyTbCNmkqTA+ppyQWq9E9dcSgz/qy qIgE4sbiDH/CSE5fGTtBtuC5pbtMTg7y5kDU0F/DcTArHXa5DVVpJKPQONQllyQRel7SKV/DaafO 3b45xeK8Jg3EJ4208TQpIP5K1Zg0yXVhf82lKUqkxk0fc4dIN5c+BrPkfpS8E+iRyUqHQ/bE6NKS uusyFae009KqebSNSVvhQEtjuDGZaG5V5kTBNXinyhZcdt+ZZExugfqmVc6kW9zWyGgrWJMYlTHc WFcTOyUu57EcccaNg1u1utOKCx5bTmQ1m/U3brli392CYoJlcpgpSyafdNVMbmm55U6XM6n92T/K g1ouxhtwLxWBF7hQ/2a7UFgzzEnAFwEsUAiLRrUF863ozftPutg9jfNj5qol5588/Pxg3jg8Rs0H IARsmtD7Tw58oI/XU8bATVBTlNHIgs43H34+/Pj4+O6DfjrqbNo79dDh94/9f/jxuYUcIWuVjfmg YQ1K/hPh+MXBWtv+ufhT69g/l9WsLTmt5uTa2vNz1e3n7dKB2sf+uUxSHZvOmNfWmc/P/NJC3D8X 7ZeLen7Gl5bOzyVtLV8/l99cTlOr762eDy070FrfP9eA3Mapu4xCm2X/XKNqD/P8TIv45+0ygz2f t8vi9etDy+j1vlseSy3XdOj87C8jPIjZSPn8jC9rjrd/LlMyZjs/x4OIrrezP9SN4ZpLhjL8izG0 jUwMMkqap4fgXYgx7t65CzYVkepOEx8SJxW8n3lu9Plv2EPulLE6EQiPdhQ6j9MZ6gOHzbuDi4Hl 4C2y0q9Iic39GUe0qAwHEYvWzLPqBoJq8+Ilw9Hnyws+6wxC2gNHCiUfuJ71B0HzbubaA+fj1mYv 51sjOg4Lppuj8pw7a91c5BoLrVyKHEC1ziByPs6+LwczOE1STJtWKXL1kVanRK4n0EoepgVE8xQZ cZyqWzePUlRkKAkeztOER8brBTeXgRTp2mgKGjHwSWYSlo6ZLCU0bTKW6P9L9hacllhuSwK347Zj 6+0RaVY8As82jzrwc0dZiMlRJSJ5FI34HzVk146SstdHhZnePApOWrV56i4yHuNACrd2vruI364P Lb4cs0OWtZzOz3CZLDL6GDTKQAun8FLJYwwpOcdUUqiOIV0/02VmKYp12zdK6THR6yfs+e5vqOnB vK+h+hh/ZGxL3I1hcNA2jFN7Fe/htL0K9/zw5X4QWTOTemgZlltRx3mLDSx3j9Nl/tfPZf4vLi0h b7Gfn3ORtj+QNl8/19tymLY8qNbC+bneHuLBQ2/jYuliyzx1lyfW4ym8pKNf312y08t5u/yQXq+3 q/AhDpyrPg8aS0hHOIUbRoMjpIuS48J5OWzLmN8/59UyzFIw16PR/B8VD1o+hK/HMKIjFoOiOpG+ ocybzEaax5wo2hPLDtOSPsu0ZCedhe5IVfNDzXQZPjRpWpAoU6cFoZHzCWufocdqJnN4uJEiYWFI SouFJ1NgckJmiWbYlnXRPKdZXDJ9MWOo22df8swlaqpbzhK1wI1EwYaFeZ5zk5CVj/20E8Npn7NZ zTDn3MvMFhxPqHjUE0LuJ7w6ez4hZyxUtFmuhaivsHQ2+Mx4Z2lO5wXHPQ+YTDgN832S88sSXhZu ZwLAkwFxB/on+ih5WHBxOZE7IPmRmxAs2YD5XzA3AXwMhs8i0+WhzDWgXP4L3h55ZsUj7WxzPPpc R1MYRD96RCR7v9y3fukgu3Y0lL0++kuCHO0mrY7uk4ztclcxFFy+LQaKC2f4p+XUre2ySORmu77b 4NtefnG+bB3F43aEl+TUyz9dQnWsqBzwcYx9yA8WOIYH+4zl9Zf1TunBti8JuIcRTiB8oPjZd78b 9/Oh9BKxGmSh2+fZiftpfssT6/v//DW/ld5qQ7Z7PezLCX73B1hbsKapNb/7I7yPffar5Hn2g9f2 1oDwu+8D6svTfPfPXmN+azVhxQBaXBTA5pHd4o8RYy7LICCgvD/5vdeETW29IOi7hvflxnwauYMB qwV+DwXXKNex5zXWt9IGNuDqO+VLUfvJa31D4mPeH/wh0KjLha3vXl6XpIylcl+yr/XrJ8jLEYr3 BLlwg6dNkBGi2hNk/LgmyPfPDx7Ngr/MyA5X61ZGHjlBPvCBPl5PVwut2ULeZZm8rf74zfvnw4+P j+8+6OdGHU3vTt0dfv/Y/4cfnwtL89WeIMcKP2b7SGv0LJcHtdzJdk2Ql7s97glyXdOfa4KMbYTX BLmukfKaINc47glyxcadM0FGwPKyC6D9NUFG2PKaIJfR7glyGQ8T5LJGzWuCjHDmNUEurdwT5LJG jGuCXB78Z4aHrwlygYd0Jsil5HuCjOjcNUEua9C9Jsgl3z4/xeyaIJdlrK8JMjYUXxNk/Jzx1E0P IR2+PRzkz/7Qsk+fKds2fQY+Pn0Gqj59ZozRps+FMbe4+74zGEo7dqfYjijXKzbLJd2aPjOibNPn Qp8mbsb59JnRaJs+l3mmz4qvtuBC4tPnGveUk6JlU1FKnU1Rta/Vps+1nGxDLXuqG6tircmF32Ok VZtZFNEf88DzxFGxwNqmz7HFPSVf1Ig7Ld7SmcI3Tm+FW2MmRDg30NP60ugPyX+iJbG+t76nzwtu m1btWoLUuIBFtG1cwKL+tis23hkesVR46Jt3XXFOPdeiCXs+twxgk6bLRgedTWY6ZayZvQpbxjpl TLTtq+9n+rx+9lto+TO287Pd8o92Lu3AJy7dwdcvzQJil94B50sr0Z1LZ9HTS6NBhEvfQZ/LGoB0 l60AVS9LAoKf2TR5cVkhsOmyUeDgmU2TuZd9A98v6weROLPp9fPBcjZMco9dXY7ZbXUhfpdNbvSK tjGE0F72vIV2zaZxXMbDWID45zWbXmrRr9n0el8uj2s1Fi9/bP0cl7e2vlwvX44aczy9iH2llx/Y Fv8fehzvsaKVeza9yJNv/7PVeza9SFtv35WEP54t2XL83sXd2ytuGHYuSs94e9Rt+XGXv90QHz3f 7cv6Xb56D+325LG/+sym1898zwIgpNccoS9rd80g+iLdNb9Y4nvPPvDzGg1Q2GcxaMdnN9R4m/Xg 6z4bAmI+S5K1kLXrzJBoVtXmyRe2uTeCkT4xKt/ZmGkZm6o+m5MlM7+pn9wz2OSZ+Fb3bJrM9Vlk K2dBU2Ow0KxmPrPRlk62qqW9sYvi57PaFvbWxgWnnQGrzJ5ZnnWMM3qMY93rCZTGqgCqyjOXbO1w sZVlI8uexWtE8jxxPguvKlc/CH/lgNWvqmDqlaW0nHE4s+kyz2xao6hm02UcOpdxsmqlH74UZsk0 my5cQGSZ2HaW1mmEt3w5R37JQ8HGLpOTUnY0Rl6DyVUpO3qz4LDlEFni22F5HBnK48iAwpd4o51L +PGJ8eivXYoDxC61As7X5Jqu33F1CwKrR2FBhEudC4KyR9lBussUlF5vQ0H/9JgReq8XzvNhcl3m w+QazL3MF/h+GTeIxGX6KoKyxzBCkK7Jdc35Nqp03sfly7fbINeab3MNeb6MeWUU9qDR8z2q1BF+ 1cn1P3L6vCQWedTVt9Z9+vw7mFB2rDO/Z8rXNPNPz7z2TFKvog+T3U951tJ/x9nut3SIg+/5R0p7 GW2+xlEg9WyJ8ZlhxsLSZl4XV+C1/fODfsZEVWZJg7Ejj2/q0B4+GmjbzXvD88XWDhN2XD44ao45 W7h+ovFT2BbkYWHGGBtTrtMI9azDu2Av9o1OdMBs305To/wFiGGGxNP55v4JyOAPF0NbWP1bQtDf lped+5KbVbfh+LQ/4gK8smzYQ8H98AevS4DHcu/e/UvuHZkUpv36QT7PUR9cRAKz+pnBWp8qQtyw TO+3ToVesRw0log9sqTC7+GYuDWc88yTZY3X4NxtO8wYqS1ViW/LNJebSj95HW+pL/MGVclvy0Xv oFJ6C6OmuTSlvaXZVuUvasp9tEWAQxsx0CPTE77bPUVrkIK/uGYivlLzfwAH1yTi2lW0d++80Pzw JLe/eE31LZXR3/3rV9j6FPq1PQUbf5aFzWLQw+9fFdm9x+dYzJrBnxKqLd79j0AINmmZpIetM0AX HPmqfTbX5pq/vDcJtbc81iBwP/yTRYWBNOOiwtISLle9dvJwwepy9Vq8wav+D7j8tKSW72oXAmeD 0MNuJP/WP5XdSE6ar9mMxOSjnQ0wXzC3/++2YTGtGeDyo9IynLZI6azzvjZPoS7PDCt2JsF3un2v QdXS8gNT+S72UP7uP7UdfL97If6VeygT1sDlyjWvOKG0fac86DoWaxl028b6HZPg31xHun0dCcJL wbpArFLt37EYrtkCAuJA5tdDgz/4Egn9OoFYAwUEIoka3/Ge2jX+LTIs8wxffCtlKwvHf0sXIJeR Hijw19SoCr9nWek1nSgNp1/B9nPjwV+/YtKUZtLgNDB1PyV/9xKIL0JfT5b0UrhWHWRBr79bsiwn JCHJ9uugyve+dkPy97+bIwfX+Ic5E5yTknIdIGHIM0U7Ja4td2U5c3RKK4N5Wny29GTBWlw1Mo5u 4wa2xYsl+TjVLehUiITJqNaKlck0kp0IB/eOS9BXlcNfnuEGIwAfePCcOc06kOvS3rnE3FW005oX UuBRLEIwLVjHHeq5wx1wXixFFBWLlRP6XHHk2fv1PrMedhdl1poO6dSxiiQzTidyaPj7Yu8z4O6t 1uhfqpnvQQUcfrIglFymJ2GKz2d4j4ya3keWBH6Iq2LOxffFW8U6V+xnS0y7wb3A+4BvZfQPwdmU IbyBfR5637zXwaiSEI+oOGCM74HLQiIx2YoduOIWIJzbhvN2kY5YfBgbqqqD94PvcdobIgaJJ8D1 oW/ifW/CJSFpRKo61PSe9GOtbP3T+xr0vhpVsOi+Ysfvgkjfeb6PowyF1ZJZOOWC+H7spwea5/2M oj8lbRovVJZfZVtVfeEXKlso4pAk1XElLoW0iCYVBln9ILlxKPj73E/9vFtNbKlJPndfEvCbwbha Zt6yLL7pPWuBlrOf+uQweTHnlpVwZF1wcQmhrIe88ZcEoX/YSKH+S76qvXcOSSrrdFltUbKMtlpy CW+U9SGIusKy1JX9Po3NK+kqeC0NZPu5H13K07EqTn+cZlKxGQfvS3Zd5lPqeglbVmseJsv6UiQm ZmPe0+Lwu53mFuHVautlSwO+dv4kLcKobqPWG5x3hxp1AJasYe2/NjbpG9k234gK2WMBCbC+0fHc JTUcGBqGXRPSoNwgVSxrEo5V7NhJsSB8v6EkcMeOCr5HfZy7aE/5HnWGaSC+NbK3P6iLqDMkddB2 wJJlg+p+TwuWdU4cbVzWul+V0YI5Sj5g6xkhttslub3vp9aCLAMOreN7fKPnF4fSho4Vya2ZFcHR b4ZtM81FWdqWScq65mSTrLTpjdOSoD0ldT9fqRbZVzyl9GBRU4nW+wg4+NPQzD6XkLZO5TlNE3G4 nXQa+35c57GvxWg0q/dhmv1MXgvcxT46SSMicuRusq9iGxj8kwVVYqr3kElirfe0Kayv8QNLCQiD S9CPotPk1O9s50o10cOoE/R1yC/SiTjITxbJIOJZt8UxmoBOYZjtAcX4PgOOLw7lDTW9T05ztpSS jV7FRh/iwlNHYVGLxiHD1qlXaCcb++laUnjeh3QDO4aMJhwd+SyW8x5YUXeIqfFhbt1jr6iROOpQ WoQ+++goqvTh0EiHe8M4KTkQ5PSlRaLHVcrQtmaDyStQXueEYgmIwT93mpp9wWppr4F111ZD3Njy TizlZFKTqpaeEtMq7JB0xj0Zwm5KdiDHZfp4hKFWWoXifE94P6V+U2L6GZtBQo3CILG0FmTf1KNl I3Vl4+p5T4lmrdq8JfbS2i/gDm1JISbgM1IoxSwbaTv3U2ohPFDvHzxW9Rp0FCWgW6APvx9Ftw+u Z3DYQVZri9SfkrSa/VvEcEBm+MxwEZy8Ps/XrUa13ddOCqCk7PkQtCVdFrI5NMJ5P4rXJ627e3wQ zK1JpBC5MrYkGn6Ch9diT0Y7/WP7smPBpcLlSpIMrw5D9GcuWfKPQNk8XMbMawSOGGj1Nbje8t5q OtjC4fanwfpVY9t6Vam3/FJ0r7VqB52kPAbTVoPied9YNpk1UEuNdUSNxlq0Fmyf9hX13a4Qv+Ly QgtV2ROTBvbPJVeUAN9rsfdJtDIZJFTmeQ95rvQ0C+ujf5DmqllD4aYKti+obihuya+0lqxPuwjJ B0235NPXJyZp46dZhbDWAntsOTZaEatY/Fs2wyjRW8jTv5VJC7WVu/huEPvCkqWe+oW4chnk9C+Z V0661I2roCZo89LmqT0JNgkQ1E9ZyghbgBTXPQOo9djrWsxHIzbFbJZ45DIuiacU2JEUlA72rW3Z J2Qco0RRDwRxzCrSgvfmgYpjbXMMY5JzjL3U7Cw4vSXRc8/DavR5mkHtej9cjseuPy6Jph5Rotlv jql6duZpNbvfBUfaqOHzwO79I+XZf3KjxD2SSqJb3VBwif+5+cdIW3/m2A7jKWrSqyXmsmyEzPKh Xt88pX/MOj7KcAWVz0ArZ5DE0fxr0ktPo0Otn/eUVW1ywVKHJSt9j9AbzqdMigfGjKl2xUFyvOBw +sfNsnYKNfXGylA6unSQ3O+b+4Ks3z46VHnN9sWPLhM976dlQ/Wq1Z1T3f2cypkDeELrNuQ5UA85 e6DGcp5AGkzpKaImdeJrmDNV+MRw42ozX4k349CO8CkjEYiuNJ1Rz/oteauNNpWLm21MgE1rnFPX sKF63rfgtRqf+gjq7aNnPIeGNGjRZxvNfL3O/cx1P/WYRjVvgTSa7q3gaE3ji/Wfcs0RlHo/+suh n1GTS/vKsRdsjXymZ0HNn3Pru3AQtHsTzF/owtwgea5NFHZsGm11Y2+r4dXi8a0arQTGrUbLUJug 9+ZZtuT+jEHhULN0wRoLDIoq6VZftchNfiknYfLeNEA8IN85QvOZ9U8w8M9cRg9qZ25Nt/arOGOj CmdQ1FSbV5UkWttYuH0/SOh7H9UorfT9BBl/3vuZussEyDOPwDHbDRd4XuQVphsGdhzHMNtsHHsQ HWmKBGLKs2DgwRWfnKMKknwR5uxfEHocuUWmHP3RxrXCJaSMmhGqc0PjlGUkDLrYOM6lIaxIPZRl fAsWpzFqB08BkM+L1C/OUfCrmRXgVlCzhnYflihrEPf4tE3jRvtCGZLPy5vE4vaJGz1RQXVDY3tJ jbMOtiQeon2bW/Or5Dwxme4PAXIZsKes39yiWP3MtrJTgV+i3Nr8hvd9cX7DrUq0j4JMRov3mpJJ S0tp7enIMG01ad+DW7wmHUt2h5jJF99TSqx+TKJ1wnTavo8oRRuSiECsgz8lfXjDmVksjD6dNkT7 svA+cUVwPVIy990JRiHKLC0TJd30hZLIbxGinSOuhkvctGKtfnplEhlcFrT8mdY/H1qmut8372uy lt67pnH+QlqObTmG8SJuXiZRQFzpl73owXktWpSLFqUIliwZNFXSZVn166YqRx+z1zwLRPPD4ZhU 4jePvSXWbfOSJc2Loe3t2962LdX0Yn72zK888yvP/Mozv/LMrzzzK8/8yjO/8syv7BHnmV955lee +ZVnfuWZX3nmV575lWd+5ZlfeeZXnvmVZ37lmV955ldenvmVZ35le9xfl1/521+6nyZBHUKhmuJA OZp/bMqnGJmRAnMCg3YPm2NwQn7VPSS8WLr6tfWYvu1LvhPg8GLXgq+Wol3QCub5heR8bjAUAAey JkRHK07aT4iZ1ijXLEPBcCMJLxavONWVV2LXqAm+wW0/nQ4Ne49ag/WrEk72JRpxXqldcTiANgvh WriEO9H4jO/jfs/kFfCLTFGpfVBLrULoI4b0zO1FCq3iWK+Kg5pFY1zWxO25NUrBcdSX9RqqCqok XKNQowLqOBSm4gSVhGNgKs7ESTgEhtB7XFeLryKsibO+DcKEOCp5Ik5hyEhMuGHIwEUi/Cbe9ylc eEk2qZpwaEyNUjpEwitOpXao+/sZ9X4YVXDPYMVtGfpSklIlJlQCv4rQO5QqMSEjpdmw8Af0UZeY k+ofPrF+gQMsq29N4wW/MMTNBXXxxXptGA7ynRQoJgsGWf0iaXEoOiSzpPqky3AJFIXb2D2AtBrW jfi1LcHilt6zFiQkhF1ffG3k8JaQkI+EUwI6JaS6hFNChH8O3fonWZp5Q3ofnS+UQPBFEpoUns5M SoZico3bjCX1SWaPmoubT1JO+31Om4PUK3KYeqf2SzgaVJJjVZz+mZv0NCzgsnvTYEGsn7eE5hJN gmULKjExy0I3TN+NDHfikKNqx1XgiL+qSxxVN6XmlsnSg6jRklJSrIHaXddIgy+6BE70TtJyPkVv SDezInrqPMINPikxuWBaALtoh+Ujk1h1P5AobukiXMhSdV+RJM0O2qeGAlbfUCUhQ1az3HCgbk/1 vpuu5mj8Q/906jQtm/WJMq7rGaW76LdqJtirhClMkpthT7PZDoOqoPdm0XUn0c9NYpGE+sykM8u+ TSWsJJHZ7BtkkqktWkqmZSiduZp9LUqPOVRNjnOJW7ohAPYlBE2oPVlBB2oaRFR6aFDd7xMTMbmb dWFLtC4QYbcuEGHjSSlmXZC+c+uQEZBKSjAls39INfF9smRUUjKKNCYlzL52S9glJbAIlet9Eix+ MMElPsvlT0r9oX2m/jBS6FlV/1i2Zq+PKUdikq/IevGrpZlVJ30pDbmYdYyi1QeTAtGKWOX9LYUk E9OMbKFl/1ZLO8UmqcWURE/Zl3ZSeKpP2WJfthRaClB0kZR2SxEK1268THrPUaN5WVjdLPuZdlnJ CK1OsCSlRuDcxx6XczftZ1LV7S55tGWcFkhS0Pr2jdQ3QdVlxzgmONuImJuPJ9lH9M2xuTk20+EY JZYcoxwXH29yKXu8gQG1npdsvoO9V88hx+o5NSociZYelen0qNF1q1r9ZolU1Zdvko9Gk8ptf1/j YRdN3tvYLolmTwk5/URNJRLlNzKVFcwiF0uQGRQdh2m+VFXS1CEvmWc8PR/uS2V6AsRxjEM5PW0b Suc9ZXXY2ML0d5JFHxfcT5lSD5yZ5JVFhyO/4bL7R/0oSrxJQ6wMpcO9oWx9FPcX9AuXdj3tqvcL 7890j5Ep6DQthcz+WpLaofxyaG9yjedK2JBvhTrP5Hgu5sdYGtng8zT61+I4X4vuJyGCIQm3RCt7 yUQr9caguNPYiekxzVewWooJ3A9mYQtvLZMc6cvEXNAQ5LrFFLK+nLJx2JLJpC5TxAb1Dc1tYTCP tPo5mxRj7uijRaGF5PezjwvFRxPUL9HsVuG40rsgt8aFustkXnFbWLS8JTGJqRshEhOWOhZNFFWC Qxzk3X8/d4zN02GSuFltJgtFtXrBTH7SBjM1SgvKemZj4Y0hXp4Slw3QWxYkDLmAAGEae9o3NE8P huS6WKLY+oLAsT27eosJfVIaF21RCmw8UHI02XiDHmi8KD1uz7x0m41iLRDTk6BEnEpQAgv4YFW3 V8BZrDWYHyMeTtGO/dK9GYnh+JC2xFUuXUQNBoNz1DgQlOD6YKMo0iQO9Q3VLReVcjk8maj30bwI tBWrzdKYYEtK3ZQtN/Y0O8R0ir1nUiIezldeoZ0SQ6QOF32DdEgHjlUpJpbJFxxP/zyZR3iqLx9s RN/w9D72uKG000vCXE/LI5T36M/0k3pLLdWzdr0f++l8OfywcYUJqCnuTCWj3L4yHWVQ3FDelqnK M0I/OfYy1ew+IBOwPq+sZXNPoVRxyjSVaZ1sVLZvuA7WGvf4UOkBMAVQyU0+k7QkpqPm4VQfR8rq 2DMIHLsvLVAbMwsPjxtU+RZNPTH6mN8nOO+n8eXQj4t5n/GgZzzoGQ96xoOe8aBnPOgZD3rGg57x oGc86BkPesaDnvGgZzzoGQ96xoOe8aCX/z/Fg/7+8Yjfzx5O/y24K+SGv3AS8OcPEy7Y7dXCPoj7 71/s56ckR3h5aOb9Z5/8u/+wev7v/ysvcghvWHvMA5l76IHrocYMWDnM0+6/8u2vdFwzrsJ6OKoZ F6MtKpb2Fu0W1nd9H3UfcAR3wLULXwCEy1e9/dUu08jr8edOjq49vo2X3t/SvtTmX+IUaBwYXd59 7zWnVaOUdz/BEfUJa69xWUZ9Q8Qrv/tj3C+R4nKR3v0+avU+Eg7AX72bbe77HFov892fX/D/cMF3 mRdevjDmxKfbwmzW+O4v8JE1gqT+7rdf61vDHVEX9L1X3JvT1yT23Z+sh8v5TLjFw1//69dPFzJh jMRLckJYhh8nqLe3FpaGv/sRHsJ9Xg3F/hbjvJr5/oJCimlcxc6zU+4vcUD/HLNdb//qdVkZ3O9w n4L9TaQeolfXkzW5wHUSc1a/Zme8ZKz/ZvRkKwEX+LWOkMkXAV69wzvFVj34LAV+2Rcu5+FNY4zB EubiwQ+f5M4VgAeOvhU24465qLlM5h1taP+DYC5G/qAyXLj8QTgcuO8ygL2u4ck1ht/YctCjxfrl zwTn1nRI+BonbphlOCxziT/WTH8GOOINjSTg3JqdEd4XbPuvl/+74atMueqiDNs8twuhU7gdz3qU zZXHJosbZpkv3KjzK+n+F4+NXzMdXCO0VHnfJvTHOO09LDTjEuWlgDnFd7/7ipq43OQHgNbYrVtO +iyVd0stne09FKgVrqzoDfdehTfcW5KhyXYFwZ957d86l1z89ql9NXS++Kevy0t9a7k/XkD03ejR YlzHHCMM3lf1OXWQvOB2QpOdYs4JtjjcMMuY7Cypwm2gkJ01DWbzHwSXavAqU2oMLhcbXvLiZShH Vldo8muX7OSeq1OiFAXssFXnhlnm25QdXM1RxptdOfAXum0p54t9RyK2FHx9sUsILin5u3cuOt87 V6X8xjK6fcRQbyH6TdyB03mFwam0jPfExQb54f6mL5cCrK8unBdAChaXPy8FWHRdinYvNAbrdGbB ZLDgwCxDKRjL9SnYQvYZ4KjmPwj2MNGYFuT5IBQ2zIm6ygD2uobmpBR8Y17miYvnqi7hITN/8rqM QgcZ//J1OQdx+QnHICzKRrImPjD405hxc9K7v3tdTFj+RIsPTPwrZ8du5+Lb987lOZ+7cOw71PZS MWpG3Hb4RT5Lwy0BOS1RZaPDDbPMHilKVSCvUXt9dEASQqGcxpQfLwclChu+ypSrrqHZH7W9YH+U UYJXXtjocMMs49r+zQYI3MBbTct/H1xcenHr1+bsgwmPvE4OF9OMtxlHkZovJvTSbrn4E1xWt/hW /9v0dAbcOrPG0YX5jF+01o33FIUpPYU+8kSVpZvzAWYZ8m+ueXyuouzy5dT8B8GlKNGCMqUoRQQU DnzKtKuu0CQnfvZN1HNNEEuu0FJyIbxG+KNL2bYyXZbvH2dYpYDfxKp+Fa/mIK+6dK184RZI3IyG AqQ84BIp8RmZxxvO2kPO+x8T6IrwSsZdsmz+g+AS5TiiTInyxCavbHJ4lyFsdQ1NBij+8bzqBRpT Mu4HE6/+HeQ7pDUB+VKhv63qpiycsDJj/HKn6IuUX/Pw5WxP7XYGnMyRZm77gllGFMT1wnMmUTDh jS6/RL7eXHLmW1sRdRDNc/iUIWx1WYZtfiMK5jckSWrcFPw3SybTGO1zkvvFMehQ9Zdow1dRECPt Z07NHA/VLjj3m4I4CckpqNHfqJk2BeOkz27UMfiUEeyeA8rk8Q1lkBSMvb7t26BcqQ+FfgvT6lDn mtG3V2wBm2N581/i9P9SqiXsiTOq5Ux/k5S6YZbZVEu479uolnDHt1EtI+1iVMt5bIps+JSRDKqu ZLPHb4Nq61Nb7g7Z/ug1RV6ruyYkA3c5MiSwtZT3bM42Rj1+7tfPpF5e05rXrNHjkJK7EacOPASc S1RH4fBfMMuYY7nwDaFowEp40zVgJUwaDUZ0QNdqYR/qhq8y7arLMiGUbzhgkZzB6Pg/U9RaTvmo 8m+8rrkNYjCfIwAyB585McrV6QtOpR4CJN0CLALYzb8iRt4ESNJfdm7DV5l21WUZ3Rr8jQiwFOYa rtesJSwv8rbnl/z8iyUgdY58z47OcHDZsmtM/lJBfGj+C8qK/bDLuGjqwoRIMDcoPcAsYwSGOZoi 8ICB1CGcgJM5wSiT3L3FUqgNnzLtqosybPMbEXjAI419/BITt4eL43p+rYn7Mk3+JU3/9Wury3Wa 7UuU+htOXrK0VBG4Vgz+4LAcI5VpOm4tN1oL1cDMxGsIthqhXjXg/XgNPPQaglVDZbwGNqJ7jTzC riFYNVTGa+Ry+pHm6Uc6uFsZr5Hq6UcKpx/p4G5lvEZspx8xnn7Eg7uV8RphnH6EfPoRDu5Wxmqk efixLNLuh8EKH86bH2a9VWMcfhhsNW5+pHH4sSRy98Ng1Rg3P1I//LCRo5rWbdytjNdohx+pHn4Y bGHQmx+pHn7wsL9d4+Ce6s2PVA4/uE/ca5SDeyo3P1I+/ODaXq+RD+4pP/AjXfxIFz/SxY/0wI90 8SNe/IgXP9IDP+LFj3DxI1z8iA/8CIcf9LethsGqEW5+xHn4Ecfhh8EsFefNjzgOP+I4/DBYNcbN j9gPP5Yjs/thsGr0mx+xHX7EdvhhsGq0mx+xHn7EevhhsGrUmx+xHn7EcvhhsNW4+RHL4QeHFK+R L1pdMvYzhW9i19ErSgAooK5A/4FZZodyIi4DtVDOGjhUimdPmqeECW2dO0yz4atMueqiTNQFo1co Jw6tkOEwUe36014eYJb5dkI5CX7sryHW/+PX3tFQvr2Xf+tNXm7M91/L7G+1zoeYj50jkbEQMUaG ZDJWYxHOWN8Use5fUOIRRAc+0Mfr6QeH6eSjLSy81Rcyj/E78IE+Xk8xqoVhJbBgRm0JEg4bPtDH 6+kHg4k722J/di/fXz0+0MfHrByWz8UYNfoWlFHLWGgZo8IgWFO76nLaj0W9C+bECisTF6wyAZgw EJaR3V/wIDyWnMainFxH+aoyHWXqFCWBe1N5XEkcu1EYbSqQAB86yv/LSMPHFC44nTIpn7qpGLy+ lWzEx7dSKxsHrRXOWM0S0wgb5zS6+xQxcbWN+igPK2fyTjiQJpmBv4zl1DHHvGmotdaibTZ6tgvu V5lx1aWvrDYL5UvfKsyQCgccW+O4YYFYxKIQeksFsGRsTR4iOgq4lN13HB8TUzUpSptWMH8xZXld oq3B/ZI60v+U1/4ItWP8YvtRIQwccuX8xfKzGBVCIp4mD8Q/lrr7ZfKDqWrU/h7RweVttiOHox35 7P3Ibesuz/AaG7BIg5Le2ZI4hoBJVEgmT35Z3IaddywCpThvDsRi2KFM1fNUTs8Seq+cNpbmxdhF 9QyMjDOkxBCHC9qc43Ap9AOnusukXHbdVNJuM9VDUU03hYN2Ewg3k3TEmGPqc/clDbWJbHsSPuy7 Sz2upk/CLXO2FUQr5vNDPhIdVL72oxllnOeQRC+fw2knpdN+rJe2oV/TtA04DPPyy8Yf6Lp0Y617 TKI5LU0y64IgWKrK/ndKusr3sOmJFWFOZ1kIt/Fz84LldT2E2onCje3HkY6F62XjY+FmKKbLBvGP 9VgUkyX212QMOwxc9kifmOumm1lZbBDYMly6ZPvDtvm/8owYlH0Y3AvuW1+Dfn5rzN+tkfYsKerI VmGt0OcBDCZVp+HZ7DTrCDT9XNjGl57G+TFz1QqqTx5+ftBPUoItaIRE0z6ybvhAH6+nqwUcLqUS bbfVHr95/3z48fHx3Qf93KjzBnfv1N3h94/9f/jxuUGXr2pxOvHyDvv5AdNjLqrbP7HCpQ7/yRPO Wzo/cWDXLsyTUPt5i/WJ/dTFAt5Rz8+Fxsz755LJFuL+uWi/PNTzE5nN83ONbS1fP8NLK6epZW9a PR9aJqe1fn6ut+PUXaNcm+X8rC89zPMzLOLvt7D7Pc/zM7/0eknOfOk9np+r8BjnZ3lZM5pbzEba OGO7xain5UW6Mdv9c8ZTd+n4LbF4ezjIn/2h5Rhi2rIdTOMXPjG0jWoMI3svYjQ/g75U3H137S+y HP2MTi05Md1/KrQislKy+uGMVD6Ww6KkZH4Dx34bkeIZVQp9puBCElObLj9Rl1RQtGIaW+piUvAd Ahm154uy6qMBDmV3/wYzsphFnyrNVZQJls/8pMrRw2BYOy9T6/aZcK7tbrPHPQpVjgbCAeedOm44 V9Nxxsmd3pfGkYeJGVkS63ujv1UNbptWLadNw5aPn7QUAjQvgsfmRaOfJN+o0f8W77C2y3na6K1k ez63DDSOPJINnO7oMtMoY83sVdgy1ihjoi2C0bNvKcXhhJfQ8mds52e75R/tXNqBT1y6g69fmgXE Lr0DzpdWojuXzqKnl0aDCJe+gz6XNQDpLlsBql6WBARv7Xx38eKyQmDTZaPAwfXo/Ay3fQPfL+sH kWjhFA4PlhNLei+7itN1L6sL8btsMs4/rscYQmgve151zOv+yVNhz1jA1fPefYRbeSJo3yMJDxg9 X9a5kOcnDpc8WGPjUD+IYC38uNDEWHHeYj353eN4jxUIULSLS8vOtHj4AAOf+iFtXYTvD4Qv44Et LRymrQ8d4jUMO4fSbVmpNk/dNX/o8RRec5B+fXd5Kb2ct4vSvZ63S8f7IU5bc8Y+DxqLViNchZe8 X0K6SDcunNfgMGa/f16jAQovjYzeztLUo/FBszN8fWl2dMRimJe1kLVDd9z/a5xtleJEiFFzANBn WZrkpPPZGajqvqwsmeGTYNFTcjbFpJkXOBiTtR84m87O95hkvSrnCbKalTNoWbiqmXV22fc5BsTP ff3KmbvmANgW4HMDbAHwOQO2SPjoIV/PrHsq57lm4iofzxwDd2Z4+xx5fNaMEcnwwaafPRfqfeOP LTzeL2xZ8v4W4mxzP82gbW7Wr3ka6aky+dCZo67RH0fK7llzIr9sntl3hMTmnDZPm5vvGvmjzY7T lhPkyl1+6DWYXOGuH5c3znVNDrGt8HZYHkeG/DgyoPAl3mjnEn58Yjz6a5fiALFLrYBz74+u3+Xq hnErLIhwqTM28F3KDtJdpgCrpy5DQf/08ovzg5EBmy4ThKNtLwMF5l7mC3y/jBtE4jJ92OR1O9HY Unf5tljieYwqnfdx+fLtwSBjk+hlrrG//DLmPMn4mHodV7x/5ntasCZ3b0v0AneeLBGfi5LhrYwR 1vDBvSBf+fZX2wvyxTlkQgtr9H2L1beC/PVreKvLT+z13T97XZNL3Ab37g8RvA2Ly9pRsYR+dmzX sGdYmPOGggU7RdLbEpjMyHF5WzYg1avo97ELo882r4a4+wRbJvu7P0MudnniM777wQF/hJYyTi5e ZcdbwSnKF3Z/cF7/3evG5GFZaezIHX8ay9uaLP+n1c3fQ+trqFzd/CEyvKvH42ryz1+5/6S2C82f vFauB5lf0cmX1yVfY+ntIleGjKf27a1o9VOWsel29Z6vURQbtb6wh4NTteZfgnK37SPy546tcsQg zAV2TXEp5l85fuio+Ad4euyKsOPywVHbOpYef6LxU5iHUfsS5o35rybDy1w0iDFFOECS1yj4hnhK OOtPfosSixXJ7/7Va3rro9W4eIm0xZpwQY4+5VrVpqUUa0Iz8hKK8NZi6/3h6Sn6lSuVx+g3X5ch 50AU6DgceGyj8ivndb6iv6sdzmb2uqUfLuFrYXFkdbK/rWlL7qs7q25b3ubd8bvgfviDTaLT2ev1 F/t9clmh7A0sMSm6GxnfvGDNcr5hn3t9w9hfIkwW+3yx64evazBbflRfOszVNCO1pcSr7LL8N01+ suxH6jUMKHF+67jcBLWX4NSE3WjtLc3lbH2JDl9JqtR5gAl3OyFoklwHv1MDDrfmi0m+slpb1qO9 dVsWs2zgkos0an/3G0jYFXIdO+7CzIHLKD/FKiGl50BCzP/f/bbn8bgeZrlkMWFp0pKBif3i7/5m tZoRnFiVljntocPk1TXGrtn9tR745PGKzonX8SX1l5PoH0+EAguOqWDYuxm+BSqktwGX+H79UPJS iox1X59GhGQ5vPyPWFqdl893t/M/rYe4cKS9+00sL5rL0X73KXdepuUiPZbcy5SI5prULo18e130 fwsxfSm100vhCRSL2phSf8fU5hlIb6aIf/dfgORYg0wjsSMuW1mdXNiO5bc/0H0T+EeLP7hiB1su Pw+tfv8DnYJVsK3x3d9/b0O/v6EHPixpXEbic4xYbubA8mCsz46jfrWArz4keARfR2hen4mgNTQf oaXvktAJi/xe0mhYpoog/1/tIP9XL7zH7k5ukuC+/S9ZeF/g+E0tvF9w77bQeT7CyTZJZBzGVZIy 8jjQjc1/MLgrd8UynfMgobDhXUaw6hqatkniG29m6lx6X+HemfpHqk1c9vteeXAt4btWUF7gtXIB ayA4ANYv2ZF4RoKxRKDgThwcY9jOFsL/DiNBXUYF+2zz9gq+KyNYliOz7NdXWP3M8z6WHVoTzl+D 1cfU3NaDWhcvXO/e/jW5j4tZYTTWHK20Bwr89Stmomk+mOJd8ve2xfmdL7FCP4YL0dds97boD6bp 04pM3WWafvwlBvB3vsQUssERa7k+d2r83gMKn6/x4y8p973rWUUWMX9r85Rfdr8MImbcsIaGobEj 2mLsJbdDl9AOpN0it0xwS/vldDU7cRKrJHkKYrcNk3NvqsNqtqrcPVZJFjsLEjV4zbdWfvH5hqud UthxfgxPLuw4PybpGrFeebYhVnfjzA3EhhaU/Upwh7s/xYVlBtn7ZBeNYyFYRazOvqQzgLBUjNe/ LyjaleudJxRmnoPUeRIh3/PkRJxY13nBeFb7PFuRrSKcgAzHck95kiFPtek8hRHrwDpOLMWw4FDQ ++K9TtlOduw6z5Enf/Q47ZRG7EauGBq474IQ3/t5kV0nSxIq+0RPcirh7K3Gy+dxahT5bfTFnVPE JbVpVOXi/Jp0DlTjiZ9ctido+HtdlKpaoAo3zmJIti/pxL/OK+1xMknXRfbgNM9n1MklGxb+gD7i 6RTVISF8Tg6wLDkQjBdsIYubC0rii/VaGAqDTApMkwWDjAJD0uJPk0M6sVH1Y/H2KYGi8Dw9CMRv Oi95wqRJcMz+Xud4cjdOPfWjSUPCulCTEJ7taRJOCZAEBZdwSohO0uk8MRL9kwSx/5Qqo09yvmja VKJLqM7L6dB4cYByXSjhTdB719xCDdnvSz8crJvD1Du2X6t4xvfdsarkKvDnyZ06Takjwy4NFsT6 Q5Rk/WYSTFvAM3+3ZeFJQdJxbUppPOey2e4bUEEn78iO7PXb0PqsfTyNpxNypVZqOpWRtqzx/ESD ue1cJzKR9wY3XVEfz3ODYzzlM0/8lH1MdjLffl6LYZTt5ETvQ65z9yHbivIw94mJPBGEJyJSfjLH /MQT88KWGsCStcy9Wzx9U6d1NU4LdUIWKVC0G4WSkYdjxevdS5DNJzyESROsNgtlIpZ9Mhrlt0jm op0+Rzm1k9mIKU9us6fJS5rOQdJ5+pxawuly7GfR9c/UKc4FSJMS3DoU07l9rT2tkkF8Jquma91h CXRmHawDL4DXKayNJ7vhlNbGy+JpE/yqer5nr/ZTWCfVkdUTRaFTTWfI4T1PmytmVUm1aVbXoCrI rXaRry66x2oW1KCyce1hbFqxVrcRoiSThOoUJgVJdT0b5z21khzkWMaWbIQkhTkuksLkqssF9U+Y R8muemabv6adn3dD41DJz9ozKuEbjSftZaPyMNkRPfPmkjCnDPMMQ9VKbD9vKWo6mbA770G5jass B/tetWUdvksxy6FL7OUdYZv/htGOdvv6aXYqq0sAm0624/k1yU7Dazwncmi0FNz2U7aEOtPeV51b Z+1PlKSs6UJMSdvc0iZo7veSBQWEpZlDR+d0O9PP7Zq+zJ4JyvvMP31PT62FhOUIPAfwvdlInhlo UNmQ9cFP/1NLvTi2PR6ukobDKCvfojQbLze9f26+Kc6M+8xG+qqzmKkBPF/OoGxeQTW/i3Ac/nRr TdX5lGpLYzlP7gs26lf5ZfQK7GnbUDrveelvPNJSbVcDLwx2uJ8yvMRWF7I3nr9nxxjoonZxqZbd v6bL6g1OpwxPtzOYJ8TRSk3r7S+cYnraH6F5epbCyxch8+i60dOg+nK4YPqO5017NXgqni61xaEe fvk1JaJqkzrljBcrUw5x3bJ4X2fceszrmJuuay4vRl+Tel49Gu24Hy7ts1EZ13cmszVI9WmUJR3t 7szGa47p1fKKWNoAXkCqa5Rb9suV7T36Xeyia7fU1fZUkv/aGN14/XDX94r1WzUrzkQXj3VrAA5g IJwar+AmxBME7T2513wnDC9+1s0NlA5s/tE3Gi0gr8I1C8nLbOlzcyUlRxymNXVuILmDI7DsKU6e Vo+la40X5Ha2GuwC3KZLgWXPdO0vWuX1qIRaOu95xTJr8XJu9lznlvWt6zBwstC85tggjbM6jSza ONw0TuK9Tj+mZDSOGxgBGkcItu8jBHDhCAGrg64d+klWeXm2PBhhq9b4DR+/W7FRvzgOvEq87t7U fN7jUmbKKUhi9evYlpMXQKt9nHVDPQDJSC1QthXHsVWz/k1n51PnUUhWxKB2qFmNc6nxIm9ClAud 1Sy5ZS1ys22p11nP4jZ5IKhtSP3jQqnq0sursBuvWC7WfhRn7EtlS4u8PuHC8ZzXPQsqklDiP1xa eYVu9tGvbU8CFMAA4Nzq8sy4RKsZtWGwSW27/Nh4MLNLgY1jpLbG2mRX9zZe+GvjFGk4KPvFIfbW PGReDs3RjbqDs3EbLzHWdfG4n96+yguROVbrcuawrZawxvvOESR19Q/vA/sqyxJ4TqWsCfttVg3S 06N549LGGY5lmHbCnUGkqnsShyakk51/51drSwK5NY9L3ELYUN7jm7BvpPk0G9DlgROXTruKka1v C+q9A/U6rWlmP5PRsWvWSxuMqb3RBHEPexb3ewzIZsPmtmHTLF/0XtGeccygNZzGvU0VXRi++Wzc K8ZJkwNByd/bjt3a7dgxwm7tm2DV7LSekPKuG0LIjy4tR89pD0jDenzETpvHp9QyljSbBy724pzt 1BLIbTebx+urafN4vTVtHnlgERn0t3OkyPbUKJ9FmcSnHAf5FDxA5KHr1Gsu3u/U8kj8ukM2pmBu 0Ot+yjGFdcwKsS2OBCk5pchZGzOIC73CzPfVMdU50bQyvZjXlATL4hhUDq6wOEYr1iJXWFJtkW6k MPSl07bxmVk8wc1rcaRkS2YxSeHmdq7TYrtcSEqIuY0v7JkfaTlV6gEah0qpeHu0GZQX8sPGCvg5 nbaa9CSOepav98FrkUvp6jlijL1s3pctD9vWsu+DthbO2YK1v5wrc+fxpLodL/SMAD8jwM8I8DMC /IwAPyPAzwjwMwL8jAA/I8DPCPAzAvyMAD8jwM8I8DMC7PGYZwT4GQF26j0jwM8I8DMC/P+VCPB3 vD658J5xu0k2GbcWDrj6ceFmV3ssfCLPr/vZ31yrk3kxR9RZ3txBHHX2cRkW/US/ylDUVOerMkKm kaYygqYLhfTc4W6xz6qILo6JZLRMkavK2C/uh6y5WGRRkDSxKmKMoyoFDX9f7H22yJpahU3Ql8Tj yjgx/A3uXcZZdKkyBijvqTJKyPeMIeLewMrIojSVxySpVd4mjyhNZWRS43FVlBX9C8Mic5XRVs2v ea6Seh2MKqkyBqrIQlVkdPWKRy4xhkduJd2EWRRHXl/FJNKhumPLPIoJUdZUeKc55u/YvuCx+8Kb zBFxxiSSVHWo6b3HGw1q/l53OfJsJ1KFm8xxBWnCHT4V557t78NLE1bQc0xyCfH92E8PNM97RsTt lF0+By9Ull9lW7L6+kJlC0UckqQ6rsSlkBbRpMIgqx8kNw4Ff68oq+rn3WpiS21HuYUV5nLcUk+u FsbuJcvim943xZYTggq7vqLk5LVHccV/k3XBxSWEsq6If9H7Yv2rwSTU5Kvae+eQpBKWT7IqS1wZ RcdYIwlvlPUhiLrCstSV/T6NzSvpKngtDWT7uR9dytOxKk7/yjyVouS1eJZBT6nrJWxZrcwZRbZK qSYmZmNob/XdTsOJ8EbVWUoLBr6aKcsijOo2CpFbXrqSCu+t1oU3hfdW57LtVc7Ja0TdDY4avPdd 8dqi++RNUsOBFeMepkG831xlTcKb3wrOg9F4mzpxz4rlFN0CX/ZTvp87Cl26RZyt/UFd5H3dkjpo O2DJskF1v6cFUzRaNi53bXdnGV3hQcnnnfDqGSG22yW5un+++5c7rUR98Zvqi26qzy8OpQ0dK8I7 4tVSS45tM80tdsd60W3wrjnZJCtteuOUbt7Hnbqf6634JWW+UHpi2JHdqnhu8KfwxqknJaStU7wp nNqHm8Sl0zga1XUeMX6jEbxl9WGa/Uxei/E7jNqUxhKM+8m+irCo4uUIlvot35RJYq33tCntRJYL 75JOkkDeyZwl5ex3tvPMm+hh1An6OuSX92SHYhbJIOJZt8UxmkRF9mV7SrTRKVtk36C8oab3yWmu O9CTjV52v7hwSd0satE4ZNg69QrtJCOeybWkKI5G3UAM3mjC0ZHPNEMyOJvuEFPjw9y6x15RI5nj oBaV0PboKKowohqcz869YZyUHAhy+tIi0eMqOkMA7PDsDkLutVRpGu8Tr83sC+ln9qWWU4O3klfj LrDd8k4s5S5Skyw2SkyrsOMN3dGxm5Id5kWmj0cYaqVVKM73hPdT6jclpp+xmVFmjsKMMlNrS7uo R8tG6srG1fOeEs1atXlLuntd7euWc3B/33xedDO6dI+0nfsptZD3tVv/4LGq14z6khIeO+b3447k S88QXwBZrS1SX3P9wnvW+S1iiEirnhkugpPX7+yLUW33tZMC2SL2ksRejqTLQjaHmHGx94zjsz5p 3d3jg2BuTSKFyJWxJdHwm55nUC32hLkb6x/blx0LLhUuV5Lkbrdzf+aSJf8IlM3DZcy8Rt62nV0v 4HrLe6vpYMv4tz0N1q8a29arSr3V/e/utVZFRiTlMZi2GhTPe0bGEQ+hBVBLzXIUfM9atBZJUXtJ Q3W7EizzIXmhharsiUkD++eSK0qA77XY+yRamQwSYlza3pcuWJLL28QpzbpNPBVGs9m+oLqhuCWf d7urPu0iI+QpH8mnr09M0sZPswphrUxJYZSdtCJWsfi3bIZRoregm+zxLb/fniNQF98NYl+y3RC/ 6xfiCqrT/+aXzCsnXerGVVATtHlp89SeBJsECOqnLGWELUCK654B1HrsdS3moxGbYjZLPHIZl8RT CkqSNxm9b23LPiHjGCWKeiCIml6kBe/NAxXH2uZY64dj7KVmZ8HpLYmeex7GPBP9JoPa9X64HI9d f1wSTT2iRA/L8PmzM0+r2f0uONJGDZ8Hdu8fKc/+kxsl7pFUEt3qhoJL/M/NP666zk/YDuMpatKr JeaybITM8jELtHlK/5h1fJRhFshnoJUzSOJo/jXppafRodbPe8qqrqYtPNmy9j1CbzifMikeODIX pTgIj1N2OJz+Ifpf+9wempehdHTpILnfN/cFWb99dKjymu2LH10met5Py4bqVas7p7r7OXVYfErW TbdnSQ85e6DGcp5AGiiaW5iFRLQbbtiCIGuMz5uvlCyjZ08ZiUB0pSlbzPoteauNNpVxYxsTCjON 02ymQfW8Z+SdtRhXTz6CevvMDEX34JhlJO+b+XrMN4W6n3pMo5q3QBpN91aYKxVfrP+Ua46gzXKU h35GTZ6aWo69mNsK0LOg5s+59V04CNq9CeYvdGFukDzX9uI5U9GAtrp5dpV4Wc5V1KKVYO6CloH5 DLMXzBkl92cMCoeajN3THjGiLyiqpFt91SI3+aWchMl70wDxgHznCM1n1j/BwF8nlIPazDIEa7+K MzaqcAZFTbV5VUmitY2F2/er00bA6NJK30+Q8ee93+XEbCfvcprKlVGnu7Jx1PUbzpavK8yVc+xh plyRQEx5amNMioezc44qSPJFmLN/QehxrMohbv1Rlr8w28WoGaE6NzROWUbCUhUGqTCbY2MqOcH4 lrKMzTwFyzJKkorNOPSmmRUAbt2sIbPU7lsYBEr1tmnMS/ckQ/J5s/J87hMzJ2hQ3dDYXhKzRmpJ PJzKOZHHw7KPwmS6P2T5NcqAPY2WHZRFsfrMNJLzO1MlubX5DfOynN8wq0X7KMhktHivKZm0tJTW no4M01aT9sjHyOJpzYFxEVShfPE9pcTqR8vyJ0yn7fuB2VFJRBiWNdNT0idGZere2+jTaUPQKvN7 RdnReqTEbm1KwSlEmaVloqSbvlAS+S1CtHPE1XCJm1as1U+vTCKDywJ7zVFcp4GKlqnu9837mqyl 965pnL+QlmNbjmG8iJuXSRQQV/plL3pwXosW5aIFM1q0/swyBZflbnNBHVLtsiqqcvQxe821GZof Dseknky47C2xbpuXLGleDG1v3/a2bammF/OzZ37lmV955lee+ZVnfuWZX3nmV575lWd+ZY84z/zK M7/yzK888yvP/Mozv/LMrzzzK8/8yjO/8syvPPMrz/zKM7/y8syvPPMr2+P+uvzK336SRsWF2LjM Pn/nd8jkWnGnySIxbs75ddwi86Pr1obPX3vwS/YF5cATSXQyylgC0eyWx7A4tIZ8uwGlK27zuC+I N2BVDMef4RIwxil4M2VgbMjuW4Ekleb3rfAEhZF530qwOfIHf24w44ZLCnDJkGbOC6qaOb/He3xp oZQjTy9ZUrQgxh6S3hOu++lwSLe3sxZmYBlXGtOf15c0X1hw0CxiYdXlz+eosw/0fZ2TwPdRnn8O PNuA84EFD2s1TJt3L4ixo6n3FjFZEFoKLJk8trLgYL0OPNdjvcqBkQl6SwuuijcsiPGS1ZOgEyh4 CXzQCRT4qs6dIBRe7IQJ49RqOuNSTsamFpT0Tb63ONaSAdIP7zlDD2pf5y7w6e5ftT7z/XSqaN7f 7UuaD0k6IJELmpoZLfySz+cOLPwBfcRT4wDkqzsHVJbf6sYLfmGKm7yajnM/9doxbDa7W1A1WTDI 6hNO+2lwKPRTPyRrnxIoCs+2ewBpFdbiJc9YkQSLW3w/rFYOjO5Ntc+ILTkgCO0zGiQJpwQg0rag JqwkIY6/TrFALUWD0ob0nictkC+UwDRdQhkDMbklXyjX4EUMSXPX96a5mIcvaOqpaVA2DXIOS+8S NJBzO9OglA2rmJz+MVk0ie+7a3DqruGpbAmNyeKEZgsGMTHL8p52ht8tvJM6VIuS0KpxFqprGyOj G9UsE7V+JtZgNEU39AZ6KjxxZz2n76dLD+lNBdk7nkdgMOcMupedMrnhvsvQbjTdDEwOYNPrfl6U DRMXsJ3Z+9B0by770Kqw48yrZcFDHq/sAkY/SYLON5DUYMu7ZA0jpmxF6+I6Z4lDveAJBLotnpLR umPFPfNpyOYP7Zv+YDKPfc9qEzuoJd09m9WCl5BcUjtlkvtiY98yix3tDgV/bzo3zA9TPzqtEvs5 59YpeGTWp+nWoZnOcU4y3SoJqu28l5+M+tq7Dp2QZyOrJI8HNM0bv7MjP8NnqD3tp7ROrGNWjzus adW4q5qU4v7fbFa1abe47Kcg7lvPx2p3l7EhWJaucyyBDDquveynQx6Z6NODRhjw3yicNtUJtev9 cA7Sfnb2z9qv3kNyXRbe5OK9pMR8vs+8Z7ovOnBXNO2NQ78w2qOu0QYjbqAvafaKfCAWhOLmjeGr MxKS1wp8P4/s8DSF4BwXZRxD4cveMzO0+Je1q53aj1JVow53/huM+Q126VvpRr5H318urwr7zxc0 tGvdoC5t4KkMHRgJ4nvUGXrPtkby9gdKUsKGpJUyNraMCarnPTk0zEYA1y4tZRndKx506gIlPjhE 2e79SHSnxLcN1Rc7aUCWEecPOBT9fZPEC66OeUuObZ2Hq6RhNcrKo+hVfRib3pSohDu1iuzOFOy2 d5D3sLaDUk3IvC3BdT91XRkhbl+hU9spwRx1Mb5388Z4UgftAs+TIMSTI2ys5v7/eUmLvNjAcyAc zqcMz3fQzesBGfARxA2MaSOISyme/kE+NjxOGejP0A30tBjqY4uPkPSjWdsanW6o7z6O4H7aCMOh aP4SytLjE5RfDj9M30HRJu4Ewu30UFmBqZvQ9n2JdSg/ODG+jGll0JNuMxD0lqeC/NxoO7MsCmg+ bUyG7AGWTsxM3U+AzDZ0wMkswqSVgbxN89ZheyYtiqDq76PewyJNWRS0RNpBcmcoe1yYtMX8Pscl 4hTCtgSD8gUpEBStJN7Db1J9+FKTvIN/Nc1WY7YxSfuw8QvEn7NzUmym/TRD/llHvprayuh1DE4p +GezqH/EpeD7kDqD8nlPWocj35PSgUgBoI9mC41CwXElB2LeI5/wJt04rhBK8bynD89aycfYaSNn Jgc3XTmGujRI+ohvkE/C/mRJUOyCD/QLpzhbIUUoG/Ae/XukGMc0QWVDwhezQvWCHGPPYjwSE9nL sPnsvBdHf246PWsgvrATs46t34CN6nV6T5uNCmilbUrQogqq2+JOjjWCpkPm4bFsrzaqzD68/T63 rOL6UsNEUBPE92U/Rf2BPsJuzS5ZpQRpLAP+HN/giU8b9UgPjgjkB/EXZLrQvNeRVEFL5FaVLiOq N2txztXsnKuSNFibWZPrCtYrztm9/oKL6LugpO8vKIpmfE+ssz/tLMmeJr0HVoi1zkn6dNe1Ybpa RR9avuQUol4iqqda3XDpopBD0SGdc6Syjd8CBVv2XpmHwfbpd7DXguqRldBdVkghQdYS3xPetORs gVLsvErOy7i5Tq4M1SffGFsgrxmPkFSYLDXBLkvTpdpoRQkcW1aH+wmitVkA0o9Whd4HbW03u5xc 1kvcujDF3201KCH8Uo0vR+9MC+tLCzxXlfaM8Adh1kK0mi1E07cWzKMQ3PbTXdIsOttiVIf9nZsG 5lEQC/oZ1H1B0d+bxE3dMUyJ1WpwEK5OnRwEwu8yvRx4EaQFehQJJD1w9v5Ryg8cvQy1k/0yb8T6 mKy3v3CK6WlTvV+oPy1wVBA0HTLvgWXpoQnKL4f2zBdB5Ro+hHubm8HsDbDI6n2PDps30ILWlkJg do0RvBStWUPBD25zW9AaGyh2C0U1Op7rXGlRzGF8gRYE145j4uBlxaWOssgjCfuWNyT97sAKUWk9 pVXpoKXpfwctaGHYPuLz6okyPHMUweS1QeSc2+KgWuYvtqDct8r07F6WfZk9E1QEvXfKIfet3goK wvu9UxNZFuGIyLo9q3ofnQaUL1pWYqu1o8JFVtgoS3tJ6L3LU90cAjZTHh56FC1CstjcIj0kyKJB iE7bbBdSFamF4HEMZUPV9a1FereCXD5jjKd+dFmP9AX5fRvv14MWGa+I+CrjimEKMqtPmDoUAAeN Wy3KNyjnW2yBGhR3XyKoaLYhQDIZmwjg00waFVqY5u1RQsCRYU+NizrrVRI6tyxOSi24oFwL7QO+ mmDwSaGEQYZU4fsirO19ovySFuIotDNqHTe1M5qukR5Z/GLP6K/BokR6pKLndC9iwW4vIv29dNEz G+1lSWO0WXaL5k9m4hjM/sZtiV0eWFb2N4mytMSkxnu3C4wP0SaQ2rRy0+QpCz4S+ZFWijI8mdWG qSZNOSbb10KSzJonYtwNzWUyXDIJPksmBU1/H7ePueDi9SmdgTQwOTEaCRNIJ8cNo2HCcNsQMpXm G5QEvTcLiLKyY2qpZ0n/e7O2+KpDeUNhWzeEXK1WaGbd1D9rNWSzmZI4WA7Rx2V2umUSNFwPbFya 9L/Khqq//9kz9/TMPT1zT8/c0zP39Mw9ffLMPT1zT8/c0zP39Mw9PXNPz9zTM/f0zD09c0/P3NMz 9/TMPT1zT8/c0zP39Mw9PXNPz9zTM/f0beWeftmWKpxPV7ATGsaEBxbxmuucEADRcVAZ5+GUyin0 w5aqvMqUyitzc+oo0yjYOHmr4OrLDyiT8VwXWua8qFbqYPA4R5SarKHnBi8aE844j6sg1JxxGlfR lt0F40tIBeSlGwWbgxe06jeJlMF5P+0OaZhlLWyPzrhaqmAjtL7UNNHNS5cLtpUvrFASU8a8NJ3P 8D7m/T4Cwpci6+j7YXiroBs2Qi8I9TVRxV3jBQHuBWXHf/0s2tKccXFWwUblhbRRZUHosxzGNEEL OIRpohZcyzRIV6oMzjcjvKC8oaCS751TcEPTYnvBtvYFJX2T74PRF/elF2zEXhD6JJXEzemkpUPV 30fhx1oYBlInfZp9SRv4JR24iWxBKAkDmJZIFF3UKawBH+gjnhoHIF+jGN1VT1DcHFS7woAc5Lf6 wZAYwFymXk0WDDIKEI7+NIwNtVM/RGufHBSFp3EgSVqFtXg5+pZgcYvvZ9jQkYA0KRfkcPH2Z9kS TgmgBK2xRVhJQhz/SWmnXJlcLshklRKWjC+UQPDFJFQpCMkt+CK5Bi9yJIdUPzbB0ltB1KBsGugc lt4hRLCKHg3KxbiSs9M/5yaa8z2+j6GAkDQk1y2hOINPGiBbMMrLsSycsui7hVMWnERYLCWUGvqj 0DTrKj30c9d6HmuacXZkadPs4MK1KzWFMwsPvL7Q5XiR9w4vM7/KDD2PFzxQRjYRdsNhcKCXeJ4X c/PIBQSD2Qd8mSFB9aGblYZ8dS0m0Bca7QbabMUsiK4ZlNQwwJ4mvtMotYvqFmrH6Yyly1HGSZEL nsIQz7thRd0aPFRP0j+ysILMj1yszUH9hXSPdKzWSC6pI9GqoX5sW2YZnhaEgV7vTedYSzKPlmiV oDMWfqZOdVot9knax/d5Wz2EmWWVOnWyWcn3JiWqX7taFRUs/I2zXQsDxjhZ0/ArxF/tF+AX91Pa JNbhEXbWFm1dHU6pVkQ/fr8Jlv0cuRmmI5vNGcLlg/NA9mdDkEHHdVSn1WAttzSblmlTGBAtnSDR AvIxaB/FweAtmX1l+8kpLK66XLyXlERh85n3LEkLWlWpA3002uspaYMRFyfwkoqbdsSCUNy8MXwh uepFpZTw/Tz9beyvc1yUcQyFL3tv9gIeyzB7UfBcKWScHrvhgnawT1+lK/mOFhWgo1c1qIEZPULQ yCBpA+waQvYO8T3qKMCothBKUvsDJSlhw6QNZWH3JGOCqqDNoWE2Arhqc7zKKMVFa6Yvs2eE2G5v R6I7JZ4t4BulCu/3ZhlHBy0FBX/fpJGCi2tEi46tAk/CpVLijbLyI0Y1KeTT7HZnYYtA+Wcm/zPm bXsZSqe1ZRDZoL7H4kkN0NPkujLn9hUGtZ0axlEX4/uwsRjj/qBdAAaCiKW9L0G1PjjX5MXi/NoD l1MmpQMv8S1TqSmc7XvgePoH+djwPGWgPzNIGtv0Pva4Iev3exuTmDC5IX7b+lhEL4eYrhBMP4+1 aJudC6bleK5kcFpNLVhaDv9iNoOBEaVEUNuQ6E948D1q0ZuFh2zhUbVLux3QS9p1+CLT6A/PnKFB nAhcGETEOeI1KK2E04NroIVEUN+gcd5Dv1QL8q6WIKXePuyMvlq7YwJ5nVpkRtvC8Cyt+aQmwsrM Eba3zAQCpYahfvGrW3hV9Wrb4/xUSpBWcVKr+D3WrEOtEbOur8hWiobQKQs804thuFj9IY7Qbwss Uz8nvf9CehplCL03qVV/09xQPe9Fb9SPTfxaUBYP+T46Pcg5WjNChr/gtp/CxsHfnGY/yOXaTf8R sg5F3hD5V4NbaMK0UhVZSPa3hrLHhorIN+lVA8dVJExDtnEd7WrsIVT8fYpO5Ro04qAlznawTCLE bYkrQ9/6fjR6VguCQ38rg77QcIOSlaR8Rq8fu1qlXahBy31AxRo49oWNXyB+RkX2aj/N5AL7L/zY VkH/kFRCbjfjHG3SjN9HfQQcpSmEkOqy0KNoHbvbH8K0eoR+ITkyChWWnRpRajBvgdQSXdOmNaAc 3LOqiEVZLfpAbEkLetR+2XQlL10apEHEN8oOsT9F9pJ0LllyS+gXTnGkb40iJsEVeelNMcqJoM0R wxfJnUCfhxyjp5fCkRhaH1JBfO4vB0Phy370IW9jCjYPowYfkWuQxhPKh1K0CIToy/O90ppqq5mv ULHywKinVBjG6Ro4DhODtm2heS2UMJtNUIa0ABD2+MB5l8EtEPweYCxbC1rKDEtOPAmH0z/KqsPj lMnEUfMq4TNdxpp5VjXYLKUkpwHS4TcUTx/llWTR8OMnDtf9tL8cLognkBAEDSlDqw2EWylDA3A1 /WVQmzodU3BPrUbpRAZk/lCN4Ugvg+4GBXsfZvfxpzKIql7OzRMb/0gb2m7aD9rzNARtaaOVpTQP Gx/3e9Kc9ck5WmnyRPMiHpeEgO+CHL84ib+WkE72aj+F/WMdC7CyLQb9KSWiVAyiH7UF9anz0BuD uqD3Ruug5T/SUo0z7RGS/FOLSCuO5ZNcaYeWoJsoLChvqG5bHGWLG3rgXoEFzNk+eyiuk6suF5IS 0liLX9WzKKkFxZkQod7c0LHSkTaSVGLEKbBOOVQkPoTC3FB1L6kyTC4u0l8JV8+pufKNtjw5roY5 +tHkZcCaRS0eouWK3W1k7D4SRBuFKfWNlGYL0SEtNRAl635aOJMBZWz8QWo3ZreGkXaV37R5L/HK 5iU4VFSS8sen3eUPLdHuRC27iUj2xgKpHMQEkjqIn+QXdilifqanmI9ELKqKWuwbsYiWvZakgxKS 717O9+WRRSzMIi2EC9tiLdlX3ISz4OAYYoGKnmmhnsHJ6xf2BW2Wfr6Fvkg2CmnRDy0pURzPSDVB 87xP2WuR1uRFYv2xfWFSSFypyXld6/W+ey30RFJh40dK1mt9lVLhcmVWNOjin89s9NUlQNYe51bU rLl1zKIv/DJ9ST5ldJp1zJdkW7RtxIfzYfbWfF1iRg+YmAmqgsjlrrIfXGK0tBOvDxxPmTb1PcLJ LznKsU9dfkR47P5Jyhxuu4xshJaH08dQH+PYkLX3ftMuvjxAUd92TzFSswVVjmyCt1Zx/uJc0BJ/ XoCiRV8QyQpFA55Y4guk2McN+1gIwUMNXgykZW2Rl/xEGxezrl5RDV4/kxg/oWzjtSiRuAGIVwEp Ehh5gRDig/9ve1cC3sRxtiXrsmT5xIBtiC3MJWOwtYdWUjgcSAjhKARKAwSCCWf7FGogbUKIsWjT 5vibhvQnbbhaJz2eQJpAE0oCCcXhCKQxYAgY2xgsn/IlW/exu9LuP7OSJRnktk5r84dH8Dx+RrMz u9/7zTffzM737gwC6aXQQWPQ2ahR3N9LOHmhR/HnwlUW2EHVqJ+wg3DHDnF9jzvACK6tcPpH/R4L 4Q7dIXSBEQ3l1jm5I3OIgK9UB2pxHgfl5kvcoU1EYH5HBJ6K+g996pkpooFeBNsMxXt6AcrNR7nr gfkqHN1Qzo9xx+dwa37ckTqBlVA4OqLcOOg/AIpQhPTn70XQ26N+Cqdf2uD8HsV6xlcUC74lcUcU BZ6BB9HgmrDr2sB4hHK9n6uvRoMjB3xVDNyfW4VRBTQQ1Ja6Z/4AX40C8qm1QZ+Fcv6VO8KI6Jkp 9LSWDunJ9R/spOqxi8B17mAlrj7XmvBJfpsL+Ez/wVKcteD+Y416UkToOkTtrwVbA+GOoMIC1qbr sTH/EU5Ba/GPP35ZuA9zuGOluE94uMO0Ap/ocEc0cdbKHcuEoYpQ+wRGVlha4+8tkPbrP2zI7zf8 BwwFLD2Q5uyb+ygHUofhMlegbGBGBinCcJE70Fthj+ZSmH91F+GOJFKpg7ncdSA75n+jhEO0GgYp /ffHYHCceyaGBPqXzp8GUqEwxfUvdfA61+KYn+LFWQLmpz1x+g2msZ4nc8cOwbUj/339s17/8/y5 XC34DPhhGKYKyMCl8R4Z4cwmkBfAALXOzUo5H6BDe3yAThVqdTirRbgjurREj331rD0E9b0+GqeO xqmjceponDoap47GqWXROHU0Th2NU0fj1NE4dTROHY1TR+PUgVXVaJw6GqeOxqkVWDROHY1TR+PU 0Th1j5aiceponDoap47GqaNx6micOhqnjsapo3HqAYxTb5HB77IVhJrIg4s6m/w/NQTG/dwow+FS wJ0/Vbrwnz11obNbMkHxI9kWhUoBuvAkeBQoBvdqInRqrsSaTbIZs2X5D383f9GsGbL8JQqdLP8x BSLLn/H4wwqtLP/R/Ec3yvIfeXzKlPzHt65b+4M1Py7aqkDUoEbRxp9s+tEzsDxIFm19RoFNmyab /Yhi2wH+SF4Ty3d7fTW3jU0GY1Nnu7GxKTFpyLC05AnZ2RMnZaftTLDJZs5WLOTkAhOjgFxw0wEt EVkuBO+nYLDCnZKt8TKt5ndGV5l9axtZtt1dtasi89a6Vas8tq7cN7yurk9e+Zv2jS3msUdPvP4g b/nC4fKQlMDB90iJASmxPqTU9FdKTQQpV3zcdG5DyaGssrqjOzxepnL4sNnWDfQSe+xsYG9TXvDN n7M49rFpLLV8/gJz6c9v0omFQ3XpvDZhRmNIXtAre+QlFIRGE1leVNVPeWGFu9p7Ku8My3/l7VPx vraY1MxEibD89Knh47XZWqympX2YLPb0Xz4Ar/w1lbeMbXUWp3fsiFHmpisCzYIHxmT4LB7aTc+4 mfllmOhEUHQdEB3vQ3S0v6KjEVS9cf/fH378tZf58t+vPKHc1Kg88q6HujSLGPfS7tyqHUzFuvbv P0ue+cBdUSgYqly259aD2x+6dLOhvWD9SxXsxys/PUt2Snhr3s/EQsKDnh4QHtg1oUH6EF7dX+HV EfQ+j3eU5W/fc2yUWt3w9Y1EV9uYhYs7GowCt+PkP66YbTE8s90RK+PxeHKpoLmu9XvLZtbUNH19 uXqsNnfe7MnOLtN1o9VldX5a3qB7gDpd1TnOlEuGIdEGkahBm2j7QEL0FwkRAckC3l9Z/kv7j496 UHW5wiDrMlp8Al5iqqO9vbmxO2XUSO2UCV+eu3G1zQHAeM3kU08Rq6dntzrduw5dLyAUJO1zu0mS 9J2+ajI2tXRZrdPHyi6tzH85BEYb7L5gbtE3mP52XzRC9+Uv4n3A8n/x2bUURmA3dwOJKxrsNrcr JXX47aYWeUrSD5aoPztbd/yyEVyaPCFj39NI0eGLs4mxX1xqQHPTu5xei4uKE/HPX2uTMpaaBiNp dRYvn1XumjgvEh7gmAYDz94zN2/UdsRLxHaSEksEEp6gwUK1O50OJ2tqNA0dNbzV4nZ3OC/+8Xsn K9ve+aRh0xM5KXGC+jY3AGmjvGKKqTV23aw3mDroyubmFJ49Lg1jwvAEBycwoyOIPgYntL+jExpp eFrKe5fl7zt0oZEWxCRI7VavwQTtamic8LaFkQpYkBbFsPEi/u0OB18gKN0+ua6R3PPR9blTMydl JzV3e2iSpRheu9VZa+iqqr+dwqer6ruHCshJE0cvWz3pYERUmkFBtX7PUbc3OVYs8FA+r1Bic5IA Sb3VByCxbrKT5mUNkVbeMmVnpfxw3qg56IgHnvjg/L7H2ixglOE53QCXwGJzObpdX1Tf5LscbpvN 2N4ljaFXZ6iFIVRg3hdARUBnjUZGhSH9RAUr3IVqJe8dlr/s1U+GKzLbzS65WNTtol20j2YZs4MG qEgv09btOr9r+r6Pao5VWGqqO4rX5126aVs3RyES8Gkfy2cZl4dPMV6ny9NmMtfUGbu6LJ2dVpOx mSRjRD7z07bp/4iIDRsUbE/tvxgrEHp8XgDG5PACVwYssMXu5bCxtI+x2D3fnzv686umdXMVuYpE UQzPTTJAFyw/BpRxUSxNexnabWi13K5vbe80d1ksHQ0t4BLjsk6zTQ7HpgtiA1MCta4PbFh/sWER xtWTm+1bzO1LDNO8QxpXgxnWcbahtsqs1y7bW7iDdLqzHt/ZcMFc8NCiJ984ii76zqM/t7e8XGoo YdatWy+UMQyd9eWqdU9vZ621tRVldWXs5q7uoxXmgmKvx3r5dxfYUzuE77VPmifkLXxYo4yITzfQ +A6cst9kxutPlbCXL5xxULVFzxJGfRkbtxkt1FudraVsQQlLkrThSKE+pmvdwx/86ZTPW17+D8pt KFC8yJcv3Zte5vP8hHLNQjJfKi04VVBs8V6jK3YVlu1gPO3uBeafyk5u+hV/wcSpP4+ED+4mNbD4 3l+2tePGgtefyyp7ZeuH04ARlu8qOPD+vAPvXzTo2XU7f/pyUVnZNkdD9cRdpfr0Eoa6dPHcuYqz lO32c0+vdJW7p6UumJo78fwL7K3yV9WfLjlSsN1q9NU+l1U4dYe35eys84UG4cxf8CdsIOwR4akH GB5/LW8/y9/yx4ryFqfD45XHCsFf0N3SE8QdDspDMy4SdsDDxVrwVyiK2bDr8uWqrjc2YpqcpAfX Hwcus8tOVjbZk2OFYESwWG3nrrV0GDuBf+nqtna0NDlAlpNJFHl+uXzqpxERagcF4XffLAcAajoc EmEM8JQAWGZybKPZAzIbO1ybF2YXzRlf2WrJTU8aufwjkUwE8keny19cNWGuIjVxw8f7NyOP5KZd NHR2Wx23m7v8CO3dpsaGJpfDxadcoLwsAY2IEG51OAgIgfs8d8tM0owyTe6mfQ1dbjDC1bba4+PE difV1UW++sP8r250uymmaOFo4ChLTzRUNzu6HZTJSiVIY2xuBvwFxfg0vX1lVmdD83VDa011SxIf TMNibBYbTyTPHDH9cESE+KAg3Hyo8sPLRoCQorxpKbIkmShWHHO73dli8gDR//DCjDghRVK0RCxy uEiRMOaVP9ec+swgzkwckRrrV0FqAiggVuewqswhjk6Tz9pdUddsbW91uTxWOnZcZvwvXtGwERFq BgXhWydu7DhqEIuFACGwKNB0GTKekxU1m5yrZo2dgT9g7bbafayEzxdBC+UNTxSDv0VvXd3+ZE72 MOlnFe0SvmfUiBSWpq5UN9bVGts722wWSxDhssfUczarIjpSuOHmICC8UtM0Z+8N2mmGU0upMJYv jpOKKm/aXvqxNkUm7nZRWfESMKME8MRCPiiTHCcSCgUSAQ+M8zQbI4zh0TRt7HB12aytnVZjXZ3L 4Wjv7DJ3mEAntLq8H/5qC/8gOi/SNEY30NOYNX97r3YL3SIRq+pbGhtXechmwTMlP2NKy96feLHs i23VZQxTfumri5e/ki/+/Ox5T0uV/tnzZaUliJfx0Z1m9oC+TE9R8crKaT/Z9cdphreeK5x2Ss/U 1yx5nS3c+TOe/XbuoYiwiEGZnc16/uAtq9dosibIJfLYWJtPqJ6YNCItIzFJApopI17spFmRSBAn EoCfqbFCkwdaMGgsr5cBL0qxjLfbRdrMlo9PVqmyJW3NzRarvb7WlJvm7eQnjD41KeLME5jnADfZ gVPWx+ounn3yf24VTUPRnT89ePLNdw7jcdhwiWR32vDaC3pWV7P0eM2ynYvOTJQXsSqVj7TbWw1g 6C/xMb/Zba2gFxRMK/Y6SN/LnW8dsWx5ZsoL1P9aqz4pLWPmHb4k4U1unai8+y0I53b8HIS3INGc l5Pj+YnxsS6PgKadGWPGjlIkyaVJQiE9VB7vZlkpny+RxvCE4mRJjNkJh0PSzfh8bjvpi2fcHVa3 1eH2mFq/OHsFeMf21s7ODrNUIjpan7M7Iir1oKDavufYvo/OdjnoCekjhamCrOyRXjFc3JHEioYm yt2UUCr2SqRx0H1IBGbSJ2Y8AI+Xos1uUkY57R6vy24nzR1yl/3qLQMo5rA6dqxZslE88au7F31w bp/VAV30WfPahA79Zvf59skLSOG2guL1iGuLh6SHCwQvTilw7y/V763WVtfU7FyRPP+3GgPLSzcU 6H/2Rsw8faGecplb3YXmlfyZmdO2XfaQo3nFlePW3L0Ih3N7BQ/oItyaxaq41bwXn9MzepZcfqHS mZW7X6mp+qSM3VOt3dkIOkzS0xtK7HZzaRm7VF9Mu8wGc34puWdZoX5buYOu3f9WUU3N0rTMQsl7 Ql5W69gfh62D6oIo8H+yDtrfYQqNNN9f2/KbJ554YtWQ3Z9taZIKBGf1K0sWItPnj/p1Frt05p/W bhv7yN6Cv5MO2lBmeE2vL6HcdtpcWPb8HvbkNnrowT2g7xdp5vPTeSUHshbdvZKLQy7ZAK/kXv+r 5cQLzpMHT2YIBIKs8iMLCkvQzRbU6/FSLc88On3s228//7Zht6ZwGVMs+Ij1kZdsrGb8NTbfoOef MJzyeZ5tSuX9Zb5i0d1L6Di3d/iALqGvkc+dUHNsh70qv/D489vS0tKOH3+e3FZdsIOUrtXTVI0K 9VXunvWQq7RAzzBCacxpOrGwRM+OOncmljdaP+K9sDhF0C3BbZm1qj7iFP11S0gEt7Tm1jPNi1fM uNH5VkX65w8tXpHypdHYQFItvzz5u6rniNNs1u9Zr7P1Qpa4JO+3+VllD7351FJNMk8+N+MPd4dV cG5X8YENq2xs79hP/LDmkyOl6ZyCC8uKL/MEG598duREeQGjUrHMO4ozVkeuYPKIuc/+VcAzDk06 HpIUDUkKxmddH56xv4JGknPKDsZ14MS11w3brZ2Vo78XL9jygO/A4wt4+9C41/3yLJSpFPD/olmB xNYNsi0ybR4G/3EZ4ek1mxQzFsvyF8FNqVV5KlyxeD2oBuAgEA7QOUYoEBWRh6GKxZtky5Vjc1R5 KKEFU0elMAf4TlyDapUSkAnP9lQRypicSXDzaK1KpdMph4MSkHuPKkU5eB4kJGHKxBwsD9TX6pQC UAu87RLgcqggSIFnqjB1+E3l4LJWh2hQ5YicSQjIVePa8OorlP5sXKNWjgmV8N8BQXA8WAJmJ+ZM QvPgfvt4+DNEOQhIq9R4ZLlEsD6uURG6yAiSctA8HFXp8B4RgSkAZSBARZhWueJHUC0YocVVuDIu qLdxIaFCmSG1hvJ61U+D8sP9usOFUoPnw3bpq1Jq6FGhtujVWMIIEoAHaPLg54kBgIiWQwVqAaWh OkRJQHNAIcENKOOpxXNkOKLL02qB7SxeC6wlov7ksIm1hIaTECgInuLQW5Tw1gprzzttCxoKgYeX CBnKN1UNihJ5Kg0OoUwKYJmE4n40ERseyIrAfdOBCfXRyuFopBHtVxoZAULk4ToM7407VCCUkobM H6hFB4wbUffUAjIg2n/L/oMKi2y2YbYQJvqIO7sbd7NwKbh76dR9aSdCN76rrcMNssd2w70PkQe6 G4EpR+cg4DKG9wImBG2qA4pEYZvOXAz84xYZDj+xDZEouJ9hrAkceLs7f4ZIFPBnRBJFcLyCn+x+ C2gAwekA/Ah5YKcD/Ad5X7D88oray3bWI5DEkc7rx/6UoZ4zPHcMXIT84pLL2GBsrktKy26tq0xK Sm1PHjb+wYLWxi6bw7NuquL11zLnRZh7wQ+pv530BSC69ltHXwi+c2A4MsDvHPxHeSdY/oFTN3xS ecPVa4zLNWbOnIzEGIeVkieKr1+qvnDmKlwOZOlbtm6rRTwyWd5shoFabX7mMK366xutUr7H7DTV 17vTz46NQMEAGPD7g4IBkGjuGwoGjqlV9wUFI+ha1dj9R1kAqIj7j7IAUA304qp/4fjDk9dOtJJ2 Dy9WIOx2QaaClaI9FOPzMZSP7XZSaQkSzZghv/20jnbRf3tlysGzTe/+5usThxfY3XQwrO+nLFyp bjJZrHyno97QBC4Vr5r/a1FBQiRs8ICp+5OyALANdEz4nlIWAL6BjgjfU8oCjmkGOh58LykLAN7g BIPvGWUBIBycYPA9oyzgmHagg8Fr5L/fSt38Zb7szAHNyuL1PMHMpw/TRWXTqxMzdxz+zvXr303Z V9Z0utt+ZGf2p7biumGrqzKLrcfeXHGSvnpsfOn4MYe6j1tMxtvmy+Ni8jPLtlEm8t1dwD5LPO7W itasdC2j5/P+sg4/FBEcdn/zMQDCgSa13WM+BkA40LS2e8zHwDHdQBPb7jEfAyBU30d8jNDLAjxV 876L7OPw1ND7JbIffP3G4Vmrg/D6HTdlnSsmAUgzRC5KzkjLycmUigVisTghTmpxMxKpmBUKwdUU qdBs94C00OPwkDRFUUk82uqg7G5HW3Ozw9Jtc9Jw3O5sJj8f+2pEPP9sbeS/h0f35PavrjfFSr0J SQkdrS7NghleHyOWykYkyew8yRAxGysRiYXCWCHPxrGAXE4XRXnMVrdMyAdzLKvN6jZ38T0O4ARN t+urz/z5SnXuHyKs9eDIP1se+bYwL3B4nvO3nnmBI8S3nHmBIwP+Dd1/n3kRjFrg6EBHLf6rJAYc HrP+/5nEgAUNGwUDtraPmRbSX8NGIs20lLwqMJfcs//F1/a6nPa04alt7Sb49hUXn5CaZpMmk5R3 RBzPJZLvWL34+6YkaQ+14RsSGdQYcieRIR1GQdXAC2HhAeDeMcy7mQghlkB4sDKsQFjyLibCnbm5 MKnT4urw+yaDonDzcUSnHAavgzqEOjw3FAJVw3AniuN9UCkyYOgV1xBI77B4TxD336cxRCR6hEqG ZfYVDA8LLktyEG0e3LFGicPbEhpNeDS4FzfgXwXTs2ETYnAHrHBcgVsArfxn9AKOzYBDEXvYDP+K aNBn3LynAFQ0pIQSxL8bN+9TD/0Nm/fiNfhRBXkN/QilRyCGfCPmSbjMYVBCBcbcxZmA7IaA1ghg dZFoMiGT/obqC/RINRrezcZFpG/c0cZh+s1fROAhH4QCZauChJhh4LmIDtVpMGVmSITUUHIkSGq1 ah2KhxdIB8LgGFBB+A3yYU9H1CDV664I6BMaTKN8AMpHoGoN14N7yRfuIxFEkxe08BVbYZdCgMfR 9EnqkkMb1arV2shEpDDNjofVUAQaUUibEbkuvR6QDVsR06C9nGlKDnDFeSiKBVkcC2X/By2yCQJl bmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjMwOTQ4CmVuZG9iago3MCAwIG9iago8PC9MZW5ndGgg NzEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztnQl8E2X6x5OmB7SFFgRbzoa7 AZvMPRPBhsODa0GxHihSoAVW/4XSogi2JFQXRUGKCgKi1msVV9YKrgJaGgQ5yhVdxIKFBtrS0os0 SZM05/yfpEemkFbq2tVmln4+5J2Zd+Z9fu+d5Ps8SRMjUhQTI+6/5kTSklDZLFq8eHloWigml0vl ckrc/Lqk5QyFI4g4JRQjSaRVuvl6SuhfQx8RLw1NgydSCFyPwzCShgPIRbfk8pSFIeK7U0MfgD+w AcEQEgVjMBqTE3JIEIhcDpbNuq+9q+mLwVhGirv/eURw00lLxBMToBwUFWO0FEpNWBSKiFFxHDxJ LEekpFxOiilSiuDwmrAk9PHYQAmcRWiUwGJF7iSJYwTFPRskiSOlFEMSRGxfCSWVo3Kaiu0pQaUo Ssnp2DBJHCKl4SpGxYo9aYTCMJp72yB4GEogBELH9oaknEYweEQ3SCJyhMJJeWx3CYlTUgpDn0iY GnpPAlRPWihKUDSYijQ1hueQZrCmGkdByU2HKMU9bL7X0zyjm9qHYMRx7qpCCRoalmlpmolTQmWT HpTNum9iqOwRMUqFyiaL0VDZxPsniZlQ2b2ye1NCZXffP26c7P70hclPJj2dmi5GSbglNeWZJUuX e26AdGr6cjEeHx865W7xyreTHK4K3fvDCnXO5BKWrSx94WRMvmvRvHkNdssxS46q38HLRXu1h54f uGGOY/zXO3feLnA9GR0ees8U8QMeS6HrNFsKWhiqDUvlHbVUfrOlwjsFR1jhx/uOGyP6N9h0wXVG XVV9yLARpV+9E957gKleHxYeIRAIyquv9+/b+8ezP/eNjq4w2Qfem6CrMw3pLlh7cGCJ125K3mw3 g4HdiG+7MbyDdrtvuMnuewX7WeFJTdGpKntA98AGUUiY1fTTVx/1J6caIvqMGBh54cjp0h9O3HZ7 lNv6suLI6KEOc231tWuRkX0ipz1UUVJrqG+ASwvvEu8ZMWS6VwNNtmiA4ULTbWggO6qB9KFhuuBL Vrjuvfwezmu9BgzVWx0RIYEnv8uPGsUMZfA6m5k12b/77J8ic13c+HvA1gvnLpZfK+4fPfTnS7+M GDDE0D9m0PD+zrqGKoOpV1DwySvlx18Z9ZhXCYO2KGFACdGGErqjSmgf/T1lx4FJ9294KSvrCo7T Om3uzNw5m6m0zYUPZjrLP2Si7BvXnlSwFQEnHrvzLWHByailB1Sux6bOunzBGDH19pHjX/uE3dYv ns1gnaW7i3JPl1mlWmWQ4JGpI3CvGjnSrEaOiimK8a0GRzqoxn3DTWpqHv0iOytrwt0zSmSjNIfX bw1ilUr7G7OPnJz2Sk7lyWOJ4xwpY2xvZi5KXigQFbPqrLJ3ZurilfNEWHLgqnfz2AXvy0Ytmv9c 5S/LhRtVCpXrzhX2rz7uU/pCiFa4kBrF1YS3aCLa0YR2VBPqQ9Pbq8uHiCKR9Pi8p19li9ZbTuV9 rLyeOzg+yeVaqCkI0ynQ7t3rFM+5NgrDVzLbs8reyNBMGvaEQulyllxYP61iaR/q49Wr7eUnvszW zFVGXW6w2Go/MVqKHz/hunOlkxT8dT5u9QqDFaxFGczksOr4VkZ0VBnhYxQtFmxjhS/u2HfbHaNh kFy8dDW0trzOKRqMxJVoK+orK8tKrvceMpAZN/rTPcfrbAGQx2q1iszwKnjiCWrBhKEXa01h3QKy P/2JQQdZLHDR+UuFsaLK2i9Mf/p8fa1eP2FEqNnpgPwp3agVXJXNcwUJKz9FYW2o7OhcgfuYK5LG rXaZP6cV3wdao6Oji7WrwodrFI7w4YrV7MjhQ5UW/YODh2SdWna25OX7og9e1nwVZR5y7/iju+4+ 7HhmccJHdycsDMx+d3Vsrth2pUi29OGj1dkKNVtnOvvtzJIAdml8ptlY+si6ewXPXpNJfevDO1mf 8CnBFlaYmXNw0LD+PxdVQV33CAk2Wm3BIaI6syAqVHSlzlZpMtWb2JqSGkevnpDBUmUag8e8v4yC dN65a+/vvfJaKn6xwtw7THT5msVgcwTbXA2OhtIqU8V1ndFQV1NlP1dWJo4MgvwrHhrHFYqiLUJh a0C2sTXAOzpV4r6myre/MjR8qD0VHh6eo3IFvD495aJFmynElGzS5pKF+fYrMaOMKvHWLZXs3+/T jVh5IXr7dkvC2Ltc7G2xK3U/avrt+HzlY8fx3a7Ch3rvYx32XFW4TKFcyLKWEy9EpCozlc6SLZGl uuqI4tUOh2hn/A/3BglE99M7fYuVd7JY4TJBNitctO3L/tFDLpXVDesXBnV/qcLkCAwxmKw9w0Is lobLeiecZC3WarvgyQdGrH/3h6Exve+OixgV0xvOT8UGDHr4nzTaL/tJ2bW6Br3JbmVFdQZzgKPB YHBpK8rK9Wahud5iMBRdNUH+PsHGnyaODeTKbd5MkbCDpsg2NlN4RzdTuK/N1ArBy6xwd97Z/RVW uz2wweno0c09zVTqWfhfb7NHBAdV1ludTpfNyV432aJ7hjw7e9TDa0/YzXbZqN5r57snsJ2HSz/Z 8u8De2Y5HE6jxW62sXa7w2Ru0BksVltDRbW+stZQU6cXmurLK2shv81szpw3o+a+GT19iyY7WXTS hpqL0s/FFoOTDg5+MVEVLb5cpFOrWTZpYfJzJuuoTXajRh2lyx9U/ayjvjQ1pWL7DnruQyOqcZQN mfrOAZPk3LSs9e9YYVusZl2sy8nmqlT5Sru+1q6Zmag+sJo1nbZnp2qVK522Um1OzpqqxHH2QzbL XYIh70wt8C2Z6WTJg17Z3eMQEinQdp98/x7hiDBEQOI/iNGeCwTm9yeeEj4/6uhG7QqXc+SyS5Vn as4Uzh4rXJNQdi7MUTCnfMmrR/JeVo3esv6xHOknp10rx6ZsrT73/Osbn/xl/KlX4tdvfqp//9Ff xt739AthfTL3fZgxbuy/3sxQuAbd+XdN1Io3p3P1Ys0bIhJD29ZLdHRDRPjaEIXvyKistuhYJRt1 OdlV55SJRKLbxgz7m/1yrUWnZp0OI3tMp1CoWLupWnNkyvVHclQNZqMuRxX+/MVd44+oWKcoffb2 fvAaUeZyOe31tdkLxoXfachcnJrvsF09uYPOURxgHQ2mouyc+IC+easd0ZOfK+ovEiTPn/Y335qJ /4bmS8dkME9/MGdXRLEyBMtnXccKTnxfcMJxvShV/IIweHC+M//zowHHG6xbJySsuVowZtOCRSNH Kgf/vFU3PmX+3BV7Sw4cWpBn0RwgkNLpTz+4ympzgtLEvFWs+dIxt9JzoHSbvpCe8MB8wfsTUaNv qTRvpOJIJ0sVrhK8yAqnbS7Q19t7hAQGBAmv660wiRqtzsjQIIvNCbOye4Nod9Xobd+uiz9XXD32 jqg6sytEJPhQXTz/3uFwdfKqQx+vonv3DLlaVS8ZHDFy6ucJDw/r1U1kbqgfPainqb6+psZ4rUan 1+trdXrIX1taajC5urH1n98z4VPfuvHObuJ/VTKGq8dipig3ahSsoB80tYJ1bC1LyjBdLczWsmsu piomPF/91B1rhsfIpqXYty8v1O5J371iVKXwnlNk0K5/r9hVnb4p8vJKu7Xiy0LtM1sC4zMd9Q5n 9rczi5WsudT4kkZWnKeyXy/NjsjNqsq5a7W1slqh/DlGULBw0je+NVOd3q3fTbeVfyZbMC4lRuWw WitiRKLDoLUsUD74APudIDh77uox3RJOWGapbY5JCfaCvakq0Bxwz8hd6pDND71Z9uSMH976otx8 vfc0V/0Sy+KMd/ezNhgmqQqnra7SaJ+pUKqsjpLTdo2uOC/TeftOl/MzeoM6X9hPMOH5u9sQLe9s 0T/tupArPiU5WJBZ4gqBIQprMqyrktDll1T2V2Ecj7PN2bHz00+G93k4bc3anLDYoaOOHtEUBCSv fHzdExl1C09X7QizD7xdp9xcPnJ36aEvdzyrztge5nLYWWt19gZFvmK12XH2WLY2XhX8D7bBYDVm hw9k1QLBxCcp312baGfT9fsoTrhDCxslxaQRWTqt6yKozMoSHt8SVZ7ndOAyesAmu7U6F5p2xaLq nG/MUvr+2opcrZp1PLil5NO3VH1jM0oLtj6bqBT2S413lZQmB2BrXoGFaumMB1yuas1ni3PhIC+d tZ4eMPPqiPEf35VhM5x9aWb4rnGC3m9M+ty35Ha2XL/jLDbk2W9hnuoX2e1KVf2Ifj1gohGJAroF B1yqNDXOXz27B3yQMTEs0Ga12U32gGChIygwAKatFVv/DZnzv9UGD47oExEcEhRgNNmEdve7LVLC 3keMqKy6bqwzCu1Wp/66prjszEX3zrqfqEpv7zZycI9TcQzrW3c7+67fp6n7FFw4cfToB8c1TxtN smDk8tVFb5QsaLDlmFhLzky1a8qyR57BXnM2XC+tULOrzkcPeer8o9FB+2cPqXFURuUOVH2Tsmf9 69EV74dF9P37Wthrmhy1FVtztYpMa6XuE5ksUd1Qf+VwtixnzStaNexA6fs+ekkiuP4043sLQnb6 tmvz6F+s9uqMh9KyimSKL9L3IAiyDNmTtnzP3AOmKVMeGn4k8Z5162sv7U005NWoXeiy5Rh2cI2Y HrMpef78RYsXwfvDsVHHWC273cU6nTXn9u7NiT8zJ+NHzYwrh+3Paothj3b15MnCVFbp7JbAWp0w rF0pNXGBglkyerrPnTXZzq7r93kz8XTunLSK0pi0uT8bLdo6/Rc4gtQtW5ZpO7ngH8Pe2yU2lh5T KIWb3usjKyrUsvtn95s9e3a/g+P/9kLQ5HyrPuSQ02m35ChYpYo1Xy/SzNQp6tK+2HU+fXst+3jc wk+jZr6b2dBgtX9Li5/YpZqLG4SCU07E95sIsp1d1+8j9e18/eTiU4dn2F6RxR/4xvTW9qysCetq Yzb12bIV+2lLMPbotv0Ms+37fefjXXaN5rsTJ0JniQIP3SE21MYEf6xQrdkAQl0uu0Wbna1TOBvq 9GdzExVKpXP3M+eWjvjLlPilGxfPTFTa6rrv3PDC2vnpS+IFb21EYn1+EEAhnf2pR7LpqajbSqxO +xiFLATW4b0xp8Z/vfmVf3zwvGDTycOSg4cMj29+yWJn2ZqBu96ezkY/ej7a5ehdFixRsqaQTcmO k3WlhWq1So1nsoaqUkt2Yr7K7theWbG1KHuu+rmGhL9stFw1FobPq7taGiWYFI+94Vsn3tk6d721 +5mfPz4cjojPjDkz9NAducONJp1qxYyl73UbG/JZrEJjSbwj8+3p01N2je/1tUqx77tZOpUraI/K Md/ltBTmJKpVykyL9VhOao4CdzoMziL6vYB3U3NkxfsjkvOUpsGTv154RCAYUCk94Vtgp3989YcI 9H4QSck7+4PWhB6yDHO9kx4ZH4xEls/vu/l15Ic3bdbstW+8uv3VV1/N3mE8bFGl5M2BGvi+IGC4 VuXS56xdq9fElCsUSofjtKm6+phMHa9iDZWlx0ClylrXc2f52UItbA0P7LcLjgcLxIfiknyqo7HO Vpe3zJi2qLT+wUcGw8y6bJnrym2XM0yOHa9v371zOJujZs8z+z8K2hePfxGW/kXabldS0nzrmYND jxtCdjacjYi0llboVColazOVVhTGpGpXOxoqS9U5WpXSbq49SS99U6XNd65cbhGKogWCmhepJF9f CZA02clfCSRtGF2lTb8cCfOMJUdtDVypyFx05bLjw9oag9Eie++9cQrLjhyVnNkXPXt2NKwet32/ 0uiM2ORg7ZrsGO2acHOuLlFlM+sqLDnafNTVYKgtipBKN74U8S6udJ3fFtM9QSBY/1fpLh/f5JA0 09nf5CQgYQvWZD2rcrErjeUKmXrjZ9WKh6kHln6eqmLTDAanw1qtzY0ZHzS05tR4w2mNWuVyibBH VZl2sy6mwhKTq8hbaHPWQodU52cuKL2S5DC9ekX/zHsBgjl43NM+vnAjmU7/wm3zv9OS581b6ax7 c8+egB3bLu5YLCvOtIn6WDUnZaNHHpcMN0DvQvsumdv9x0StOs3lCt5sq7dr1doN0BsD9rBOxxmX xb5+b2JWytFE8exePyuypTkiTPB979hZPr4QJRmis78Q/emLuv0Zprydef0PZ2vCB+Zl3qGOX23t nizYr81Xuo6OPnrw4MExYz5cuCAwedwq45arGjoYabBU0LLSXJlWJbwA40jQ/a78nj8FCCavG8YR 0fIdO8nQnfwde9LF5WUJM2Zc+USmSFRnnhEEf1Dy+niKjtAUyhLXfLTutUH3143dcZmNEAcpVE6r /qUsqyVi3YKHZ2w8O22scPKGgR/4IBpI6FadSzQkpVRW7aD+78Le3Jx+0dH79q1y274m9Py/aphH x2+IUUVvU7HzrpbNW5xU0HOFQMAe6LnPayfRMhXDiKbkbUzFaEenYtTXVPx2fNKK5ZpTqYkKXCyU Lp0rLhg1VP/yg5HHG+CtNkFPSnsuQIAOCe/utQ5vGZJgFY2gbVjX0SGJ+hqSYJ157ZjCjdrn9NcM 8u5pvYKDgx/qIUobtHrYqu5j8EkC/T/DNjaa5iaaMFLs/c9DMbU6c2vkEi7GiFbYEipHpYR7gZTC yuhhlnpJQDWJo3js7W7iiMRonCBiUQkiZaDJaDI2SIKiUoQmsDayes9CTk9GLDbcfQ+K4njsnKUS 2D1RiJyIDXDfJG9MR0niUClO0aicmyNEEodJCQIl0NjhYAAuRzG8xQC8EY8iEZqBsubEejIgFEZy yg3k5AiAxyIIPKONEoIkVNNdg+B+Bifh8uCWVIyP1Bj30wmGwRiUU+ZICekxBI+Ndj8cp3CM4Vzu 7rUz3AN6uS+3pWSoxM184WgrUWA+5EaasvTx5vYpBnGfbHyEVxenOblN571rlBsro2GtRaFpUEbq EREgcSNkBA2i3IhfQjJ0l0h3w6E0yjBQPCYlSXhsLAn1yxDup4vgHO5JcVq4v6feUAQ2m5wiud3B WzNBEgzz5HAXHddUdhzGSJnG8jtWGR3sh5wn31oLNQ2MAd7O2lgBGHlTb0UbH+EuBsdhpaS4fB6G Mlw+z3PoBfIwHJXfdNjC53kO2+XzMFTeRfg8sLRL8nkYhnR5Pg80+AmfB0r8iM/DMNTv+DzQ5Kd8 HijjAZ+HwRDzZz4P9PGDzwOh/OHzQCyf+Dzow/zj80A03/g8kMwrPg/DCN7xeaCZL3weSOULn4dh JC/5PNDNOz4PNPOPzwPRPOPzYD/NNz4PJPOSzwPdfOLzMIzmG58HkvnC54FU/vB5GMbwgs8Dnf7N 54FA/+bzQKAf83kYJucBnwcq/ZfPA3H+xudhOOJnfB4o6vp8HojognwehqNdgs8DO//EfB5Y9+fi 834Lewc7bClzC+xdK6DuJvSOCyMN9ya5tFGEBAoi3bSVTwaOy2iheCPq1QRgMXIud5buhqNoGoxq Kh+V+zSUiMXdt5MYziXofLF03nzec94CuWBWGzK9mduvu99ikheX6+0V3inW4RxEra8Ew6WYu9mG NeJ2lJvQbKLtOFBba4SMQ6oFSeJwqRwjaSZ2jsTbtsN9onFcQLK9lm6vXrncGk6RYoZp4dbchyjK EM1R/bjp5mwtEf5+wxDCEUpKtRpCvhp3kISEfAxOtVjaYqvHoCZDSYLEm43jppuM/o+tJDApwjRa 2bpDNY1pDrwYIEEJz0CFTgCXKQrBWgONzS3lHbGcy9yeGeE+jRIMtJlvONJnd701qvJX6F7OVMN5 mE/+tbH7u+MZejssB0HtAEg80vt4bt/2SYN6pDMMNG8ryJVosptjQGsJN9rd4dmAdGeG+fiGeTqw VbqRtaWbh763qEaJ0Kmo1rI4oKy3k3NjaS5pFWaTYJDW6VYhN93MKCp2/6Uvvil8J+EJx+WOxpm+ MHTR6NbBOSkPacp5XmNwTswbnNMDCcOcJqURNzoLCcZTQ41Ye5tXbwlxh6EnbzX4SBqDSUtMUFJU 3hiXM5aRJDzVWEVQmgfVFt+caLSlrau3itszUoS4wRyYlcSw8mN0c5TQgR7mmGAw92SAwyRBeMKB xhFSqEzEHQ80jpRiOEZ5pmBYHFB37+zVOIUwmDuKKKiTuwOGDnL3IAqDrb0c5j9vOoaT9uZxxxRF Ya2Re1ZdWGcYWNJjh7jLIGgKo6ETklIKRUk5JwXLC4pJaRxlYNCQYLccc7PNzZeHSuLAFoRh3PMZ DiMJFiL38IEZEIGlA8YOnCRx0oPE0zCM5JzHhEAKwVDP/qM5m/ecN98wuMrIGTnFuTpcQmJu8L4V Rs1dZ5a0XoJgpLZK37gcdZbHxX+0ZLUIWNJ6mXIL4KZbLVmdrOR/y9r/lrX/7rLWaR0aJ29whmrV YanGDsutkrZkdrTpmscKp1o5HarJKYUifTkKMXICIXw7Cnnf1Iz3Dpf2nZvG3jTvpIXCLp/rjOI5 9Hqf4LCQ3XTY4oziOWzXGQVHyS7ijAKWdklnFBylurwzCmjwE2cUUOJHzig4SvudMwpo8lNnFFDG A2cUeGvi184ooI8fzigglD/OKCCWT84oOCrnnzMKiOabMwpI5pUzCo4hvHNGAc18cUYBqXxxRsEx lJfOKKCbd84ooJl/ziggmmfOKDiG8c0ZBSTz0hkFdPPJGQXHcL45o4BkvjijgFT+OKPgGMELZxTQ 6d/OKO4fe/VLgS0fRGKEHzuj4BjJA2cUUOm/ziggzt+cUXCM8jNnFFDU9Z1RQEQXdEbBMbpLOKOA nX9iZxSwrus7o+AwZ/42V5Q5kltg4jhxdVshTK3yt4qXTN3gi0DR+M1GMSRF3rKPx1jf/hzNBXEi GXNN5JBVfdr0uGiui5G/ghT+13iypvJ+PUI2t3UH/Hp7tRX5uJHqY8CAZrDv1zgzr7vPjYBfWihO Ya2IM/chBzGjSflNh17ijCZ/jTij8K5CnFF41yTOKKLrE2cU4S/EGUX4E3FGkf5HnFGkvxJnFMkH 4oyi/Js4oyieEGdU5/++25+HOKMoXhFnFM1D4oyieUecUTS/iDOK4R9xRjG8Ic4ohjfEGSXnJ3FG yflHnFFyHhJnlJxvxBmN8I44oxF+Emc0wivijEZ5R5zRKG+IMxrlEXFGY/wgzmjMz4kzuvN/veuP Jc5ozJ+JMxrnA3FG435MnNG43xFnNOFvxBlN+AFxRhNdkTijya5BnNHkn5k4o8muT5wRJHJDILxb Z864QXJ9BJK7ldi4wRJEijWGZPP+cD0n+lrT4xCmOdacnLrxaVwyyhvgrTVndSPGdmshddvD2LA2 whI3Vc0tBWHjBv2lbjUGHYcJu7FWveHifJOAnHroUAg+3zzd0KbAyJi75zThZm1Ratz0LZFszYa2 EbGvpf/8J3wbgSJcvs1z6AXaCAyX33TYwrd5Dtvl2wgU7SJ8G1jaJfk2AsW6PN8GGvyEbwMlfsS3 ESjud3wbaPJTvg2U8YBvg1XXr/k20McPvg2E8odvA7F84tsIlOQf3wai+ca3gWRe8W0ESvGObwPN fOHbQCpf+DYCpXnJt4Fu3vFtoJl/fBuI5hnfRqAM3/g2kMxLvg1084lvI1A53/g2kMwXvg2k8odv IzCEF3wb6PRvvg0E+jffBgL9mG8jMJQHfBuo9F++DcT5G99GYJif8W2gqOvzbSCiC/JtBIZ3Cb4N 7PwT821gXdfn20iEkWJ/HN/WUwKtiyMEzb2xFePluY8hSJ9xwtr5WcnfD2W7q/2IbH8IytbcBG2j bL/t12TbQtlaKviGNvAgbiTOQdz+MJTt5p8i/n/v4BCNZW5kc3RyZWFtCmVuZG9iago3MSAwIG9i ago3MjkzCmVuZG9iago3NyAwIG9iago8PC9MZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJzlnQl4E9Xax5OudIGyaVu2hr0Bm8yS2QQbFmX/ALGoKFKgBa5+hdKCLFIS ipcLl62oICBK3a6ici3g9QJaGgRZC8R7EQsWGmihpbQlTdIkzTrfmXTJpEyq+DmapvI8dpZzzrz/ c95z5kzmd97JEEESGBFBzL+mjZSF4dJphGjBkvCMcISiJBSFi5r+Lmw+gqMQJEoLRzAM8thuOp8W /pfw50SLwjNAiTgEzicgCEaAHZCKaE7luhYCiZ5MD38a/AM2QAiEwcAYhEAoGQU2ZBBFAcumjW3t bOYCYCwpQZn/XCLY2ykLRaOSwHVgWIQQEnDVpPnhkAgWJYCSRBQkwSgKE+GYBELB36SF4S/GPyqG JShFkWR8J7AFwzhFxIeJwfVlkAwi4nuJExCwjZJofFdwlCIghMDju7gTdBMnABthjMTiI90J2GVh KC7BEfilpAnhTyUB5RnhsAwngBVQYz27dgkSaaxMGBj5wC6Ms3eb8rpqfkhj1ctIUQJTC7CMAG1G Ntf6qPHh0tHPSKeNHRUufU4E4+HScSI4XDpq6mgRGS4dIx2TFi59curw4dKpmfNSX05Zmp4pgjGQ JT3t1YWLlrgygO30zCUiNDExfPyTohXvptidFdoP+hdpHamlNF1Z9nphXIFz/uzZ9TbzGXOuMvb4 zeLDmhNre22eaR/x7337HhU4X46JDH9qvOhpl6XAK5osBVpI3Iul1MNaSj1oqfBxwSla+MmRs4ao HvVWbUitQXuvLrT/wLKv34vs2tNYp4uIjBIIBOVV93s80vU/l396JCamwmjrNSZJW2vsGyZYd7xX qdtunGqym0SA3RC33Qj6kHYzGR6we4zgKC0sVBdfuGcLCAuqDwyNsBh//PrjHtgEfVT3gb06Xzt1 seyH890ejWasv13SOaaf3VRTdfdu587dO0+cXlFao6+rB6fmPSE6NLDvJLcGAmvWAHoCQXjRgD2s BoxDwyTBV7Rww/sFHR13u/Tsp7PYo0KDCr8riB5M9iPRWquJNtq+++KfgabahBFPAVuvXblefrek R0y/n278PLBnX32PuN4Dejhq6+/pjV2CQwpvlZ/dOPgFtxISblZCAiUyL0qIh1VCcPh72p5jo6du Xp+dfQtFCa0mb0rezO14xvaiZ7Ic5R+R0bat6wrldEXA+Rcef0d4rjB60TGl84UJ025eM0RNeHTQ iDc+pXfFJtKraEfZweK8i7ctEo0iWPDchIGoWw0FNamhYBGOk9xqUOgh1TAZHlBT/fyBnOzskU9O LpUOVp/ctDOYVihsb804VThxY25l4Znk4fa0oda3s+anzhMEltCq7NvvTdEmKmYHIqlBK/fm03M/ kA6eP+e1yp+XCLcq5Urn48tsX3/Svez1UI1wHj6YrQlt1iRrRRP8sJpgDk3vri7vG9gZykzMX7qF Lt5kvpD/ieJ+Xp/EFKdznvpchFYOh4XVyl9zbhVGriB3Z99+a5V6dP+X5Aqno/TapokVi7rjn6xe bSs//1WOepYi+ma92VrzqcFc8uJ55+MrHJjgL3NQi1sYuDk1KwMjObihcCuTPawyGUcvWiDYRQv/ tudIt8eGgE5y/cad8JryWkdgHyihVFNRV1l5u/R+1769yOFDPjt0ttYaANJYLJZAE/greOklfO7I ftdrjBEdAnI++5GEe5vN4KTj5wpDxT1LbITu4tW6Gp1u5MBwk8MO0qd1wJexVTaNFRi4qeM44kXl w44VKMdYkTJ8tdP0JSH/PsgSExNTolkZOUAtt0cOkK+mBw3opzDrnunTN/vC4sulfx8bc/ym+uto U98xI07vf/Kk/dUFSR8/mTQvKGfv6vg8kfVWsXTRs6ercuQqutZ4+dsppQH0osQsk6HsuQ1jBMvv SiXc+lCe9QlfEeyghVm5x3v37/FT8T1Q1x1DQwwWa0hoYK1JEB0eeKvWWmk01hnp6tJqe5dOIIH5 nnEoGvfBYhxs51+5+8HhW2+ko9crTF0jAm/eNeut9hCrs95eX3bPWHFfa9DXVt+zXbl9W9Q5GKRf Nn04WygMNwsFUwPMy9QAfdihEuUaKt/9Wl//keZCZGRkrtIZ8OaktOtmTZYQUdAp20vnFdhuxQ02 KEU7d1TS/xirHbjiWszu3eakYU846W7xK7T/Ucfu+XLFC2fRg86i6V2P0HZbnjJSKlfMo2nz+dej 0hVZCkfpjs5l2qqoktV2e+C+xB/GBAsCpxL7uMVSPIsVLhbk0ML5u77qEdP3xu3a/rERoO5vVBjt QaF6o6VTRKjZXH9T5wAHabOlyiZ4+emBm/b+0C+u65MJUYPjuoLjE5CevZ/9JwHH5rwsvVtbrzPa LHRgrd4UYK/X652aitvlOpPQVGfW64vvGEH67iGGH0cNC2LLbZpMYWByjGNeJlPow06mUK7J1DLB 32nhwfzLRyssNltQvcPesQMzzFTqaPB/ndUWFRJcWWdxOJxWB33faI3pFLp8xuBn1523mWzSwV3X zWEGsH0nyz7d8d9jh6bZ7Q6D2Way0jab3Wiq1+rNFmt9RZWuskZfXasTGuvKK2tAeqvJlDV7cvXY yZ24RWM8i07ZXH1d8qXIrHcQISF/S1bGiG4Wa1Uqmk6Zl/qa0TJ4m82gVkVrC3pXLbfXlaWnVeze Q8yaPrAKhenQCe8dM4qvTMze9J4FTItVtJN2Oug8pbJAYdPV2NRTklXHVtPGi7acdI1ihcNapsnN XXMvebjthNX8hKDvexPOcUsmeZbce+PBjiegzgJN2Liph4QDIyABhv4ggjvNFZg+GHVBuHbw6a2a ZU7HoMU3Ki9VXyqaMUy4Jun2lQj7uZnlC7ecyv+7csiOTS/kSj696FwxLG1n1ZW1b259+ecRFzYm btr+So8eQ76KH7v09YjuWUc+WjV82L/eXiV39n78H+roZW9PYutFmiZEGAJ71yt72AmRjGtCFLln VWWVWUsr6Oibqc5ahzQwMLDb0P5/td2sMWtVtMNuoM9o5XIlbTNWqU+Nv/9crrLeZNDmKiPXXt8/ 4pSSdgRmztgdC/5G3XY6Hba6mpy5wyMf12ctSC+wW+8U7iFy5cdoe72xOCc3MeCR/NX2mHGvFfcI FKTOmfhXbs2yP0LzjTNSME5/OHN/VIkiFCmgnWfOnf/+3Hn7/eJ00evCkD4FjoIvTwecrbfsHJm0 5s65odvmzh80SNHnp53aEWlzZi07XHrsxNx8s/qYDCqbtPSZlRarAyhNzl9Jm26cYZReAUp36YqI kU/PEXwwCjZwSyXajVQU4lmqcKXgb7Rw4vZzujpbx9CggGDhfZ0FDKIGi6NzeLDZ6gCjMjNBtDmr ddZvNyReKaka9lh0rckZGij4SFUyZ8wAcHbcyhOfrCS6dgq9c69O3Cdq0IQvk57t36VDoKm+bkjv Tsa6uupqw91qrU6nq9HqQPqasjK90dmBrvvyqZGfcetG+W7if1WS+jtn4sYrtqrltCAWNLWctu+8 nbLKeKcoR0OvuZ4uH7m26pXH1gyIk05Ms+1eUqQ5lHlw2eBK4VMXsOD9/122vypzW+ebK2yWiq+K NK/uCErMstfZHTnfTilR0KYyw3q1tCRfabtflhOVl30v94nVlsoqueKnOMG5eaO/4daM8+7WezOt 5V9I5w5Pi1PaLZaKuMDAk0Dr7SCqzzH6O0FIzqzVQzsknTdPU1nto5Ns5w6nK4HmgKcG7VeFbp/+ 9u2XJ//wzoFy0/2uE511C80LVu09SltBN0mXO6y1lQbbFLlCabGXXrSptSX5WY5H9zkdXxCbVQXC WMHItU96EU3xLfrH/dfyRBfEx89llTpDQRcF92RwXxWHL7mhtG0B/Xi4deaefZ99OqD7sxlr1uVG xPcbfPqU+lxA6ooXN7y0qnbexXt7Imy9HtUqtpcPOlh24qs9y1Wrdkc47TbaUpWzWV4gX22yXz6T o0lUhnxO1+sthpzIXrRKIBj1Ms7t2rJWJl2/j+KkxzRgoiQfPTBbq3FeByqzs4Vnd0SX5zvsqJTo uc1mqcoDTbtsflXuNyYJMbWmIk+jou3P7Cj97B3lI/Grys7tXJ6sEMamJzpLy1IDkDUbwY1q0eSn nc4q9RcL8sBOfiZtudhzyp2BIz55YpVVf3n9lMj9wwVd3xr9JbfkVqZcv+Mo1nf5t2Cciu3c4da9 uoGxHcFAExgY0CEk4EalsWH86hQW8OGqURFBVovVZrQFhAjtwUEBYNhatvO/IHHBt5qQPlHdo0JC gwMMRqvQxjxtYWJ6rGxg5b37hlqD0GZx6O6rS25fus7MrGMD7+lsHQb16XghgaS5dbcy7/p9mrr7 uWvnT5/+8Kx6qcEoDYFu3pn/VuncemuukTbnTlE5xy9+7lXkDUf9/bIKFb3yakzfV64+HxN8dEbf antldF4v5Tdphza9GVPxQUTUI/9YB+aaRntNxc48jTzLUqn9VCpNVtXX3TqZI81ds1GjAjNQYuzH 68WC+0tJ7ikIxvu0a/uQny22qlXTM7KLpfIDmYcgCFoMHcpYcmjWMeP48dMHnEp+asOmmhuHk/X5 1SonvHgJghxfIyKGbkudM2f+gvng+XBY9BlaQ+920g5H9ZXDh3MTL81c9R/15Fsnbcs1JWCOdqew sCidVjg6JNEWB+jWzrTqhCDBNCkxiXNmjbUy6/p9HiaW5s3MqCiLy5j1k8GsqdUdQCGodvHiLGvh 3M/7v79fZCg7I1cIt73fXVpcpKGPzoidMWNG7PERf309eFyBRRd6wuGwmXPltEJJm+4Xq6do5bUZ B/ZfzdxdQ7+YMO+z6Cl7s+rrLbZvCdFL+5WzUL1QcMEBcT9EYK3Mun4fqe8W6MaVXDg52bpRmnjs G+M7u7OzR26oidvWfcdO5McdIcjzu46S5K7vj1xNdNrU6u/Onw+fFhh04jGRviYu5BO5cs1mINTp tJk1OTlauaO+Vnc5L1muUDgOvnpl0cD/GZ+4aOuCKckKa23Yvs2vr5uTuTBR8M5WKJ7zhwAc4vtX j1TjK9HdSi0O21C5NBTchw/HXRjx7+0bP/9wrWBb4Unx8RP6F7evN9tourrX/ncn0THPX41x2rve DhEraGPotlR7YW1ZkUqlVKFZtP5emTknuUBps++urNhZnDNL9Vp90v9sNd8xFEXOrr1TFi0YnYi8 xa0T5Vvn/ncOvvrTJycjIdGloZf6nXgsb4DBqFUum7zo/Q7DQr+Il6vNyY9lvTtpUtr+EV3+rZQf +W6aVukMPqS0z3E6zEW5ySqlIstsOZObnitHHXa9o5h4P2Bveq605GhUar7C2Gfcv+edEgh6VkrO cwvk/eerP0Wg+4dInOL7h9akjtJVpjoHMSgxBOpcPueR7W9CP7xtteSse2vL7i1btuTsMZw0K9Py Z4Ia+P5cwACN0qnLXbdOp44rl8sVdvtFY1XVGakqUUnrK8vOAJVKS22nfeWXizRganjsqE1wNkQg OpGQwqmOQPhWl7/YkDG/rO6Z5/qAkXXxYuetbjdXGe173tx9cN8AOldFXyWPfhx8JBE9EJF5IOOg MyVljuXS8X5n9aH76i9HdbaUVWiVSgVtNZZVFMWla1bb6yvLVLkapcJmqikkFr2t1BQ4ViwxCwNj BILqv+EpXK8EMALj+ZVAyuYh9zSZNzuDccacq7IErZBnzb910/5RTbXeYJa+//5wuXlPrpIij8TM mBED7h7dvl9hcERts9M2dU6cZk2kKU+brLSatBXmXE0B7KzX1xRHSSRb10ftRRXOq7viwpIEgk1/ kezneJODESTfb3KSoIi5a7KXK530CkO5XKra+kWV/Fn86UVfpivpDL3eYbdUafLiRgT3q74wQn9R rVI6nYHI88osm0kbV2GOy5Pnz7M6aoBDqgqy5pbdSrEbt9zSvfp+gGAmmrCU44UbRvL+wm37fzNS Z89e4ah9+9ChgD27ru9ZIC3JsgZ2t6gLpUMGnRUP0APvgh9ZOCvsP8kaVYbTGbLdWmfTqDSbgTcG HKId9ktOs23T4eTstNPJohldfpLnSHIDEcH3XeOncbwQxUgZ3y9EfzxQe3SVMX9ffo+TOerIXvlZ j6kSV1vCUgVHNQUK5+khp48fPz506Efz5galDl9p2HFHTYRA9eYKQlqWJ9UohddAPxKEPVHQ6ccA wbgN/Vkimt+xYyTB8zv2lOtLbidNnnzrU6k8WZV1SRDyYembI3AiSl0kTV7z8YY3ek+tHbbnJh0l CpYrHRbd+myLOWrD3Gcnb708cZhw3OZeH3IQDRhwK36JhpS0ynt78P+9djgvNzYm5siRlYzta8Kv /quafH7E5jhlzC4lPfvO7dkLUs51WiYQ0Mc6HXHbKWseikGPxikvQzH8sEMxzDUUv5uYsmyJ+kJ6 shwVCSWLZonODe6n+/sznc/Wg0dtGTE647UAAdw3MsxtHdrcJYFVBAR7se5huyTM1SWBdaZ1Q4u2 al7T3dVTYRldQkJCpncMzOi9uv/KsKHoaIHunxFbG0xjYCUEE7n/5wKUPI78OigJFSEyDyIJpmCJ jLlBSsCd0YUjdRED1RgKo/GPMmARhhCoTMY6GiyGYQlEyJD4AWJIglIQjmDxoQykJJPBMjg+yJUL IkiQNoK13Z/Jh+MQwk4cLYZJCY4iZHwAkxTUNkTJ4ge5C24qDfHMF+mimxAIB+YkoBIKAXcFjyJA wWhDwaxcwWLcZTnCvgI7V0OxLXKxZALtoAAM1EegGJGgMpTA4mfGs883G8NpAPtajcooCI1Hmcti CCqLH8xgXQTID3vUnZfqfcAyRlqoGEYkGEbi8TJxAiwhKRmGxvfkbKpoJgGKEzDl7WpscVENIBoJ 1IeKGZZMRiISSAacKCkV+A3hyoXAJMlykZmLmHKhxhK6c1rhNl3KcjjO+vNiTnd2PSCIq5EZAxMa LUxASAnZYCUrF7smw9wlDPKo1EYdEJMNQmFwsDcwl0Qx0IIwSEmCYQw4AburuL1sZiZTwQQBDnuk aK5siIrvzCSBCaba2G3ANs7Tr5ubzG0dtwu7t9zOypIf4XEFSgKBVoJbNBg7DbfHuy/ils2qTHZS 7uHCU1BjCQ1JYVKGg6SMN+Mwxj2ABHFayHJ3Vv16OhLckKSFYlYPjnA5OeihEhhvcnLPzt4k+BFX M8MkuDJLu9uDOQ1jWdNVjEKoBEFQNqFJyTwITWbXjWQiEEE9sNtMaLp2Wyc0KaytEJoU1jYJTQpv +4QmhfsLoUnh/kRoUoT/EZoU4a+EJkW0B0KTIv2b0KTIdkJoUmQ7IjQpsl0RmhTVDgnNhhVX7YrQ pKh2RWgiENTuCE2gub0QmkBqeyE0EQhul4Qm0N3uCE2guf0RmkB0OyM0EQhpb4QmkNwuCU2guz0R mgiEtjdCE0huL4QmkNp+CE0EkrULQhPo9G9CEwj0b0ITCPRjQhOBsHZAaAKV/ktoAnH+RmgiEO5n hCZQ1PYJTSCiDRKaCES0CUIT2OnDhCawzrcIzd9CXyLgVv7b2MvBYsRFCrLhoiAv/FigmGhMgYkp CenaYnNbzcQTi2PqxOSBMC5DPEitSMYiUBDKcFRg0uVi0Ng8mhcCjJvVZCVgo2dDxDAmgRCI/H+A am5aq2friJYH5tgCOPXE6jyIR6Z0mCB/uUI44NYW0CU32AfEuKBLgpQgTTjaAwAojuOcolgXDfOA 99y2ekBwHhCl64oshvKP5H5bVA0XbthYzzCGNQpGMJTloSykNoy7fC/QLTuJu7iHI1obexQBLJKA gzgEYzi7sHjO/NzwsRfHYzWVCx10hdd0AeKujd/IhSMEAZpbJpM1DEz/X8LRLZldw+zWfLj6xR9s XHbBbsO8u3gL92nZTd1F9GNQUQJC4UYWlcQor4VxDcsehGvL1soIR1AcE5FkE+jp2gVegjTFOGVv NyVrjnf6G1oWhXAJ/hvvOu4G425m1tgZKQajNJO4WapLLDtq60KPgK4yEvLc9gjuygCssIj5Bxy6 ZaBYmSs6HBP3NXNe+PwhnmFgcRf2yiqvIQws4g4D62pSmYhpZKaZwQbpUtawysLr2V/Vs0DlUx7V jxHAhxCRDJe4uATQAPGUOOmVxr4rwZhKBUU8sNFgi7ezv7aXkwwO72kODPo56OwI0RSPtpfLX2Uk wqDsKAPQg+YEA4BMAioTYiLLJmASBEVwl7+gEgRm7sddGlB3EnSCYDFQRzGhZ3sz/oQj4DmDiu/D 2o5jbbvTxIuYMhCSolwQPbN2AYPj+zLXkBE4QoARGZPgMAz6n3sLTF9gREKgMLPkAgN2Uwhz/2k6 3U+cAGyBSBIBYwkK5g5gosP0XtAHIODnjJtKwDQHcw1BBPBXilVMqJiZdsCuYaQpmfuYO11/cJak SApnnR0gxhCMgdjZXZ3dhxd6dm8w6Hhst+zqv8+w/ud2fsL1vrNZPrPLYthJGfnArhtpJ12xLziQ dhRvfCAgmChdlJdndBh52AcCxAvSvveJBTExMX1UCovx8uGcuJKAa/aAE3O7rh11PaBr6ajHv5kg WDmik571OEU22ydrG8g9sJRoi8g9cF2orSP3QAPqH8g9UIL7D3IP1FD+htwjBBM6yh+Re6CM79/X fQC5BypJv0bS3UKZSFB+LLT55SXhiv/UPth7IJZoR+w9QuCtkJ1+yt4D0a1gnX7J3gPJrVCdfsje EzjvQOfmlzJNxeuV8hjn+IyDKptpD5jxleVpklX0rdR5IZlgHKLNcVM33zqjlY+YNuPdb6Hnnxrz V4OzMH1m9YURb6TL6UMIiqz5Tquis9dq5YpVNkuRNi5ZlUU77p/cGZ0uX62gb5WdAa2sDPp8pa0e 3ladMClIAHcZFc8pmOCd5/S5xQYEwTfQ6TMEPkHwzXD6JoFPkPyvofE5Gp0geV9E42M0OkHyvpbG 12h0guJ7TY0PSuZ7OY1vAvgExfuSGl8C8AmK97mXrwH4JMT3EuaUf31enGG7E/q0pLxI40TWCKXR 0aEn1YPjdhm61WVflytnzNil3KQ7oHQ4du7Zsfu9HbEfbl6/pcs4hcWY+55OOnRoYXGeUgEeJbRn DoNHCOGpnJlHltffPSZ47k5O3izlSvOdMluFXKUI3qiia4PHBQhmHpZ9xi2V94XLvrLWgIT4XrDs Q2sNSBj257UGzT/bkbDMj0l1EibaAalOIpD/kuokgvobqU4iuJ+R6iRCtVlS3S0CRdqsiOZ30yTK dzi4lMiJQ659vRqNJrRVO9VHV66IiYlZk5bYxzRFeTVGkeU0Gb/a8MZ7+78ZNNV+5a2x4PZToc5V yZUBsVowf3Y4zoAB5B9Hry3dMUA4fbCoKwciQKJkG1wxQMrgNrFigJTJfGvFAH+Bk1EZzMQF/QNQ qgcZ2SgxISExBiX2Rto3piVRNlPdeAEG3HOXFcYFGLcW/bgFM+vmXN2nB7nDt4ZxE/2/GMWYla8n 13n3ZVkIsPu09/C5XFSvSyxKssv3WKrAWnPAhQr/irDSDeGSoSZuv+GSKEkRnO3LrimOVv0dIs62 DJMMecZIbnIvj6UUrIC5XLXgzWhvx/uJG+rfI87yA6snGKq/ZQNgFOFeTIBSrPDZD3oFgbNO/yJb 7lGYl7DL3tFvThSdJZOzpbwsbmhek/OLRDlrJc6DvZc1kHhcnTPut6eyGCYrijd6ZmP7tGhMl1vj wFtIjhUp7LTsEYujN7Glucn9lgxpRjiKuD5210SQunbdyCiKEsQDu80EqWuXkyBtus2iCLP2uO1w jyy7sbZkd9NkDNjN92SMd14TRZiVwf7AawIlvK8I/uN4TaCG8DdeE0WYhcP+yGsCZaj/85pAJe7P IZKBPr4jk/gGpgmmJ4j/Y5rNswuS77dQvsctAtG8v4/yMW4RRahW+B//4RZZevmO5OYTepHmGRHF O/jjU5wmyqwlbmecJtDMexhdH+E0gVS+UR+f5DSBbt6ZH1+LlIyiMP/Ita+xqUA078y1b7GpQDHv 4XN9DNREUYR36tqHgEUgl3fe2seARSCZ9zC6PgIsoijK9xI3XwEWXW+I241Uvhe0+Q6bCcTy/UEo n4gDjaIy3n/C+lPDJAOBmP/Cp0Ad30v/fQA+RVHXun8/g0+bp0JYax+8bIOkJlBEtHnIEdzsoDYO OQIJaNuDHIHVeFuAHIGdlG9BjuywyChKID4UFrmFaZgPmfbbIjbLIBkTvpGNfcoZmgrCZDjVAvpr 4rG8hjxtJZYzJ+I10EX9UThJsumsRtoSQTHPCLuuAkiPcKkhICnScIFQMdEYyxRcHmu4PCs7m9Tj jojcCg0qowgvYam5aVau4r0Sd+za9MLceaHNWo0XDaMu0Q8GbUQx10eOmpkzZpcFmeFgrG2562bO cFf4k1aiFoLiCF+OWggmKVDbiFoILEXbJAWHMR+saeMUHMZ8k6YtU3DNs3IMay0mXtvkxjDX12b8 hxtjCeP9SzN/EhCH4Xw/+foCEIfhvC8Q/lOBOAzne4mwjwBxGMH71/P+fCDOLZbvT+j5UtxCIJfv n/99kP/DiFYgC//k/zCS78AqvsXDYa1xrX6Kh2GtYa3+hYdhreGsfoyHYa1hrX6Kh2H8o60+pxn/ A+hWn0PicP7xVh9D4nDeKVefQ+Jw3gFXn4xdiOL8Q66+hALi/OOtvoYC4q3xrf4FjeGtca3+Bo3h CO+fbfAJaAxH+P5iw58MjeEMwOq30BjOMKt+D43hDK7qZ9AYWx3ld+qa3+fg/H+Q6g+Oxwgktfbu rS1SfjiDnrZRyq/5pTvOkKVtDpHDGWS0DSByOAOC+iwih+NQ2+fQUEoCkX9O+EGMKZ75Vq33mH6e 307Hf2UsQm5kjhVBzVtcuV/BgXnESYQb4hN6jeX2QBg6Jh+rgnpyRif8dZHuWruER7w9kJ8kYVLm LUSc+wP3vxIfDGiM1wb6JfNRbFe8NrfmzkwWmGA+Kt9QDu76FjJHnDp3iaw83ki7Xwp61yISYYNx rGCEbv/txFgFMZil2wC2p/MY9o7tPj3duKVrk6RkkIwz9CI7F8siVtzBoUwKGUkiJMwdRdL9xfkY 4MtgZksgLMaS7WTe4nSypAEbyQYb2ZZ5idj3S7yk20kfjHfZ0PvBnBWTsSoRYqqgoRtwE7E9XLUB Q0yHddfGTLG3IKeNx8HdBvEI58l4Egakws1ezvJTT8aVFdMSRWVMvEnWF6v/D/cLPnJlbmRzdHJl YW0KZW5kb2JqCjc4IDAgb2JqCjgzNjAKZW5kb2JqCjg0IDAgb2JqCjw8L0xlbmd0aCA4NSAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1YW49VNRSOCKIbA5LgFS9b1LA3ydm2q/f4 JNGY+CaZxAfxaRSImYMZTOb3+63VdrdnmIMjExNN5ATOR7vafuva1XM8qkXTqPhTweF2+PJBGB// MRwPlNLIf7eCvFFqPBrIObWDee5oeDL8OD4djrGDV5jbWKc0/mMjviCxpOTz3nH85vfhB3zUQm5s /zz47vTIs8fgEBfDf4Rbjw+34/0DbKfNSHY8eDSoUY8bPlLHuCg7Gp0WQ+PBdvhp+mLe6CUkH+P0 6kyLsSa46eE0a7WYpPz08OkMhl4lO12aN4rJMr4xb2jRNlrLEhhXLE1uujJrv6hgaXptBtW831Xs 7Fx0ad921xg7FaI20+UOvznrRWtDcQoz+bC4EH8++H5wC8Vx4xN75uAXaPHKTHrxSvudXZtC/Z5t 9MqcqZ7iCs2s1VZ3869j3mqlnZ/emLNloOuu5r0O13Z0MEm0YOYbfC/ejhtjF+cz+etzAiNlQ392 z7gbvjGHJTrm0dR4i12oA5zbMb4JyyVnsHqPyS/vodvLwJk6O7PbbpqdGMBMd2dCcgTXh867TMb4 oFPP6xIoKBhKv8BmO+HHNtbReqZQNHrOTCa6Pg5vdY6ZGv6rILgD0aCMhuh7s3W0eBPYU98eIBGR 6I7SqJN2nOqMjYP7Sn73WGTWZH+J5DTkOayJ0hJzbipWLlPrvXK7KXf7LD07F3S+74KoC+FOtjm7 bXV3FgfDZJ0j3mcuhoPQdHHR5tvYO2JxCgbuuTmTk/HVuKt5xYzVvGC1mrfH2dQXNq+lsHix72Tm g99OM+ETK5MUzHp6jzOrizMxLrv5Y9grGgcfNfTViq7MRJLUZ9iNWRW21sc1FHtcmF+cbfBL8Jnw w3lfPp8dWX2W78o/n3FZuXx3ys243blWcWnu4iomKt6DjnrkDy7IOlO/ce2WG/jZr8Oje+Uku97j DF9wylkXucWwXORqz0V+3NWG7W7NCPBLj/+vHy9XP6pJt7s1Q8zb43++ftTTt7s1Q07v8b+jflSG 292awQx7/F+sHy9B0qsFOpOR5kxIvlxLOc41Sc5uKS/WSNZm+Gth5LhteYFxwCUfuyeN/36LqXxl pxXq5flaS7vYRPBiL9HMdIq+QV+cvF7dqfK7wY7cpLG+AFHUy6+ivbPneiEhCtJOHLiAhwqNFsq6 VNJLzxuLUuqc71jBhVEFfowF1mNkr2pPcvGYEMKoneFKYDCdsUEjDOR1RcmMh0PDDZ3kUbiAL52C E6/DXo50GOUEQYdDww2dDJZUkT06hU2RseRN3rcgnHY4NNzQSR4VbkcVe15nip5ygqDDoeGGTvi+ ha10shFvaaS1DdYDOM4F3xmNghgtqIxZfc+boIIwdiKTzeI0b06CrWNsM+a1JssbHrdZxvC49YKJ x7GBYGLsq6lFNcEs4zMHzSpLIQTmc0NxDe8ZfcVOe1dlnA5U1wLHuqfT0XZuVZkDy6eVmyNVuCXG edyIE7O84XFtq+7FubAJOBBlGagEnDmwK4myvOe1cgVZYp4rjlXG8hdwdrdZ9wTmPXUUDLMWDsCh crO4pStnYF91QdioqmMLPcGebZI5eLaJ2Bb3LMuHzCGwfbyvGDYPVQZY1bXwi617wnexC1eqHIqv hVuJAWCqsSG6lJgRHUsstWAXvMaeJYklo6oNS6wCU41hJIKr+ElNEMtXL3DKWFbIeNZAy7ir3gDO OxGfYLOFjEQuVc8AF2+IlsVLpkY0sFgl72kl0lP1WInuYomQ1zo+N5oOl3HXioHjiHarPLxkOlzG TfOk0zUbwCGx56lyA/aVc8kM0QXYrqVLp1LGOKJzg045S0yLXFXsplokasmq4hkZzxkcqGEfqgyw jJesinVPYFPPQualyiFnoU55LWdG5oxMjTXSpRpBx7wn89cx72N0qxCsiw55LfFan7kR6+5txTC5 rfJrNZIKV9ZKbATVqqD3lU/JBvDUNU5KBXVZR4kNl2VyZqRWfW2pyrpVU8k2m8+V7LRZL6nogh+V Zxnu7PV9dq4+zRD/YNlf0TamxY8GE7VTuy49lTGKplv8iLBelabNJHSy8pNVHf4AyCpvCH0xOh50 SoQmUiv09IkfLliEm0mbiPasrrk/G3IQsH1XIr+Ajc+D3JXsmz2v2vG01i6gnx9D6PqSD6VBxoXK Pb7YCa+kt9GsLChtoH193jh0oKh//I4yuH25374pv/eGSGwB69FspTB9xHp78ohovCEa/qTDTQbd G/agmOR14UEsOT19ymegy6eA/g/m0mDaIZhb04JQj+jsHXgn4uawTt+ZN+CiYmQfGrwNyAXuBz1a cLz/+EfURaH68k+cGlZAP9m2uQqkUG9jJ9bGmtxnmI0pJt/Nfj474t8zdfeC+BOnAZyTZW5kc3Ry ZWFtCmVuZG9iago4NSAwIG9iagoxNzg5CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL0ltYWdlQyAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL1hPYmplY3QgMTUg MCBSCi9Gb250IDE2IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjE3IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQyAvSW1hZ2VJIC9UZXh0XQovQ29sb3JT cGFjZSAyNSAwIFIKL0V4dEdTdGF0ZSAyNiAwIFIKL1hPYmplY3QgMjcgMCBSCi9Gb250IDI4IDAg Ugo+PgovQ29udGVudHMgMTggMCBSCj4+CmVuZG9iagoyOSAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0NvbG9yU3BhY2UgMzQgMCBSCi9F eHRHU3RhdGUgMzUgMCBSCi9YT2JqZWN0IDM2IDAgUgovRm9udCAzNyAwIFIKPj4KL0NvbnRlbnRz IDMwIDAgUgo+PgplbmRvYmoKMzggMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv SW1hZ2VDIC9JbWFnZUkgL1RleHRdCi9Db2xvclNwYWNlIDQxIDAgUgovRXh0R1N0YXRlIDQyIDAg UgovWE9iamVjdCA0MyAwIFIKL0ZvbnQgNDQgMCBSCj4+Ci9Db250ZW50cyAzOSAwIFIKPj4KZW5k b2JqCjQ1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUg OTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQyAvSW1hZ2VJ IC9UZXh0XQovQ29sb3JTcGFjZSA0OCAwIFIKL0V4dEdTdGF0ZSA0OSAwIFIKL1hPYmplY3QgNTAg MCBSCi9Gb250IDUxIDAgUgo+PgovQ29udGVudHMgNDYgMCBSCj4+CmVuZG9iago1MiAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDkwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL1RleHRdCi9FeHRHU3RhdGUgNTcg MCBSCi9YT2JqZWN0IDU4IDAgUgovRm9udCA1OSAwIFIKPj4KL0NvbnRlbnRzIDUzIDAgUgo+Pgpl bmRvYmoKNjAgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0 ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VDIC9JbWFn ZUkgL1RleHRdCi9Db2xvclNwYWNlIDY1IDAgUgovRXh0R1N0YXRlIDY2IDAgUgovWE9iamVjdCA2 NyAwIFIKL0ZvbnQgNjggMCBSCj4+Ci9Db250ZW50cyA2MSAwIFIKPj4KZW5kb2JqCjY5IDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgOTAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQyAvSW1hZ2VJIC9UZXh0XQovQ29s b3JTcGFjZSA3MiAwIFIKL0V4dEdTdGF0ZSA3MyAwIFIKL1hPYmplY3QgNzQgMCBSCi9Gb250IDc1 IDAgUgo+PgovQ29udGVudHMgNzAgMCBSCj4+CmVuZG9iago3NiAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0NvbG9yU3BhY2UgNzkgMCBS Ci9FeHRHU3RhdGUgODAgMCBSCi9YT2JqZWN0IDgxIDAgUgovRm9udCA4MiAwIFIKPj4KL0NvbnRl bnRzIDc3IDAgUgo+PgplbmRvYmoKODMgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NjEyIDc5Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvSW1hZ2VDIC9UZXh0XQovRXh0R1N0YXRlIDg2IDAgUgovWE9iamVjdCA4NyAwIFIKL0ZvbnQg ODggMCBSCj4+Ci9Db250ZW50cyA4NCAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1Bh Z2VzIC9LaWRzIFsKNCAwIFIKMTcgMCBSCjI5IDAgUgozOCAwIFIKNDUgMCBSCjUyIDAgUgo2MCAw IFIKNjkgMCBSCjc2IDAgUgo4MyAwIFIKXSAvQ291bnQgMTAKL1JvdGF0ZSA5MD4+CmVuZG9iagox IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8 L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjE1IDAgb2JqCjw8L1I5CjkgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjkgMCBvYmoKPDwvU3Vi dHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDk2MgovSGVpZ2h0IDcyMgov Qml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRENURGVjb2RlL0xlbmd0aCAxNjI4NDc+PnN0cmVh bQr/2P/uAA5BZG9iZQBkAAAAAAH/2wBDAAICAgICAgICAgIDAwIDBAYEBAMDBAcFBgQGCQgJCQkI CAgKCw4MCgoNCggIDBAMDQ4PDxAPCQwREhEPEg4PDw//2wBDAQMDAwQDBAcEBAcPCggKDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw//wAARCALSA8IDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD8zZpI BE8NqjhXIZmcjIwOnHWv1WU4pWpn55CEpP8AedAt44ljmuJFD7CAqMcAsfXHbFOnGP8AEnugqylL 3IuyY/yre6kxERAxX7shyCfQHt+NVyU675o6Ec9WhBc2sSu5kH7l3YhCQFJyB9Kwl7suXsdNOEZJ VF1Jre1kuA3ksPNXBCZwW+nuK1p0pTd47mNauqfuPYsiVJm234cuBtEq9V+o71tzxn7lYx9i6S5q I2d42EKRqRFEuASMFieST+NZ1Jwl7sNjSjCUVOU1qyytjcRjzUZRKgEmxWw6gjIOK0jhpx/eIxli qc3yWFBhuxK88gS66q2MK+B0OOh96bnGqm5q0xKNSk4+zj7pVYySYLOTgcZJNc753ZvY6rKPupGq 0dnbiOCWByHiDfaBkHJ5BUZwQOld/wC6pqMJR36nnqVWcueMtugBPse63vIA8UqhkdCMj0IPT2Ir JNUVyzV0zS7rPmjLWPQo4NYSdmdaSkrGlFG0UEV/ZzYuITiRDwVyeCB3BHBreMFFe2hv1OScnOXs p7dC/aRxtOmoxXEEUDb/AD4n6RjHKgdSCDxitacYtqaZnNyt7OS0MFsEuUGE3HAPpnj9K5Z2U+Y6 lea16GtYo1ndFJpPInlgJhmwGAJGQc9s9Mjoa2glB2e/Qxm41N9kRyGS8tWeVlW8slAw2Q8iA989 SDjj0qpJ1dZ7oUXGnt1K9xf/AOlG8sfMtpHUbwhwA3fGOxIzis5VOVpouMW1aQkNheXo+0CRN0rk L5rgNM+CSFHJJ+tFudKTBT5PdiMSaK3isr63U/abeQrPEQTuBOQTxgAjcDSWvvLfqNvmunt0JWtm SLUUcN9haMXEUqZ2KTyuc9SRkVTjFarYabaTe5ky6jIxs5UzHcwIE8wH7wHAOPUDg1HPf5GsafUj mk1C+D3kglljQY8zHCj0AGAMegqWr/McUkyOGJfM0953H2e4YjI6KQcYY/ln2ojHlHJ3+Qkt4hCX cdukc9vMMiEEJt4xySecg/Wk5PRdhL8xsnmPJqVquAXImWMDJY5yAD9GpySKuyKeSOK5AuCxZrfD hjkq+MDOPTApOyQ9SKG9t0SB3DieEEKFAw+cn5j2xmlz7FOCsyibljCIDjaHL57gkYI/SobLUFcB dSDySHwYuEI6jnNSpMHFBJdySlSxUBeVCAKAfXA70OTGohHcyxszIxLHk8Bs+5BBpczE0N85iWJY 5bIY+uaHJlJD1unC+X8vAwDjkA9gaOZjsIJmAjXghDkCp5mFh7yqVKoCMnJyadxjgwdpNowSMKOn pSuAucMMHOxc/jQAisVCjpk5J65FQA3jBI6dhQWJQAA+o6dKAD196ADPvxQAUAFABQAUAKMg4HTu KAEoATn/AOvQAuc8tQAh+lACggECkgA5Hfr3qkApwRkDHrSASgAIIAbse9JobYA4PIyDTWghPp0o AcvOTjOO1BLD73QfNQIOCOvI6GgsSgB+0dM8+lBAD5hjuOlACgjA3DOOlAWAMSSaVh2Fxxn3xRYL jy2GBByCMYP8q0JWgm0AsrdxwfepGIrYGCoOOmaaAaeSSeppNFIcq5ZQeM45+tIkeQhDYXBGOCet UgF3YMbgdAB7ZFKwChcGVCcdTgdDjkU7AJkBUP8AEpOf6Uk7ASF4/wB46HJfI246Z96tu4EW/KKh HQk5+tRcdg3EqE/hByB7mi4iQzOV2EjH0Gfz60NsXLYjzxjtnOKXMxknnSbfK3nZ6VVwshmTgrng nJHvSuwsiZbiRVCDbwMBsDI/HrVc7J5UMDEI0f8ACxBP1Gf8aXMNRRaSaEGKVlczRgAAY2nHT3FV cixCjIIJgcGVmGPoMk0rj5SyLcu1mFDCMqCXwSM5JOM8cU7BcYrsRd3BA+f5c9CCT2H0FMkkicRr bxRRoZZD84kXIIJAA5/PiqQn7xE0Iea4WIjy0yxJ6AD/ADgVMo3HF8hX2+9ZGqZNBJ5U0UrZIXHT rgccZ9K1jKxElcmkNtHFKsLGR5CMMy4KDqR9SfSq0WpGspJdgmSSJY7EYLEh2AHIJHAPrgVOq90d k25E6payPJbRwh1CZE4ODkDJJz2JrSyk+Ui7iuYy8GsJNrRHQkpass2zKbmFpiCoIGXPAwMDPsKq DSd3uZzjaFo7FloZrZpLu4KiUP8AIpAYSE8kj2Gc1s1yPnZjGSrQ5LFZEi8mW4nO+RiQqZ5z1JPs M1Flyty3K5pq0IbFbY20OUOw8Zxx+dZezd3KRspqpbUtJcxhYhNBveLhTnGR2BHfBrojXWkZLY55 0Wm+R6MasbSE3lyoMO75hnBc+gqVG/76aBtRSpQeojLPeu8oChVwOoAAJwAKfLLESuEfZ4dKK3K5 EkE2DlZUP5EVleVGXMtGbOcK0Emiw90XV0ihWNpTlinVs9h6CtnWc1yxWph7CMbNvRAqR2bMZ4Q1 zgbEOCFB7t7+1KKVLWS94c3Os04v3SiysxLnuTyBgf4Vzu6bnbc6Fyq0U9ixabC0sMjbPNUqHzgK RyM+xrWjypOHcyr80bTS1XQd5EVr5UkzLJKSG8gcjBH8RqlGFD3pPUnnlXvGK0I3+1X7tIFLlR0U YCgdhUScqvvPY0io0rJPUp9PwrJtxVomy5pO8i5HDdahMzZ3EfedjgKP6CtFGpUdzLnVONh6vZ2y SL5PnXIJUMx+QDoCAOtXFQg7bilKpPWOiI72FI3ikhGIJUDKCc4PQjPsamrGK1RdGTeglvcRJG1v cRl7dmDkKcEEDt9amnKK92QVINvQdJeDeGtYVtwFKgp1IPqaJVLO0dg9kmveK2Zzzvl5/wBpqmzK tE0HEZdjEpCdgTkge5qm5X5jNXtqWoXntcP5QMUg6OuQw+tbwUqOrV0zCapVXy3sySMWTbZJC6MD uKAZDDPRT2qoezk7vQyqKvH93HWJGQ91ckgfNK3A+p4qP407LqarloUtehZNrDkrBcbp1fbsIxuO cZU1s6cI6Ql7xgq8pe9OPusc7uI/s9xbjzE4VyCrL7H1/GlKc0rVY6jhTi5e0py07FcA8uBnHJ9v rWUW1blOh/3jSeP7a/m2u83BBZ42Izkf3T3z6V1yXt2nDc4E5UFaa0C8Un7NJKircSJlwowSM4BY dATUYpWtNrUrCuXvQv7oy3S3eTbO5RCCA6jO09iR6etZ0UpXU9jSq5RXuLUuLtjK218We1G7y5Iz kKScbl9RkdK6ItKShV+EwveDnS+LsRXLxMtvBbhjHECC7ZBck5PHYegqKtRVHywNKSdNuc9GyWGB LeQxanBJHHKvEhU5jIP3gO/oRRGKp/xOop1HN81MRftGmXcUm3DjDLuGRIhH8iKFek/IE1VVupWl aN5XeOJYkJyqZyFz2BNTJqWkUVFNXg2aiQ2EFrYvdwyMl0GZrlScRYyAFUdSDyQa2ioqmlURi5Tl JqmyJkJjk0++mMUsCb7Zn4Ug/MRnGeRyOeDU6JWlstivdk9NyvPqt3dRPCUj3y7RI6J882AAAx5z +HWplNyZajFavoRCya3uYYtTR4IpcrvOMKcYBOM9CRkUuTkaTLVTm1iNXzpbc2qBRe2LGRGQkM6k jIXHXB5HtVN3SiiEvtSI764+w3M6CP8A4+IAJ4JDna5GTyD1BGfxpTfLojSFnZGPG09yY7WOTIJy FZ8KMdScnA4rFJy900dtxTbpHMqTzIYpUYxTI2UJwQDn0yMGny2Gm2iNb2RLeynjBX7O5jcdQS2c ZXPUgkGmmJRbZUndIUu7VpT5kUgMRycEdDgdASMGk3ZehaRHcahDIk/lxMsk7AvkjaMHOAAM9e9S 6i1LUfwM97mR2Vmdi6gKD3wOAKi7bL5ULKksW0uy4JwSGDbSezY6GnJMd0LiOL7SZwX8ohdqttyS cZzg8UcugWGuYk+0qHyVwUPqCef0NJrViV9BEkTZBlcnzcNx1HGBSTRTiySW4kkQmQEsku0E44Hp Q2hKLQrTun2pkyjbwMg4K5J449aNBg7/ADXXy4OB6ccik7DQ4yfK0eCECAgY78c0roYgKZTPQLk+ 5paAO+Vim3jcM4znFKwAoLjqBnoD3osUAI9MVAyQPx05AwD7UAGRgD86AHd/ZaADrjjmgAoAKACg AoAKACgAycdaACgBSSM0AJwfqKACgAXB+tABkgUABOR6CgAHTJOM0AHP4U0rgKcZ4pPQaQlAhehB B47UCFHqDigkQnJJFBYvUcdu1AC9fm9KCAPY9DQCFoLHLgAcZz1NBF7i9Djop/yKA3AEDKsM4ORT Bqwwncc4x7UikHTB7HvTTEyQ4yU2gccEdzTYhMnYD/dOPzqQHgDJfIKnOcnnJFUgI8/LtPY5BqLj sOMjkbS3FXcLDRkk45xzUiJFjBAJYAngDHWqSAQJ8khPVccfXilYdxVAMbn+JSPyPWiwidWQFIyq 7CuScc5I9frVjuQnHlE/x7v0xU6CLJddzxceUF4GOc49cZ61TaJsQnb5K4xvLH64wMUroLE7eUfO jVVCopIcdWxjv3p6CsyIxfJAQcvITx+OBSHYe8SBXMbsWQ4YMMDrjIP1osK5EVZQrMuAwyPcdKLF XHkzRqYyXRT1U5AP4U2TYbvbyvJ/g3bvxxikmOxeLwMy3DOCQm0RFTwQMD2IzVEbEABjti4b/WnG PUDkn86fMPl5hYyqQTOy/O+EUkcY6kg+tSkK9iYWsfyxNIwunUMq7cjkZAOOc4qnEXMUqz12NE1y uRbtpj9oaSSQCRlIEr5IViOCcVpGSepnKLSXmOeP7NF5aybriUkMEIYbQeBx3JFVJOEb9WF1N27C ujEQ2EUeJt2ZM4yWPbPoBRZP3RJv40RS2wji82OVJUB2sV4Knnsex7Gk6dlzspVtOSS1IF2l08zJ QEZA6474qOZzV3sW07WsW2DXkssxAS3iHToAB0Xjua0+P3zJONJKPcljnkn+0s+1LMJgoeQvYAD1 zVKXtG77GU6ai0ovcyufeuda6XOte7ZW2Jow9y8MDOQi5A4zgdScDrV0/etC+hjUShepYe585xbw Erb7htDdATxljWrlNy5IaIiKUY889Wxt46vKNshcIoUuQBuI71NeTm+WOpeH9xe8rXK8crxOskfD jOCecZGM1ip+zfNF6ms4xnGzWjJkh3RvcTyDbk7QTkyEdvXHqa25HL95JmLm0/ZQRat55LmR0MQ+ y7CpRRgRjqDk98itqVSVVO60OepSjQd1L3jJx+Nceiu2d9mtbli3igYNJcSYjUgBF6sfQVpThCqv fZjUlOm1yIcZZpVW1hDCLJwi8k5OeSOtWqkpP2cFoS6cYXqzepDNbTQY81MDOM5BGR1HFZSpTpvU 0hXjUWhYt1Wa2uLcACYkMnON/Yj3rSjLmRNW8XEDbQ2sqfanWTg7oozyCOgJ6VLpqDvPUFVlP3ae hWuJRO4ZY1jQcKi9ABUVJxq6QNKcXS1lqV9pqEorSRq5cy900JGsUiMcMDSSEf62QkYPqAK2fIla O5hq37w7+1NQ/vp/3wKPayF7KI5UZyFUEsewrNXmuSJU21Hnloi6Re2sZjbcsL9jyD9OorqSqUo8 stTkvRrvmjuglaCRQ0cHlydwDlT9Aaicqc17q1Kgp021KV0JDvQiRFPyEHPYfWnByi1KKKq8jhyv dlwJb3D4iKwPjOxycE/7J7fjXRGFOrPn2Zy80qVO0tUJdlXeJRJ5hSMBpM5yeuPw6VGIkpOy1ZeF g4pynp5E8MF5ag3CIAAAGHDcEZ+ZfQ1pTp1aK57GVStSrS9m3oG2B4zOknlXCtu8sAgHnjaR0x70 XptXvZh+9UlFq8H1I4wHkXzWJBIBbvgnnrWSTnJc5vUvCPuo1LpoxM9pc20cMZYNHKo5jXpnj7wI FdMve/dyjaPc4aaa/eU5a9UQTNNAj2DOkkIIZSMMBnnKnqMjrUVP3ceXdGtNRlLnWjCzYW9xbXUq N5Cv94KDyB2zwSM5xU0vi59kOqotOD1ZopFNJcR2Fy8s9lcOximjXO5j/GuRzjuK35XJ8s3eLMeb kjzpWZkzzTbFtHk3xQMQvfbzzg9cH0rGcr/u29EdEbR99LVhAyWtzG15bGSLHzxNwSpHUe+DkGph o9dgbvsWyI7UeRciR9LuFMsD8ZQngMADjIxgjNa2+zLYjf3luUNQuo55II7cyNDBGIkMnLMASScd hk8DtUVHzKy2RdOKi+Z7kdsTbpDqakOsEoEkfQqD0Off5hn1pqPJ73Yb973R7RPIl1bs0v2CRHuo XOCFPYsRnqAQfejlUtQtbVGJdai9wbeU/LcRoEMqkgvjoT7gcVjKbloaqPQjjtvPRHa5RZpmIijb JMhHUk9sngZ6mjl7l9CFbpIVtrmNMbMw3AIJBzkAn6jt7U07DRXuFa1t2EjEmOUGB85DjqcLnp0O aHFIqLbKD6nMtzPPbt5RlbLKORn1GffkVHO0aeyuVpEuBJH54ZDKwG9/Unqalxl1K93oIskUCyed GkjrIEYPnKjnJABpxUVuJqXQjeQok6KOIpA6k9cHgf0okkmUldCzFtt2zEiNyJFIGAxPOPqM0SsE Y6kJuIWeUFiEkQfNjcVIAz161F9GXyjXul3S7V+R0Cc8HjHOPwpN6jUSMTkJsXgZ3Z75xikmU4Ej 3JcYwFydxKj7x9TQ2LkHpctudsBt/LBhkE+uKXMLlQvnMd5Jzv6/nUybK5US+eWUjAycAnuQKbkH KSLKCTu6EAcdgKnmDlJA656cBcD3PrQmBIp4RgeAOvvTbAep4QEcdagB2d231oAOvSgBQcc9aAHg g0ALQAUAFABQAUAFABQAhANAC5PegABHOO9ACAYoAXg9PyoAM9qACgAPIx37UAKM8g9KAEoAMcZ/ OgABxz1oAQ/pQA4dM4zQSxfcUCD3FABwT/M0FCrx15BFBI5TjKnjPSgBx6AA5xQA3HGaCh3yqFyM g96CRMEgrnpzQAAr8p3YI6+/pQAm7ltpwD2oAFG48Y+p4oAcF+YKT17inYByttU4OGz+lFgHYy5w MB16H3FUAg3FEI5IYgADn1oAUkbphnqDj3Oc0ANUgK4PUgYP41AEodP3bk4ZBjGOv41SEyPcPLKd yQc/hihgicyoS0mW3su3bjgcYzmmIiLjZGuPusSfxx/hQOxO7J++cMpMnQAcrzmrJEXyy9sAcAAb j75NQArLJHFJ5mQWcfKe4GTmhASjcs8eQG8pAcDjoM9/rVgRszNbqHZixb5S2cAAc4P1qbAOMKGV 1VsRxrkt16YyR9SaLAMljCbSj742GQ2COhwRg+lDiCIueBzgdqEDLSSLI1rE4xEhwffJyT+NO9wt YmKSwGed18tySqoR6g5wfYd6ZDRGVxFDAsZ89zlsjBweFA9u9Cj1G2E1ssauyTq5RtrqBgjnGR6i hxS0BMhhkMMiSqAShzg9M1N7FP3ixGCLae4G5pi4XeM/IDySSPXpWi94hrlFZGijFmI/9IkILHIJ x2A9OvNJ6e6txLX3nsiCeNYZDGsm8rwxHTPcD1xSlDl91blxnze89iSCSJVljmQmNwOV6qR0Iog+ W5E4879B7L9pZYbWPbGi5JbAzjklj/Kqkue1gvyg+bkpBax7Yo1JycAnA5ZjQ17Rcq2En7N80tyu yTWsqH7kgwysOQQehB71mv3ctC7+1iTNcSzgwwwqjStlhH1c+n0rR1nP3YmXsVF80tkIW+xiSNNr XB4Mo5CjHRff1q7ql7sN2KzqpSnsVpIJolDSRsqnGCfcZrCcJU020awqRqNWepLG1u8KwzkrsfId Rk4PUH+lb03CUEpu1jKpzxk5wWjGu5kb7PbKUidhhM53HoCTUSd5ctPYFHTnnuMnhSHaglDyD720 cKfQHvUzhybGtKcp6vYgRN8iIONzBc/U1nGPNaxVSXJFyW5anmED+XbI0WzKlifmb1zW9Soo2sjG nTdSDdZj3R4bMpPtzI4ZEJ+Yepx6EU7qMLSIjadW9NaGdgdjXKny/CdractUWxZ/ufPmmSMEZUHk t+ArojS0vVZzurbSmriyXMIiMNvaqqkcuw3MT7HtUqpTTtFXRUKdS95PUo1k3G9lsbra73L0ENus Xn3YkKE4RU/iI65PatuSMFeWxzynObtErM6lmKRYTPAz0FY8zNrI2LMrHOCxC5BUMeikjGTXTQko yvLdHFiYTnS5UWFjurdi0TF0TnK/OmD7e9bvnjLujFypTh72jYXaKJjwASoLBRgKSMkAVFdQUrJG mFqXpe8tiWGO9t1NxEjBMc8AjHXlfSnShVoR51sZ1Z0K/uS3EJtpY23oyXPJymNrZPQr2xTbhKF5 fEOMZxn/AHSJVIOTjjB//XWNNSjqzeaUjVdGuJzPZu7ysCzxnAK4xwBnkegrul++anSep5sZKinT rLRdRL5PmhdkRJnQM6RjABPTI7EipxNp2utS8NJxTV7roMt1g+ZbpXCuPkkTqpHfHcetRShCGk0X WnVlrS3Rb2vaRqt3bLPayqDG5PpyArDpjutW+amuWSvHoZWdSTlF8r6jVSXU7qR2KIMF3fosSAen oBtApW9tK+yHaOHik9WTHdZRmISpc6bcAMxUcjnrg8q4wRzTceSPLuhXjUlzJWYyS5msTJbWN8Xs 3ywIHIyMEEEcHHBxRzunZJ6DUfaXdRDLe0tDDFNe3RiWVzHHtXdjA5ZvYEgcc0QpQkuaT1ZUpuL5 IoJD56/Y76ZUngj/ANHmYYEq9QCepBH3TRJq3Kwi3fmW3Uw3uZfKEHmN5IJYITwCepA9TWV5S0ex oopaouW0k1oNQgBMGpFVMZK5LDglVPOCQQRjrVxVny9RSTlr0K0t5H5keqvHG6yu0U9sBtAJHJX6 jnPY0t1zM0UdomE13My/ZYppPs7NxEW4OTxnt3rJNr3TTltqEiRWkqTSSx3MCP5cyR5+UkcgE9fY +oq7Je8VFWVipIxZGsZJghiIkgZyAGDYzlu2Rg0r3GlqUru8AmulgK+TMAHCj5SRgkrnpz0qZM1j EoR4kEjSS+XGgGWwSeegAqE2yrLoRviMTITm4icEMOQy+v8AKm0i1dizO7rdMcrE4EyleRkngZ9e optvqCSKrXURd8oWjkQbhnBBGCSCc9xUOSRfLLoQSXLyyOy8b8KVHPA6D36VnK5cY6CRq8igq46l VBJ5PfFVZtEtWYqAkxFnwrkg+2O340ktSmSBomaMquFbIK5JwR0p20QLQYj/ALp8jLDBB9O1QhtM sSSsVlUjhSMDj5QR0oYrMkMjKZWX5TuAyD09qd0hcrHM3+t+TGWA+nXildMfKyVnJDDGAGAHt7Um 0LlY8FQWIGRuwAaNAsx4xzg5G7H1qbFEmMd89vxpEjwxBx+GKRRIG9fTAFBI8eg6mgB+cj+VABQA 4HtQA6gAoAKACgBPrigBaADB9KADPrQAUAFABj0oAKAE+brQAvX2oAT5ulACjGc0AAPcUAHB9qAC gB3T8aBDqCQoKExjr0NBIeoPagBOvPpQWPXBzmgB33T/ALJFBAhHUHgjoaAEJywIPTvQA0DLY9aC hxAwSDnHWgkdn5iAOG7UAJk7QfTgD9adwHblDMDyp9PzouAhbkFeNvSkAgZwflJBPpQAYYnGDu9K AFUEnAPQE/lQBIqB8ZbBJwBjqapCY3b8rN6EDFDBEjRgAjd84G4jHGPrTC40IW8vHJfoPxxQMcyb fmDBhnBxng/jQQASQtsCkv6UAIwYHa+QfQ0N2AespDlm+bIwwPcUJgSiVDJDlcQochevfJoTAdGr SxTMikyEjIXsOSePrVgSDKzorHesC5OOOnJ/U0myUQxKJZHeRiFALMe/Hp9TQkDHR28si7lAOc4B IBbHXA74oSKciLcSV3EkDoCf0pN2ElcuxM08tzMVLTbSyKvY9Mj6D0q0mtSWhjb4oRDgbpsMeuQB 0B/nSs1oGwrwq8pjtgCqKNzk4BI6nJ6DJo5bi5uUZm4tJHXJR8YI9Qf0IovylJ8w5JUCzyyfPcuc KT2zyW+vpRGfL7z3JlHm91bEyl7JcKg+1SAMrHBKAnpg9zTSt7z3Bu/urZEd8irOcKqvtBdVOQrH qBRON7BCRAskipJGpwrYyPXHSpjK10Vy83yLcqNHttLdZC7KDJwcyE8jA9BWkrxioxIhaTcmRz4f yLaEvKUBGeuSeSFHoKVS02uXcmm3FvnKys8TbkJVwCCRweeDWcHyu6NpLmVmWFRLeFJznz3OUyOF APJOeDW0Vye89zBtzfItkKC/2e4kmlB83gK3JYg9fbFXzNwak9yHFKaUVsZ5HYda4tHayO3mteN9 C0JWaNLW3hwWxuIGS5+vYV0qUpLlijmcEvfkxRHbRArcMxm3bSicbADySe9NxjFWluZ81WTvDYr3 EJhlePOQOQw7g8g/lWU6fsZXZvSqe0p3LDXjlXKxIJm4aTGSRjHAPTNa/WXUjrEz+rJSu3oiKO23 bnuZfKVcA7sljkZGBUxpub94HVVN/u0VWUBjsyV9SMH8qxdlO0TpvJq5LDA0zEGRUUcl3PAFXCDq at2Mp1PZ+6TrJa25cLF57g4V3+7jHXH1rVTpQ0tcz5as1e9iO6ijXyJYhiOVAQP7pHB/WorQinzR 2NaM29HuPglhaE2twzKhcOHUZxxgjHvRCcZq0tiakKlN3huSZ0ocbJz78c0/3JFqxdhW3JInZlJ+ 66jIH1FVTjD4ZMivOaadNfIsxwzohntJgVGc7W2kDpkqfWuhU3Fc0HcwnUjzqNRWKeCx3MM56571 y+85HXaGyZrSxyXMoltZQ7yAAxL8pUAdCD1Fd04Oo1KDu30PPp8tGLhUW3X1C6DFIJJUVLh87gq7 SQDgEj1orWcYykgoStKSXwoSBLqIG5jhLRrwxZdwIPqPSopRqU/3ltC69SlP91fUkxbSI80b+RcK SRFyQR2weoP1qvclFyi7PsZqVSFoSXMmRRbTNG02Sm4FsnkjPNZxcY1VKRpNSUGka91NKkvl3YWa xd96mHBwp4AU9voa65SUp2lqjjpKCXPHSRRuo3t5pbQSOYlYMFbjqAQSOgODzXPUTjUt0Oin7/vr cs20ctrCNQSOOe35jmibnaCcYYdQD1BFXC8VdbE1LTfK9yxB9lgguZ1vUNtNCVe1I+cvnCrg+hOQ 1WlFLmRnzSk7NGCCMh2VjGMbsDtnkZ6DNY2tqdF9NDSkeGAC3kmebQ5nDCRV+aNsZxz0IB5HcVpb l/wsn4v8Rm6hcxNDZ2sM7T+QpHmlcbsnIVQRnA9+5qZ628io6GcI0kguD5hW7jIYQsMb0PXb7g9v Ss4x3NOZED3yyQBpbh1vLfb5Eg7qD90kc5HUE/Snz21Y/Z8xSlvLrU5EiZ0Cruc8BEXPJZvep5nU 0ZpGHKVGQxl7Y83RxJbyxnIcYzgH0I5HuKLWLtf9Ss9zDIJrx5o90qMJIiMHeehUD1IzmhmkYmJL cSSbQxLBFwO+ADn8qxuzZRS1FYQmNEJfzpELI+cgnPC4H0x9aauOyWhC9xvxLKdsU42Pt7MMYJH1 waLg48vwMrS3AjKCN1YhCjMo4bOf85qWy0n2K6sZAVMm2NeSWJwPw9ahRctdy5JpW3YhCxhjK3zI 4BGeCD3FNWfxFaSjZI7PQ/BHjfxRcCHw74S1O/mU71+z2zAbMZzkgDAxnOcUSq20SI0VryNI/D28 0448UeItF0LZIW8i4uxPPjPO2KHcc+xIrinmNOKaidKoOTu9jW0Xwp4U1N5Y9GXxJ4ie3bdLcWlr FY2kQ/6ayytlMj1FcU80fRGywzZuvJ8KfDeP7R0iDULyNiRYWN/LfYYnkPcAQoOeCFyR71jLH1pb M09hBblm7nsLHGrXPhXQvBWnzIDBZtA+pajcKBwUinZljB6h3UeoJFQsRV7g6aOU0+9i1m+l0fwr odpYW86O13qupqt1PHAATJI7MNkYAJ4Rc9ADkiqdeq+ovZo53X9Ys557a20iExaHpwK24dB5k/IL SyHHLOVzjoBgDpzSq1bbk8iNfXLkaF4114R2dtPapcPG9pJGPLkQgZUYGV4PBGCD0pqrV7i9mie5 lFhZx3ulxQ6h4WuXJNtexBns5SMmNmUB1OOQwIBHOOCKqNWr3JcER2K6PdSM+lxQLcSY3aZqpJVi Dn91MCMH0Bx+Na+2qEuCLs83h24la3v9FOl3yt88bM6rn/eGcD/gOKpV2S4FKbR7GDExmnS2J/1p AliJPT94ucfiBWyrszdMrf2QxXfb3Cyp1LR4cfkMn9K2jUuZyjbcpGxnAJQK+Dj5Gzj6jtVbi57E JSSM4dCPqKLWFdAG/GkOyY4Y/GgVrC9/c0DF3Ee9AC7hQA6gAoAKACgAOf8A9dAB1H0oAKAEyKAF oAKACgAoAKADpQAHA+bNABQAdRx1oAX+E0AJQBJQA32NABntQAuBQAc5z2NBA/oCM0FjTz70ALxx nqehoIE6jjqO9AC+rHoRz9aAG56D06GgB2WbqCRQAZOAex4zQA4qvIHBHqetADgdrfL3H9KAFBOY 275xk/X/AOvQA1Bh8Zx1H6U0wHKCwTGTg9u3TmqADhlk5/iGB69aAJGGdz5O0gAHPU8cUACHmHDY x+nJoIEKsIwrZBLdCPbrQA9ic3BODnCk9O/b8qAHA/vIgy5CJkjrngnmgBI9gC5QMznGCSMDjkUC aGlOJHB+VDjPrk//AFqBi+XKiiTBUeoPIz60AIrkBwDwwwfpnNADwyiJ1x85I5PYD/69NAWvuTZI 3R26jjp/+vJNUQQYUxg9ZnfoOwHt7k0WGOeGSEB9w4OMo3KkdjQ0KLCKYxs8h3GQqQrE8gnjP5UX CUSYI4jihh3F5/mYdAcHgZPpjJqmribHMi3DYQ7IYUALtyeP8SeBU2C5UoSsDdy61xbtum8om4KY wxyoPTcMnPTtV36E8txV8y1VlKZupQME8lQfb1NLm5fULa26DJbKSNGYspKYDqpyUz0zScOUpS6j RdTiPygwxt2ZwM4JzgHrinzN7C5eUlfNnuhhkDTMAHZR9055AP8AOndLbcVrjXsXRXzIplRQzxDk qD79DjvQ6SfvMaq8uiRHHctGixtGsiKdyh/4Tjt7UlVa0YnR5tYseY2YrdXhPluegIDPx2HpWkY8 y9pNkykor2cOhBLmUtIkIWMcYQHA+p9ayklU95LQ0i/Zx5W9R1qQHkUSGN3Qqr5xg9efr0q6LduX qZ142fN0ARR2xR5ysrkE+UD0PbcR/Km4xou9R3YlKVZWgrIgkEsm+cxkITjKjAHtWc+aa5ma03Th 7vUbDM0Db1VS2MAsM498etTTnKnqh1aftfdb0JjFNMVmncqjtjzZM/XjvWnJKpdz0uZc8Ipwgtgk gh8t5beRmCEA7hjOe49s05U4cj5AjWlGSU+oy3cbZ4ZDhJAMHHAIPBqaNpc0ZirxacZx1FK2lu6n d55Gcrjaue2D1pyVOm0tyl7SpF/ZIZpPtD7sKoAwEQYAFZ1J83Q0hFQ1TuQrHlgCVHOCT0HvWcU2 W6l90X/s+n/8/wA3/fBro9lS/nOd1qn8hsMttEBE0JdygO/cQQSM49MV0yVOGlvmcUHUr+/GXyGv bxCMTQSM6ggMGXBUnpz0NRKkn78ZXNI1pSqezqRsNj2o6u6B1HVTnBH1HSlT0qXlsjWr8Fk7FxY7 aVmMEvkHgqJWyCe+GHT2zW0Ywm7wdjk5p0o8slcrEsxJZiT6k5/WsW5Tlvc3iuSOxq7XuRC1lMfN 2CM26kqQAOcZ4IPWuuXNPl9m/kcOkOb2kdO4l5GQltJLCsVw+7cigrkA4BK9ieaVeCcYytqaYWfN OUb3SGW+IfnubRpLaQbd3KnI5yG7EUU3yK817oSkqukHZotKZbOHz7O6RreQgNE2CUI5AKnuOxFO /s1zw1RDjGq/e0/UbZRi7uZnnR5mCPL5aZzKw5xx78mppRVR872KqNQ0W5IjK8jXumqsM0Ch3tpG DA4znaD1A7g81d+Z8yI+DR9TJndbidmgt1j3niKPJGfQZyefSsn78ro3VqceV6mgt7Mun26WLqyx q63Fr5ZOc8l2BzkYxz2NaR022Mm11My9lNmGhtnkFndRrJ5UwGRknGc9xjhhjipl7ui2ZrDVa7lG 0l+yyw3U2Y4ZFdUn27gjYxnHqD/jSS2KIJ5roq81wZEv7MIUl28OhOBlu55yCeopt2v5Fxjc5y6u TNJLJsVdxyQgwBnrgc45rnl7+qN1GxELhIY1nj+cEFJ4mGcAnAP0Pb3qlJbIvluVLiVIIVVJ0dxI GheMncBjnPpzjj1oky4oymkaVzLIflZ8O/ueTWXMbWHPMqO7wRbHiJDjO4FTx36+9U2kNK+hW8+G F9py6oQ6OhwfXB9BU85XI3qUS7yuQOrEkDoM1NzSKSWiOo0DwlrniaMnSNLlmiHD3bMI4oj2DMxA AOPWmotmM68aLbmz6H8M/sx6vd2i6v4s1qHStJkUAzyfuUcY4Ks4Lucjokb57GqjGae2p59TNUve S07nqFpB8Hvg7Y3GrWXh231u7SMIb/XIsIzgcCFMmUMSOCHT3WliaUYR5qzscVHMK+Kqeyoq9zvf C3jPSfin4fF1b6nfaJZW6eZew2hhXTdNY8lZCPK8sAY5O8n3rkwuJpwpOpJ3ZtjMJWlWVOCsjwy3 8O/Bo+KL+88PahofjLWLufZDZalcvo9hDIMkuGcAXG7GcEon1zXiTl7SvzQjofRUlOnh0qkveRw3 iPwP8W/FuqTaRaaZFPpVtKVi0zRr22ay0+PcBkiIhFUFgC5H1Nc9VJPRHZQcpL3tSje+HNS+HjPa 6B4bv9S8TRfLLr5sXlgtW6EWibSCQePOYZ7oB1MxbfU0srnlF7a61NczXWpWuoPezNukluopC8hJ 6kkZJJ9a1sQ7nWa88PhHTP8AhDoZVXW7lUm1qUEAoSA0dqO+EBBf1c4/hppIRwLtEY3AdTkHuPSt NLE6nZ+Nyr+Jr+XcP3qxS8nn5o1PP51ULMl3MzRtWTTJ5VmUT6dcgRXVqWwJUzkYPZgeQ3Y/jVWS E7j9W0tdPuUWCb7RYXCCa1uQOJoz3IGcEHgjsatWI1NG0urq5hjstS0+5vbNeEdEJlgB/uNg8ex4 Pt1q1YTRc/sHXdPZLnS1ne0kGRMilMDOCJFOMHsQfwzT5kKxJFDaJIJdU+y2s4yd9tKMsefvRrnH PcY+lXF9yZLsW7ma0toluUd76IjGVUbV9mc5YEehFbqdtjF07medSs7iMRrH9nzjIYbgf+Bdf0xT U7kunYry2KFfNCjYejxkEfpxWi1I1RSe0dfuNkeh4oGpFdlZThhg9qChPy9qBi0AFADs44x0oAdQ AUAFABQAcc+tABQAUAFACcAUAGRQAvHegBOAKAFoATtxQAvfPegAoAKAHf71ADqACgBB06fhQAH9 KAEXvQA/jqOh60AHXgnoeKAGk8nHenZiuhBz1pDHcZ5PBHWmAoJAG3saLEBjhhnpyKQC5HJz1GMe 9MADHjPbigALE44AA7ChoBv55zSAcFY5x/hQAbTzx060AO2MBnA+nerAADkDHJ6YquST6C5kuopD A4bOfeptYe4quykkYOeoIzn86AF8xssTyW4/CglolV0whbOUBwuMg5560CBQCsaZ5Z/m9uwoAeWI E8hGdx256e/T6CgBjgZRFX5goB9STzQA4ROXaNBvK8ZFNADSykeW7sVHGD7f4UXFYsI3mys4BBjT 5EXrkDA/LrVJiGkMsaxHAeUhix6gds+nrQ2LYXyfMkcW65jXChmIGT26+vahIOYQTTxK0O5lAJG0 9RnggemaLgkSKqyiGCAYc8u54568+wFUncmROkqyLLHtRbZExg8nPYg8HJJouBQAIAJBAPQ9jUO4 XLsO6RbqcqZJwAc55GerY6nFaRV/eE9dOgMpgSSF0Ju5cDrnaDzjA7k0X5ly9Rbu/QryxNA/luRv A5CnOD6H3pOLj8JalzFq2B8m5aNFecAAA8kKeCVHc04x5ttyZPlDAtFlSRc3TDAAOQgI5zjv7VV7 aMm7nqkV5YZIiFkXaxGQDjOD6jtWUly6s0VpaIljQTFpbl28qIAEAZJHQAdhVxSlrJ6EybjG0VqS 28s8ki4KrbRD5lPyrtPB3epNa05Nvlt7qMZxjGPN9pmewUs2OFycfTtXO0m7xOpNpe8SxrbrGzyl mc5Cxrx+JNaQ9ltJ3ZlJVU7xVl3HMLq8GB/qkHThVXA/KnaU/dRL9nT957lR4mjYo64YHBBrFwlB 8rN1Vc4to0LmB7hvOWZRbhQQXbhTj7o+ldNWEp2a2Rx0qihFXWpVaWCOExQ7zI4G9ycD1wB9ahyi qVo7s2UZzn7SWy2Klc2q0R0qyXMWzHarHkyM8xAOEHC+xJra0ErSd2cylUnJ2VkEtyZF8tIo0i64 VefxPWidS/QcKDpu7dymVHPJrnaTOjmb6BtHqadn2Hc6pvtMKpDcQ5iUjAdew54I7V6XvQ9yS0PI h7KT54OzYkkyNGIoogkZO4jJbJxjqe1KpVTj7OnGxdChUjJ1JyuWrbzlty9qoMocl+AflxwMHqOu a2w/P7O8Vqc2I5Pafvdug0JFNDMxh2TRjeXBwCCcYxj34xQoKcJNqzQ+ZwqRipXT6EcEcrODDEXZ fmIC7hgeorGEG3otjWrUjFMtgWdw75H2SQDjALIT3z3H4VtZVNPhOe1WNmveTKrGR3LSMXJPJYk5 A9zzWXP0tobxSS1djclkuJnaWyfz7cgNJbBThAuAAynqPcV1uTkk46rscUYQjHllo11M/UYYoLkr GgTcis0YO7yyRkrk+lYVqet0tDooVFKGurC3EDKgWaS31NXBjfOEbPQE8FSPXpVRs1a9mTKT6q6J Lm7ktfNhmsEi1EoY2n6EgkZO3pkjcNw6g0N30asyYrre/kUY7eNIYbhr9be5YF4lwccHglh0JIOO KSVt2av00ILq8ZXkunaS11hG+YLHtEgI5OB0Pr2NEpacz0YlF301RmRub2a5mumklaOMybV+8+AA BnsB3x2qY2nqzbl5NUVHniRWdBLJpMjAPEWGY3xwfqM8HvQ116FxRhTXk8gS1+0O1uGARXPA5wDj n1rJy9pp0N0hkri1eY2zu7x5jmilX7y4wTj0z689Kfw6IuK5tWY8s4t5HFtNuidcc9wezD1FZydt UbRjfcpRbPMQSrlSCVDHAYjOAT9aUY3dzS1/hGtMhG5Rst5cK6jnaw5BA6471TtHUpQstys10zL5 QVWfATcM5IHas3NP3EtSowfxN2Oz8L/DnxH4odXhtvslhkZvLtSEIB52gAliPYY9SKqNCbdrHNiM fRw6vOR9U+EvgHoVrYnxBrTxjSLY7pdb11vKtoyAARHEoJcjGQih3z3xWs1ClrN69jxJ5pWxPuYd cq7nXah8VfhX4AtR/wAIwkGo6mgyl/eQK7qcdYbUEpF9XJP06Vz1MZRguactOxFPAYitKyV5d7mT onjDUfHltP4j1e3vhcvKyRG9LSPOgA2lMgA5ORheAeK6sJjI1aUpSXLFHFmGX1qFSNJPmbOb8UfD HUpdQi1DxbBqF+N5a08Lm5jha1LHJN5KuTEo4/dIDLjglDXg4unisfK9PWJ9Lga2Ey2ny1H+8W5g fF+w1fXbjwr4c0TSbTTPDiypaQWliBa2nnvjAEQJLYIJ3sCeeuaMVgJUqcYU46l5fmyrznUqz93p oa/gb4G61IZ7MeMJLaxIFxePbwhIbcAAGRnfcSAOAAoJOABnitaeWVKULynZvoctXOaNafKo3S69 jX1b4b6HHaHwn4Xubyw8NiTdf6mxU32vSDkGVsYjiUlsIAfcE80LJpP4iv8AWOlThywjdny9dXus aLqV9Zabr2rRQ28zxIUupYiQDgFgrAZwPSvLq0PZVORH0GHr+2oqT0Z6H4Q8VeKdL0/VPGepa/ez 2lg32axtrqUyLdXrqSoYNnKRqfMPbOwfxVi1ze6zeMmo3OUPxD8cybvP8SXE27LP58cblyTklmKE nJ5OTWkacPhZPPpcY3jjxPICsl3bup6o9pCQfqNtV7PQSmdJ4u8V6xHqNg6LZFZ9NsrjLWcZJLwI xySPfpThTJlI5c+L9fPC3ECKOix20Sgfhtq1AnmN7RvE+uauk+g3OqMlxcYaxm2ovlyjpGMDhX6f XbVcgcxydxrGus7pPqd2JFYhl8wqQQeQcY71USW2RW2o3lvK0nnGZXG14pyZElXuGBJyKuxLbLU1 jb3MMl7pSkRr801oTueD3B7x+/Ud6tJCM+CWe2bzoHdCRjI6Eeh7EfWtLPoS211NKOCPUF3LD5E3 99QfKY+46g/Tj2ohBsTlF7jViuNPlEVzE8RY5EgOAQe+eQRVaxZm2uhqP5bn94m1v7yf1H+Fb2sY cxXktjtLAB4+5HOPqOoplJlB7ZTyox7dqgFNoqvG6DkceooNFaQygdrBn1ouAo/U0AA6igB3vQAt ABQAUAFABx/9egBOAKAFoAT2PWgBaACgAoAKACgAoAKADjn1oAPegBw9+9AC/j+FACfT8aAF4AoA Wno7cwNtXaPf9E8O+GtS0fTb06TAZJYVZzg43AAEdfUGvscLg8PVw8ZuO58zXxValUaPG/Etimma 7qVpEmyFJSUXsFIDAD2AOK+Zx9FUK0oHuYao6tBSJ/CmmJquu2NrNGHtwTJID0KqCcH2JwPxqsvo e3rRiLHV/ZUrnsOq+ENEk06/Wy0uKO6MbGJlByHAJGOfXivp8Tl1D2UlGGp4lHGVueLbPnrnPua+ MkldpH0qTWre56l8PPD2napb6le6nbLNErpFGGHQgEseo9RX0GS4OlWUp1V6Hj5nialJpU2M+IWm 6PpCafbafZRw3MjOzlM52gAAcnuT+lTnOHo4fljTW+48uqVaqbqHmhI+YY4HSvAWux6t0gJG4H6U tegWTHHOGHof8aduYNFsKc/vOe/NLSO4b7itn5zu4Kjn16VorXQnsfTfhiCJtA0VmiiLCxQklB/d /wDr195gaUXhoto+VxdRqq9TwbxUNniTUwFAVZSQBwMYr5DMEo4mVj6HBO9GJgIxUIB36+4rhvod D2G4BX3Jx+FC8it9xzKm0lSeDgk9/pR7v2iXyrdibG3FQpLDqBzTd47AuRjmkdmG8kkHoaS13G1b YcrgyGR/c49+1NWjsxe6+g8BiscanJc5P4e//fVKKd9g06sHKSedK3dgFH17n8BT3W1hfO4GOSMb wQCCOh5UnpmiMX3FddUCTMpkY7jIy4DE8jPU/lxTfvNA7R0LBQ7Yoxu8rb5jdgfUj6DineTSJfLH UbJtkEtwTtBbaqjv9foKWk9w20Q1C8DqzR5BByrjhgeDTS7CkuXVE67bjbGiiKBAWZjyevUnjPYA U7LZ6ILNCllnzJO2yFAFRF6/RR+pNPla80TeJHIpt5f3UueNyuuQSD0ofNDRbDi1bUfHKqI0nzNd s3ynn5e+fck07rdbiSimSrHBEyx3MbvOzAMoP3AR2x1PNCfIrSFKUpPQrurQSuiuQyMV3DIPFJKS 1Q2tPeJUeOJBKCXuy2R6Jg9T6k003styXK++xItujkfaLjbcSPjBGSp9W9OafIt29RuTj8K0IUkk t3kQqDkFHRuh/wD1VMZSplNRqepK4muV8xUVLaPA44CjP6mqvKpuQ1Gn6kM/kZVYFbA6ux5Y+uO1 TO8X7hUFOS3C1iEk6KwBBzhScBiBkDPvToRUpXmFeU4wtAUrNcMSQI4icHqqLgf/AFqtKU53eiMk 4wjZu7Q25dXkG1g2AFL4xuwMZwaiu4yfumlKMkrWsRRRCRiDIqKBks3QUqcedb2KqSS1tclDwQFv LjErE8SSDgcelUnGnflVzPlnW+J2RSZSSW4GT0HA/CueUk2dK00iPihllbZEhY98dqqFOUtiZzVP cnFsi7vtEyxlTgoPmJx9K1VFWvUdmYyrSvaEboqsBk4OR69Kxd07LY6IptXW4fKONo/KgLs6xIb1 HHkv5hUbgI23BQeOh9a9VQqw+DU8d1KMo++rXK0jvK5dwAx6hQFH5CuabcpWludEFZLk2LCQwMiG O4KTHgq4wMnjgjtW8VorSszmnUnzN1I3iupNdNeLthuZcqBxghgw7cjrjtmnV9rH93ImjGhL95Dc ltWBt5IRcCCUOJNxyN+BwAw6Yqqcl7Pli7MzrwUpc0ldFqSGb7HO99AA64aOY4LOSeRuBwR/KtJw 5ad5rVGcbe3iqb90is4L0t9otbcSbM8MAwYAcjaevB5xWVJP7KN6sqbdp6XGtJaMJJ4me0u1OVjT JUj0Vs5B+tDcXd7NkKL5kt0Q2MyRXsE85BUNks+WAOOCw6nB5xShrrIucW4+4aJjuLuUQagpnj2O Ir2LAAwMklsYIHTB5FbcrmjPmUY2WhzBlDOhmdigIGc7iAP7ufQdBWKS2Zt5lqZkijW3nk8/Sg5M dzCuGQkZwcj3yVP4VabWj2Fy316mReym+uIYrUu4jiCCSU4LAAksxPQDt7VDaqaI2i+TRlJ9yvHb YEGoISUnD4WUHJAz0yegPT1ocdOVaM0Ub6vVGRdXvmK0EVqsUjsPMCZ+YjgBR2Geahy6dDaMTPkA t963AR43ym+NsmNh/nn1qOXk1WxqkVproQFxMpe6UFRKrcOpGAT64HT9aHK2jLUL6oyQhGxpgyQt xvx0yOD9Kz5erNt9EQNIQHhmJAXJXjo3+Bqb8q5DS1tDf0Dwz4k8YTiHR9PLxK+JblhsiRv9psYz jsMn2qlFzXIjGvWoYNc1WR9WfDv4IWNnd2UUWnPrvieQnywY96KcZOyM5AAHV3yAM5x1rrp4aFFc 9Z3Z8vjM7r4m9PDxtHufRseneGPCCg3q2/iDxIvC2kTk2FmRwBI64MxHopCD1NXFyxDtH3YnlTlC ir1HzP8AIwNW1XVvEF0l3q9408iDZEgASOBR0WONQFQD0AH510Qowp/CrnHWr1K270OTufg5onxA 1CXVtXjkigtIgt1qc96bW2s4gTgyNgjJPQckngA15WYYOlVfPU0PoMqzOvTj7KnG67nknxD8ceHf B2qQ+H/hRf3l1bxRol94lu7szXVwBw0NqxGLeMqMZXLkdWAyK+cxcXzpc10uh9hgeaVGU5R1ZHc+ PtG8SeKdPSz03Wr63tYd1rZWchhN3ckhsygHlQFPU+pPFenUxqquEIrRHkQyuWGhOdR/F+B7b8O9 G8WeMiR4m0SzsL6O6aeFpNpSzhTGZpDyF2kn5gcnjHJAr0qdZyp81eNux4VenRw84ww1S99z0jW7 yzNrF4f0BHj0CBgWlcbX1CUcGWQdgOiJ0A9811UqTbU5HmVqsF7kHoeeazDriW6poNnbSXj5Hm3k hVIQO5UAlvpxVV3NvQrCxo+0UqsrJHyl438FeIrLxJY215dxanr2tvuSO1jKlpGbaFA56npivmMb hqlOfOz73KsZSrQao7I1PiL4d1jSo9L0O00q4HhrQIjbi8Efy3NyTm4mIGSAX+UEjGEGOMVzUqFW 3O0d8sbBz9nc8o8qhRs7s0upPlF8uq5dBKSOu8XRbj4YmK536LZLu9dsYTH4bcfhSgrMJSOT2e9W ok3FVCpBUkEc7gcEEdCDVOIXOn1uP+07W18SRj95OfIvgoxtuAMhjjgBwM/UNUxByRy+ytbEtont 5Z7WaO4t5NkyHIYfqD6g9waFBohvmOpN/JeWjTWVvFviT/SLLHRe7p6j1Hb6VqqiRjKgpa3M611W ONFhlgIQcApzgdhg1rTqJGU6Ensb0UiyQgECa1bnY3T6j0NapKRipOjoyOWzBUy25LxDllP3k+o7 j3FDG2Z+1kO5SQfUUWuClYQiOTiQbH/vqOD9R/hSL5lIgkt3TBIBU9GHIP40D1WxRktlbJXhvXtS sNVCk8bofmGB2PrUtGqdxo56UDF9CfyoAQEjvQA8dBQAtABQAUAFABQAUAFABQAUAFABQAEZ+tAA R2oAKAF6/UUAJQAoHPP50AOyfy9aAE/ioAF70AOpWdhrVHvXw4uhceHzAz/Pazsm0/3Thh+pNfaZ HXdSgoN7HzOZxlCrocZ8TLPydYtLsDCXEOP+BKSDz9GWvJ4gpWqRqdzvyqrem4mj8L9O3Pqeptxg CBCR1J+Y/wAlrpyKja9V9DHNqm0EevBcYJ656V9LJ8yaueJeS1vsfMniSwOm65qlmqkJHKWQN2Vv mX9CK+Ax9H2NWUT6zCTVanFtntvgSy+yeGrTPD3DNOfTk4H6Ba+syik6dCLPn8xnzV2r7HmXxEvB c+I5YVbKW0SRYHTJG4/zrwM7qupXfkezl0FGjzdzhc54xyeM14yi6jsjuvCK1O00rwHrupxpPIiW sDDINwSGI7EKAT+eK9jDZNXxCu9Dhr5jCk7I6A/C2/IJh1WEyYzhoyg/PJ/lXZLh+bV+fU545vBb xOL1nwxrOhEm+tv3GcCeI7kJPvwR+IFeTicBXw+lRXR20sVTr7SsYOG2j+7/AJ7VxxT5kdLeh9O+ FVkOgaJszv8AsyEY69K/QMv/AN1ifI4xfvmeC+L9/wDwk+tFid3nEc9egr47M3/tUj6TA/wImDEs sjpFFEXlY4RVBJJPYAda4oQctEdEmlG7O+074da7dpFJdGG0jzu2ysWfn1UAgdO5r2aGSV63xaHm 1cypU9jYk+FV0NiwazA7FskyRMgx25yf5V1S4elFfH+Bis5i38JxeseGNb0Rd97bEwSPtFxEdyE9 hkdOvQgV5GKy2vhnd7HdSxlKvsc+wBMrkdSAP/11xyemp135R8FrPcywwW0Ty3Ep2pFGpZmPsB1q qdGVWVqSuZ1KkKau3Y9Fsfhp4ikjAvporJWAby2y7YPfA4GfrXtUchrVleTseZWzSFPZXLsvwu1U +UlrfW0xUEhHzGXPJwDyOenJFazyGoleDuZ083g3+8Vjz/UtK1PR53stUs5ILxzkrIOcA9QRkEE9 wa8WvhamGf7xWPTpVoV1em7lHy1dmMZCxAhQWPU//XrFLmso9TSXux5mejt8LfEqboWvbAAEjb5s hGf++MV7zyKta6PLea0lLkZQ0PwLrWvCW6jjit9PtwAJbjOJCDj5QBkgnqeB71jh8oxGIfuaIuvm NOijqLv4UasbSNYtVhnv5m3LbvGV4I4IPPUnjiu2rw5OK0ndnLTzmnfU8wvNG1Sw1OTRri0ddRVt nkp8xY9tpGQQexFeHUwVWnP2co6npxr05x54y0PTrH4VaheWkV3qOrWlmqp8tooMkoYY4KjA5JyS CePevaocP1JQ5pSt5Hm185hGXJFGfrvwz1zT7STUlmS8z0ghUrIFAHzBSDlccDBJrPE5FXpxckXQ zWnVdjzWNjBNHIVOVIbByM4rwkuSXK9z1bRqK6LsYBmRLATTXsr7UAUlueAABkknNa04upLlWrM5 VPZq8zvrH4Xa3cwRPcyR2kzjLRy5Z0z2KgdfUE8dK9ihkVequaWiPLq5vTouxrQfCe+SeMxa3bBz lQ00ZUISMAkjPAPXiur/AFdmo+7LUxlntO9pR0OF1vw5qnhW5VdYt1ed8srowkjbPIO4Egnvjr61 5GIwVbBN86uejh8VRxKumc7LDLEVeUANJyFJGeeckds1wNSW52xlGW24sQabbC0u2JAWOQSFHUnA qo8z2JlyrfcsQyDzFhtrcSKWySy5LgHoc8Crg1J6GNSL7lSQCOdxExAVjg9DweKyldTOiMXKn75K VuLqMvJKBEnGXOBn0AHU1fvVVzPSxjeFF8ttyKU24QJEjF+MyMf0C1MuSEfc3NIc85Xb0K1Yayex 0O9r2LAtZAiPJhI2IG5j2PfHWuhUm0uZ2OV1ot2juRzJbggQu7epYYB+lTUUFsaUpTf8RWGx+cT5 URbMhxgHGamHO9hVFCGrdyX7Kkb7bidUPXCfMevTjvWip8mk3YhVpz1giOeFY9joxaJwSpIweDjB rOrRUNe5rTrOo+WWhBWdje6Oriit9+5LvaqkHDgqSByenevVpKHPpLRHhVZVZQScNxUWO4vOTsjk kOe2AT/hSio1K1lsE5VKFG99iUvZs4SSB4gMglDkn0O0/rWr5JySasY2qxi5KV7kc0BgleI9V6dj g8jI+lYVIuE3BO9zelO8FJot7o0SOG7s2UjBEq5Vtp9jwfauiMVHScTD3qk3OnL5EE4iRgsE5liA yCylSM9Rg1jPV+7sbQd99GWleKSCG1nd4LiJjtZhhMMcktjkH39K0Wq5epg5Wk5dB2onEFtHPcRT XSFgXiwQEGAoJA57kZqqmkbb2FSbbb2GrDe2MErvbwywyKN8LEMyEjKkgEEHHOR+NCjaPvFOpfSO 5mXM8Uceyxupvs8oy8L5XaRxg44I96mUtPdKir/ENtZmW0cWscElz5h8yKVdzSIRgBV9ASc4OacN h2uZF3KYII3tpJEhuVIeJvUHBwO4z0PWpauaxRlRyGOOS6ULLHgxyw7irYPQ8dv8mpjFI2tcz7ia FbR4xcJLuKmMbcMh75PYcYx3qZ+ptGJkL1y7GOTAaMsOGIPT8e1Za9TVK5FJPGDcO/ySuCrwFeM9 iPTB5o9dzVRMnG8gM2xWzhscEj3rNp3942tZaj1JmcArljhGiySWIGBgDJJJ6Ad6tqyuNKy0Z9F6 D+zzrll4f0/xz4/223hWaNXU28ysIc9EunGfKYdNhwfQ1lCVO/712aODHY2dKHJh1zN9T6X+Hfh7 R/EeiPq2l3tvp3gPTZPsr6mYikTOACY7ZMAyyc8hRjPLEV3QxdL4MOrs+VxOGxMpe1xjtc0NU+KP he2lbwZ4Ru4dPtJZTBcq0q/a7sqCzNczcBUAGfLU7AcA5PNYyxFGm06sve7djSODr1YWpQtT79zh rTxppGqXdzp/hq3udZu4E3SG0TbFECcDdK2AMnjjJrf+0KMlyQ1bMZZRXpRVTEe7BnrHg3w3f3mj DxJ46hj0fSUdl2Wkone9cHiO3yAGP95zwvc9qz+tTu046kywVD2ilGd4+h8z/GP423ni+1v/AAJp /hqHSfDFpPiK0WUSFSpHzsQCHkOOXJz2AA4rw8Vi3VbpvV9z63LMscXGqnp2Pm1YPavPUE1eR9Bd ctup9L/s7+HfEd7rN0LLQ2ksdQjEcV0yENK4cARxnuCWy2eMJ1yK9LLuaLc2tF1Pns/mqlJUoP3u x9naz9l0mzfwtosyyqGB1LUIicXkoP3FP/PFDwPU5Ppj26UPbe/L5HxlaaoP2cfmcj9iOPu1087W hydbDTZH0z7VL1Rpta5uaDo9pYSah4xezhOoWEP2W0naMFxNKCFAbGcACRyM4+T3rirxVaUYHpYW vUoU5ThI8u8Yaxa+EdIOqXen3V3EXEXlW67jkgnLE8AcHJNXWnGELNXKwVKrXq/HZnxBqL295qF7 d2lottazSs8dupyIlJyAPp7V4MrTk7Kx95RThBc2/cpeXS5LRKUrPU7DxREW07wTL0L6Uq49Ns0q frtzURXvSByjZM4/yfateUSqRDy6fIEZXOj8NPC1zPot42LDVUFuzHpFLnMT/g+PwJqJx1Gmc/Pa TWs81rcxFLiFzHIh6qwOCPzFWloKTIdg/u07WFzWJYJZrWeK4t5Ck0Z3K46g/wCetO1xX1NK7tYr y2bVLGMJsIF1bL/yxJ6OAf8AlmT+R49KS0CWpLo93FGHtrhlVSdyMegJ6j8eorohOxy14XOjMTxO HQlXHcV0NXORSsNa2S64jAS5/udFf6eh9qlaF35jLkgZSVZSGBwQRgg0DuRANGSBgqeqkZB+oqWr lKdhGt0ly0H3xyYj1/A96V7D5uYqrbtKSoAwOrHoB6mi/MVdxM2e0CsxgJKjse9LlNY1Cn3x3FIt O4uBSAUDj6UEh9adgJKQ7iEenFAXDAoGBANArhgUDDAoGGBQAYFABgUAGBQAYFABjvjn0oAMc5oA MCgQYFBIuPbigAoKDAx9aCQx7dKAF4z7UauIHqXwvuwl9qViW4ljWRR7qcH9Gr6PIatpul3PJzaL klI6H4m2Xm6Pa3ijLW04BP8AssCD+oWu7PKXNRUuxyZVO03HubngnTzYeG7BcYknBuGHTJY5H/ju K6sroeywt2c+Pre0qton0bW11TVPENgCCLSZVQdyMbW+vzK351rhMVHEVJw7EV6Lo0oy7nnfxL02 T+09OvYkJ+0x+VgDq6nj8wVH4V4Oc4duqpLqelldVKlJHr9jZrZ2dnaLjZDGkYI6cACvpaEfY0Ir yPIqS9pUb7nzDrF0L/VdQvAcrNO7D6EnH6ba+Cxk/a1XI+rw0OWjGJ6H8OfDcV27a3exB4on2QRs MguMEsc+mQB7/SvbyXAqf72SukeXmmKUH7OLO28TeL7Lw8IrfyjcX7AkQqwUKD0LHBxnsMV62NzB YRckVdnDh8HLEe9JnFRfFG+8w/aNKgaE4yI3ZTjjoTkZ/CvJhxBLm9+Gh3TyqCj7rPUNP1HTfEum TTQgS2so8uWGVRkEYyrDn1r3qdWjjoXtueTUhLCy1Z4D4r0E+H9XuLRSTaOolhY9Sh7E+oIIr47M MK8JWs+p9HhK/t6aa6HvvhcE+HdJxz/osQ4HsK+xwC/cJHz2Nd8Q4ngXi/P/AAkut+0pB/IV8dmS viZeZ9Fg/wCBFHrngTwxDpenrqV3DnUbhAyk/wDLFTggD0JHJ/KvpMpy9U6XtZLU8TMMc5z9ki54 h8a6T4fuGtPKe6vUUFoYm2hSQDhmIOCc9ADW2MzaGElyJamWHwNTEavY5aD4pL5pF1o5EHBJim3M AfYqAfzFefHiBuXLKGh2Tyi692Wp1WoeNvDkWlCV7gXMV0uPsiAMzZ7Mp4H4/hmu2vmmHdJp6nJT wdeElc+erl4pJpTbRGK3LlkjZtxUE8AnAzj6V8bN88nyaX6H00Pdirn0J4A8MRaVYLqkkWdVnhDA 4yYkYDhfTIOT+VfZ5Nl6oQ9rLdnzGY411ajprZE3iTx3p3h+5TTVtjeXkCkyIj7VRjyAzYJzyMgC qxubxwr5Y7k4TASxEeaWxiaT8SbO7mjh1O0+yb/uyq+9R9RgED35rmwufU6k+ScLX6m1bK5qPNE7 XXNFtPEGny2sxUyMhMNx1MTEcFT6HuO4r08XhaeMpNLr1PPw2JqYSasfNFxaSWkz286hHt2KyKTz vBwRj6/pXw0qPsq/J2Z9YqntIc3kfYZQzBS6s17cPuUdAFPcD3J/Sv0mK91PyPiJP3med+IfH8Ph S8On2Nul1cou2QI4ESgj7pwDkjuMcV4mNziGCfs4q7PUwuWyxC9pJ6G74R8Z2/imO7lWKSLXEZV8 rdkKpGNykAZzjGMcflXbl+Zxx6tszlxmBlhXfodTJbaPazPd3tpb+bY28vnX8jcxpwSVYZ4BAAGM kkjvXbUhRpv29RbHJGVWT9nGW541L8WIEu1EGjNLZKw+aSXazgHn5QCB9M187PiCMJtQjoe2snlJ Kbme06Zq0OsWUXiaNjKZyBboyZVSOoYdAABgAd6+kw9ZYmiqvc8SrTdGo6fY+bfiLYfYPEl1B83m zkXGzaQULjLA8Dktk4xxXw2cYdUsQ7dT6nLKvtKKl2O9+F+g/wBm2v8AwkcyD7dcIyW7MOYU6Flz 0JwRn06da9rIMvVNe3krtnl5vi/aS9muh1Pir4hWng66bR9Ji+2a4YwtxKflW3JAIVSRnODzx+Ir rx+c08C/ZU43kcuEy6WLj7ST06HFSfF64n1HzNQ0q3MbACV7NipLAYLANkE+vTNedDiGTnacLHc8 jThdSPU7dtC8SaDMps0vYb9dsTOOIwcglV6hweB6GvfXscfQ2ujx37XCVLJ2PmPXtBk8PazfaVq8 kguoXAC45KEBgzE9MhgcfhXwWMw31Wq6cz67C1/rNP2lMxAWsrhx8rbSQR2YH/EVyxbU12OjRqy3 JN0kqlbWLy4lXDlc5wcZLGrul8OiBRvq9SGaOGMKscu9v4iBgf8AAe5rOatrF3ZcJvZkQBbaoBJ7 Ac8n0FT7z0Kk4Xu0WPsqxsftT+UAAQgGSc+g7fjWqoxteoZTrPaGpUZRk7ScZ4z1rGV0rRZsnP7R MITKjTTTAAZA3ZJbHYCtVSmoXlIydRRdorUkSO2m/dRq4k2k72I5IGcACq5YTVkjNuvGLlJ6ENsy JKpk+4QQ3GcAjFRRnCEuSZpWjz0nGI420SBPMuFIJ5EfzED+VN005e/IUK8nCyiMmdGEccSsIkyR vwTk9elKtO/uJaDow5XzN6lfb7VhynRc6fdbFGzbsJDnBR+B6Agg9K9Nyp1ForM8ZRrJ/FdDYYw7 qplWPuHbIAI9T2qIXk7LSw6jdNXkr+RqgXw8x2jS5RPlZiFkAxz16966vfV2tbHKvYOyvZlSGb/S 47if5vnDN71jTqL2ikzepF+zcYbGnHHdPN+5uIru3U8iTkKCecq2CMd8V0JNT0d0ckpRSTatIofZ xcXc8VuQIQXYM5wAg6k/hWXsr1fd2NnUUI3luXna4RR9qjjv7GLA8xGyFBGRhhyCPQ1rb2b01Rk5 cy5nozFWI3E4it0wXbCIzD8Bk4Gayirz5TeTUY3Zallia882aWTT9QQAs7AuC44z6gkfUVo371pG KX8pl3G3UL28eFljt8mQvJwFXplsDjJ7AVm43lobxdlZlS7lAYC7wjoNsd3bDIcjGNxBAPHcc+tP ZWLiYDXX2i6ie9lLruAYuT09Cewz1rPm1N0ivNI5kklCLDdwKXDRD5JADgn0HXHHBpSN4xOfdnuJ WZFUuctsGADjkgD+lZ2uzoURZZvtJkdnJtjkkMwBiOOowPwHHNOUkXGNjEaWS4kAZ8ueAWPoOBms WmzdKxtaNo+q+JtQj0vS7Z55XADoekIAxuJxwB/9aqUZVFyrVmVWrSwtP2tRnrco8O/DORrXT0TV vGUSBJdSuE/dWhI5EanuAcZPPqR9wceJxkMKuV6z/I5qVOrmcbr3Yfmdt4an1v4eTRePfG2t6lHr WppvsfCMExSfV0YfK92uCIrU+hG+QcIADvHztapLEytfV9T3qNClhqaVj3qy+K9r8SLa20m48GSe HItEtPsz6rpcYjttLcAsY109jtODk/I6HuQc5r2sFUrUafJh1sfNZjSo1ayniXa+x4l4Y+AFz8RL 3Urnwn490jVYVcNIsiyWl6zuSSrW04Qknk/KSD2NcVKjPFSbq6eZ62JxUMJQjazufSWkeCPCn7P/ AIVsdS+JS3VrYzzuILOWB0n1icAbmbbuEUCgqC2fZclia9WlVo4OPJB69z52tSxWa1OaUfdWyPnT x/8AtBa748ttTsn0y3gt50NrA8MhCW1uDgLHGAAgxx1+uTWcswtT5Ix+Z24fJY06yq1He3Q8R0bw /q2v3q6do1hLeXrKX8uIZIUEAsT0ABIyTXnxjOc7Lc92rXVGDlLSx9IeDP2e45baO98aTzRzlif7 NtnChVHTfIMk5+bhcY9e1eph8t0vUPmsbxFH4KG59q2mlQeBtDgsrK3S316+tgipGoX+zLRhgIAP uyOvXuEPq3HdTUZvkirRX4nz1fEVYpzqP33+BzC2O0AAYA6V1t8vuxPOScleW5KLL/ZzSc0lyjSv qDWOBkrwO9Q5aWNUrq7G/EPX9B8A6FpFjrl8sBSM3csC/NLNPKAQqqOSRGEHsd1ccalnKoerHC1J xjShHY+MPFXxp17V3mttAgXTNOOV3EB5nHqScgfQD8axq4lz0SPbweU06Pvzep4pLvmlkmmcvK5L Mx6knkk1yOLerR68fdXI3oR+X7U3T90rmSlqey23w+1/xd4d+Hd3Y2x/s1bOeCe8JH7vF9cg4BIL EKQcDtilTo3kzHFYylRhExfG3gPSfBVvFBPqt1eavcDMaJAIo41BwSzEtnPYAitZUrGOHxzrfZPM fLrPksddxpiz7e4puN0NSOp8RR/2lbaX4lQZe9QwXZ9LmIAMT1+8pjf8faogtRtnJbPeraFKSbOs 8NeFG1xZbqaVo7ONgmEHLnqcE8ADvWkYXOXEYj2aMFXk0nUpmt8HynaMpIMiRMkFWHcEdaiUDooz 5lcdqWnxRLDqFjk6bck7M8mFxy0be4zx6jBrNaFtcx0+mS3N9DGZrRwAufP42vjjjvk11wlc86tD lLUtqfStGjCEhRCt5iKbi56JL/e9A3+P51L0NU7lKTSrpCwlh8oKcEykKAfqaSZTRTa3t4jkyNK4 6CPKjP1PP5CptzFqfKRyMt0CkhET5yCOFY+/v70W5SubmM2WB42ZJFIYdjVN3JehRmtVl5xh+xqW jSNSxmujRttccj9amxsLRYBMCmAtFhXJKgLiYFAwwKBXDAoGGBQAYFACbfegA2+9AC4FABgUAGPz oAMCgAwKADAoATb70ALgUALj24oAQjNABgVpdJWE9jqvBd19j8S6W5bakjmFvT5gQP1IrvyqpyYm Mjkx0eag2e+a7pY1fSL7Ts4aVAAT0BBDA/mK+0xVFYil7M+Yw9V0qtyxeTxaVpdxcbQIbSEsFPTC jgfpiivJUKLS6IKa9tVs+p4d4B1J4PEyCVyRfK8bn1Y/MD+JGPxr5PKsQ4Yv/Ee9mFJSoW7HtGta MmqjTiwGbS7jnGe4B5H45r6rEYdYizfQ8GhXdKL8x/iG6Fhoeq3XRo4WCnp8xBA/Uiljqns8M2ug 8HH2lZI+Wsehr8/esrH2Efdj6H0t4KiWLwxpKoAAYy5+pYkn9a+7ymCjhY3PlMe3LEvUt3fhnQ76 4ku7zTYpbhyCzvkk4GB37AVpVweGqzbqLV+ZnSxVeKagQf8ACG+GsZ/saD0zg/41m8vwU9bJNeZf 1zEw2NPTtF0/SxKunWiQLIQzqpOCR0PJ966qNOjQ+CyMqtapUXvnmXxUt1H9jXG3D5ljPqR8pH5c 14PEKjOVOcWerk8nCM7noXhZGXw5ohHBNsnIPtXtZd/u0WeZi/dryueE+I4hN4v1GJwdj3QVvoSA a+Rxi58wa8z6DCyccMj6UdykLbVBVFyFUYzgcDivtmnCnZdj5ltSq3fc+SZ7iS6nuLm4YvNM5dm7 kk5PWvzqvKVWq5TPsYKEIpQIuDntk/kKyeruy7KOqQ4qckd2bHvgU7X1iwV29UT2kUc15bxOP3bS KCPYkDFbUIqVZJmNaT5GfXTRvDC0seNyJuCLkHAHGMV+iv3afu9EfFrWolLqz5CmmlnlnmmYvLK5 d2PViSSSfqTX5xXlKrNylufaUkoU4xjsKe+wgl/lAXsDSvZeZpLmd4o+n/BE32vwtpE10WCxRmIB eS+1yByfYZ/Kv0HKJuWCTqM+Nx/uV3BdDxL4i2iWvi/VI4zwfLY8Y5KKTkdiepr5TNYqnjpJeR72 Xy58KpPzPp+EvO1w/BuioCDO3A6HHToBj6V9xB/uvl+h8pJfvbeZ8f6jK1xqF88rZBlkd3HJZiST z+lfnOInL2jlLc+2w9NezUVsdz8LDPB4jkkQfKbZsE8jIZCP1FetkLkqx5ubqM6Xoep/Ei83eFby CGJII5ZUMrKcnGQSBnnHy8KPWvfzuo1hXoePlcU8Qk3c+bOJgGdxHEgCqAM/XA/Umvg7Ra03PrbS eiPpH4X3d3aeGY0jlG1JnGMBhwcggEdQWyDX3mQt/VUmfI5vHlxLSPOfiiTH4mhaOYyXUtojOw52 5LEjJ5zjqa8TO9cQos9XKf4DPetM060g0HTls7kSG3toVdCMAgqBlT3weD+dfWYSjCNFRgfN4qpe bv1KA8LaJqcrRSaVaGebJkuJcgsBkksxPTuaweBwcp2mld+ZusXiaMUorRD18C+FJ86fp3h61lbJ L3JUguAcg8nCAD8/0qXluDbVkvvE8bit22aml6Xa+GZ4Le3sVghjkEpiRjg5AOVYE9RyCDXXRhRw 8+Wk0kYVZVcTueH/ABdt7G08SWd3aTm4lnt9x8xCAMM4BOeScYz2r5TP1H2yqR1Posm5vZcktDye eGRCJJ2HmOdxXPPPcgdM186023zHtRdnoR+ZIY1h3Hywc7R0JPf3pJyWg7X12JhbbVZp3EWOArAl icZGF9OetP2S3vYHUVrIrqzIQ6Ehh0I6ipi5fZ1KvpqWDFFFsa4cuzcmNOoBGeSe9aJJfFqZKUm7 RVhJVieJZokCHcVKZz2yDzRUScbpBRk1PklIRHhaJYpyw2EkFQCSDjiqjOEoWkKdOpCreL3G+ciK yQxKMkgO3LYPb0FJVeSPJBFey5rc71KmMcVj8O50diz5UKxhmuB5hGQignH1PSteSDWsjB1ZS2j8 xJTbMNsMbgg/fZuT+AqJODXLBa9wpqpB81R/Ig2j1qDoOlKWxiUoZBL3DYx+B613tRWq3PHXtYy1 2HwQNOxRHjVuwdgufoTTjTc9UOvVVJc0hz21zDGJTGwibjep4b8RxT9nOLu9jNVqcnyrVhBIsLh2 iSQYwUcZBB+nSnTspa7EVeZ+6nYmc2UkbsI5YpwflVSGQg9jnkVd1axkm29dR9iJw8ssNr58aqVl i55U+oBzj3FOjB3ugqyi/i3BJ7GBJ5IhMJnR08hsFBkYBzwSB6EVpZJEIopFaC2+0XckoQyGNREA SpABy2frjFRGKvc0TKl5PPHaxxvNFcW8hykmNzIRjIyeQfaidyoozYHkVJZIhFMD8r2znlh2IHBP PpyKiMrG6gZd1d262slvB5xLsGKS4xGRnOMdSfp0pM1jEz2EkCyRq8UruvzwYJK4GQR7j2pJWN4o xrq7YIYIJpDankI3Y9cfgaynK7N4xsVZPJIhULgMBiZSSQ3cED3oa0N0jNndpJAu1fNHykr3I4yf espauxrCKgdh4R8E6x41uBa6fEsWnxYW5u5VwIW5OAerMewH44HNXBc/ux2OfE4qGEg5SevRHvV7 rmieA9Pj8K+CrRbjxA4SJ54k8xnlPALkZLyEnhRwOmKxxONp4WPJR+Jnl4bCVs1re0xGlNbI63Qv hZrHgWSHVNX0u2v/AIl3B82ODU9stp4eJ5864Qkme75ysWNkZ5c7uB4ccFiMXLm6M9zEZnhMuj7N PVdDN1/w1Jf6sfDenTSal43v2F9rHiXUCZZokBByWJOzJC4UY7Afer0nl9Om40YayfXseXSzSpXT xdXSmtl3PXtB0TTPA2hSC/1LJeQ3F3f3j/NczEAZOSckAAADnHrXq4WjDCxcp7ny+NxlXNqvLSjZ LY9F8FW0VvZaj42+IGkRab4albGiaRekRT60UB3yyrkMkIwM5GT0HU1zLESqzcaKtHudtXA+zowV S7l2Pk3xn8c/iH4j8Yan4gsfE97a2bsIrexBD26RKMACFgUAI7AcDjtXj14QrSemp9dgITw9Fcz9 5lnQ9ctvE9vLqfjbwt4MfR4ZfJmvzamyu5nwCUQWzK8jYYc4AGetZwwrk7XsjWvi/ZtPlvI+hvB3 wc+Ft9pl8+teFNc0hrudJraXT9X82RbfaCEYsu9Qc5KeYeepyK76OBqL3r6ng43PKKn7NrXqfVXh vwl4P0+2h186vL/ZNo/k2tnqNiVWacLlFLK7l41wC2B6A9a6J1q9/ZRj6niQoUZSdeU/wKVz4am1 S6ub5vFGkXt3cOZJJGuHhLsTkk+aiYrSlVcFZqyOWpRVWpdSuxE8Da03+ogt7jP/AD63kE2c9MbX NU8ZEFgqnRA/gfxLGAz+H78Keji3Yg/QgEGksVTZX1KpHVIXTvDhj1G0/tuB7TTIyZ7mW4QoqwoC 7kkgdQGFZVcRHlbTN8Ng5TqqMj8+PjF8SLf4n3bXknhGW11eK6kZdR8xn3wknCBdo4PBGelZLSKj c+jw+Gnh5e2k9GeGG2lHJiYAdSVNPkR2pvsM8k9SCAOvFHKirvsR7E/vD86El3Jbdz61+E/ifS9P 8MeEtA1K6EJvmuVtSwOGlFw5ZCegyHjxnvn2zNJpVJanBmNB1qcbHnXxw1+a98SP4bt5SdO04L5k a4IacgkknGcgNitJNPqLAQdNao8Q+yyngROT2G01KS7no3d9hfsVwelvKe3CH/ClaHcPeO08O6Dq 2pWOuaA2l3R8+EXVuxhbC3EQJAzjjehlT3JX0rKTiuponIxE8E+LZAWXw1qewdXa1kUDvyxAA/Gn GcGhqJ3HgfR/Eenakmm30cUGn3Gf3dzcQoVkxkYDMCCcc8VUakEceJoc+tjH8Z+C5NP1u5km1HSr W3uD5qBrjcT0BJChjknJ4olK5phpXgkzL0WLQNOme21bW7e70u4wJYbe3lYBh0dSwXBB68cjI71n Zs3uopnpkmj6NYgxQiaSMAFTDsRGBGQV68EYNbwd0eZVaT98y5ktUz5WnJn1lcufy4H6VajYnni0 ZU0lzgrHsiX+7EgX9QM0cge1KLItyogum+deI52ySuezHqR/KixSqXMW5s5IJHilTa69v8Ka1Dm5 TPeDsRTcbFRqXEG11ENxkoOFcDJT/Ee1Ty2NFK5SntWhbawBBGQw5DD1BpbDepSkgVxhxmhouMzI lgeE8jKno1Rsbc1yMcfSgrcfj24oJ2AAfSgBwHqKB3FAxQO4m0UBcXApWC4Y74phcTb70BcXAoC4 YFAXDAoC4YFAXDAoBsMCgYYFABgUAGBQQGBQO4Y/+vQIMdPakwRLDI8EsU8fDxuGU+hByK1pTtJE 1FeLR9a20kd1b291Fny5kEi9+CAR/MV+j0ZxqU48ux8bVXJUafQ4f4jX32Pw81urYkvJFjx3wPmJ /RR+NeVnlZU8Mox3Z25XBTq8/Y8Hs7l7K7tbyP8A1kEiyD6ggj+VfH0J8k1Nbo+jq0/aU5LufWUE qXEMNxCd0UiB1PqCMg/lX6RTd4RmlufGT9zmp3OB+Jd0YNAitgcG6mVceqrlj+oFeLndT2dBxb+I 9LKaaqVObseB4NfGRilqfTXvoe/fDjVYrvQ/7OZh9osWIK9yjEkH35LCvsskxEalH2TeqPmc1oun V9oupzHjvwbf/wBoz6zpts89vP8ANLHECzRvjk7RyQeuR71wZvgKzqqrRvynVl+Mp+z9lNWaPNod N1C4kEMFjPJKeNiRknP0xXjRo4iUuVXuepOrRirySsddL8OvEiWKXawRvKRua2VxvUduvB+gNdss pxajzRbb7HH/AGhh5Oy2OJmglt5ZIZ4nimQ7WR1KkH3B5FeXV9pTqWlujui1ON1sfUPhVQPDuh5P WBDj8BzX3+Xq+Hi3ufJ42SdZrdHgHi0snifWHU4YTlgR2PFfH5hKKxsmz6PCXWGUe59EeH9Uh1vS bHUIipLofMQfwuOGB+h6e1fZYKt9aorU+XxVJ4et7x4z4q8B6lZ3s93pVo9zp8hLhIRueIk52lRy R6ECvmcwyepCbnDVHvYPMKLVps5O28M69dv5cGkXZfjJaIqBnpliAB+Jrzo4CvN/Cds8ZRhrc6jU PhtrtjYx3cTJcXAXMttFksncbT/Fx1x+Ga7qmS16dPmX3HJSzSlOXK3Y8/2vEzKVKyK3IbgqQens c15EV7Oqr7o9J8so3W7PrPQtTh13SbS/t5FL3ChXRf4GHUH0wR+XNfomDrU8VQUlufGYqjOlV5Zd DxPxX4F1Kwv7i70yykudMmclFt1LGLJ5VgATgZ4OOnWvlcxyqtCo6lON0z3sHmFKcOWcrNGHpPgv xBqdwsaWE1vbhsNc3CFFUdyM4JOOwrlw+VYqvNLl0NsRmFGlTdpe8fSmnw2Gi6Ta2pZltLCM5ZiA CAMlmPGORk19zThDC4e0tkfLzlPEz5lufL2vakdZ1jUNQYnFzIXyeoQcKD9ABXwWKre3xPtPM+sw 9L2GG5LdD60liQJFJGGCvnhsE8cZ47Gv0NKLhe2lv0Pim7ST8z48l+a5liYfJ5rEjpk5OOf0r80r P95JM+6pOKpxseifC4SHxNJGVzLNbMoBOMDcmMj8K9jIOVV0eZm93SZ6B8UECeG5lVw4FxGNy5we T0zXv56m8O9Dx8pssQrM+ey0bBHLZKABY8d++fbvXwi0bPrXK59H/DWLd4WhHzyXr3MpZAPugY69 yT1+lfe5Cr4dNHyOb3+sNs83+Jh8vxK8Um6NjaoucHKkM3BHXnvXg5419Z1PVypqWHSPZvAerRa3 4ZsbaG4EUFsoiupXHJZBgZwM8gZC19LleI+sYeKi9VueDmNBUazutOh4l408FX+l6peXenW0tzpE 0hkR40LGIE5wyjOME8Hp+NfOZrl1ajWlUp3aZ7eX46nXpxp1LJo5y10HWdSWKLTtNmePALuiEcng hmPA5HAPFedTwuJqySimd9SvQpK90dPq3w38T21pHeW1mbu2hjAkEBLPFnJwRgZ5OBjNd1fKMXRj eLbOSlmmFqy5WrHAJI9t5qeWFmztJccrjgjB6e9eNd7SPT03QkUDyh3LKqLyzueOemO5qUtbmjeg yN3icSRthhnB9PpSi/5SX/eLLJHEwe5cyyHJKKeQeo3E/wBK0tf4ib/yjLiOMCGSNdokQkpnOCDg 4z29KmdovQcZSa1HPNDIu6SEtPtC53YHAxn1zVJqSJ5bbMRxdXCeaY/3K5xtAUD1xRJyaCm4JleP YHDSAlB2HBP41jHl6m1SV1oTpM+8/ZYQhIAwo3Hj3Oa3jOTX7pHPKCTvUkV5UkDt5wIkPJ3etZVF O+p0UpQsrPQkSGJYlkm3ktnaqYwcepPvVRpwjDnmzGdacpuENEh8QhmKQ+QEZgfn3EkkAnv2JrSm 4VlyKNmRNypQ9o5XKOG965XoztVmrnYzxv8AZQ1xCsUoYKuF2lxjkkd/rXsVIOUJOfxHz9Gf7yMY fCxscNssCS3JkLSlgojxxjHJz1yTURh+7TkVUrTnUdOHQWSBFgWWCdniJAdWBXa2MgdcHvVSjHlu ZRnPn5WrMltkuRFI62CzwHqWUnGO4IINOnC6vy6CqSjz8rlqQXBttsYiglinHDhmyDjuAQCM+lJp LbQuM217z0ES0umiW4t8Pk7cRP8AOCeMFRg8+1NU59Bc6b13Kd5dXE2yO4bLRDA3IFbHoxwCcY70 p3TCw2JiYljs7wCWXiW2nAVGI5HJ4PTjODVJaXGkZGoXbyvHBJEkEUTEGOLkKSRk8k80OSZtGBFd LC9yIEtzDlj5M8DFg2eRk5xnjkg5rNs3ijl57gzzFrqZjk4ZwATxxntmskzoiiCafYUmmTzQmBHN EdobB6H/ADmhs6IxMcMTm4aZUYsdvGeRz+ArJo2SKs0zxFtpaOYn51X7pHUEUpSsjWMTtvAPgO78 b3siAmHTLdv9Ju+65wQqA9WPzHngDk9gapU3VOXHY2GChzS36I+htW1Cz0jTLLwF4Et7i51q5ZbW 3is4zK7FzghSBmSQk4yATnvxUYzExoR5KS1PGwOFq46v9YxD0PbfAXw+sPg5D9pnEF98XZQRNqMb iWLw2CMGG2YZD3RH35hwn3U5ya5MBl7rS9tV27G2dZ5Givq2EevVmV4q8W6X4Ts5p7ubzdVkQtBa clpmPct2GTySa9etiKWGWm587gsBWx1Tnt7vVmF4C1zRdL8PT674k1a1g1fV5pdQuELDc4BKoFUZ OAoXCnoS2OprkwtanGLqT3Z6Wa4StOUaGHXuRMay16bWNVb4q+I3lsvAmhTGDS9PXAl1a6ABEMWQ QCAQzzAfuxgA7iK8zG4ydeTjDY+iy7K6OFoXktWeR+NfGviX4gazNrnifUHnlxtgtkysFnEOFihj HCKBwABk9SSSTUQjJR5Dsjy03dRPffBX7PNjeaRb33i+5uVv7kCQWdnIFECEZCscHLHOTjgdBnk1 3YfBJw5pnzmYZ46M3Cgr2PfbD4Z+DrLVLHW7Tw/axalaRrHDKiABABgNt6bgO+M55znmulUKcXZK 54c80xdZe89z1fQfD0usX8VmriKLBlmuH5WCJRl5G9gPzOB1NOvV5F7phh4SrVPfNjWrmPVLqKOz iaLSLNPs9nbnqkYOSzerMfmY+px0ArKinSXNLdmterGcuWGiWxTjsv8AZqp8tjHlfxFlbEY5XPtU OUWaaqOjPnLXfjBrfgP4pP4X8SW1rD4Wch1v7dHWVInXKOcE5wwIOB057VPs77HtUcIqlHmT1Mrx 18cfElz4a+I83h3xJOPDlxcWmjaTcwvLHKZSDLPNHIGDDCRsAQAeR61y1KEZVFBo9PAUXRpOo9z5 gHxF+IvG/wAd6/LjvPqM0p+mWYnHtnFdLwtN6tHYsRJLVjv+Fj+Pc5bxLO/qJYoXBz6goQfxFP6p DsL28+44fEfxuDn+2YTjs2nWbA54wVMJBHsRT+qQ7C+sT7iH4jeMT/y+6bj/ALAem/8AyPQsJDsC xE2dbqHjvxZH4N8IahDe2SXRvL6Jn/siw6oYmBUeThSPMxwB0yawjhoKpLQ1lXm6aRxU3xB8azyS TT60sksjFmdrK2JYnkkny62+rQ7GUas4dSofG3jEjH/CQ3Q9Cm1SPoQAR+Bo+rwXQr2831K7+MfG bf8AM26yvr5d9KgP1AYZ/GhYddhe1kU4/EfiOG5trwa7qMs0EglQS3UjjIIPILEc45qZUYroUqzL XjSwhTWBqFsCdM1SFb+13EsEV8lkGem2QMMdhippJPQqbtqcvAWtbiC5hA8yF1kUHpkEEZx24rRw Rm5cyPonUNI0T4jaLaXNpeRxagoLJhgXicjBVlznGR/UVlY4VOdGbR4n4h8Fa34bUS6hDGbRn2LP E4IYkEgYOCDgN2qkkdtLEKbVzs/CWmeJdY0WOSxWHzrTItzcP8t1CDloyBkgoeVPpkelZN8jHUdO a9/c6c2ExjUzxos2PmVCSAfYmuhO6PMdlKy2Muew254p3FcyJrPGeKNy1OxEIEuo1tLlgki8Qzt/ D/sE+h7Ht9Km3KaqakYFzZyQyPHIhWRTtKkdCKpPmC/KZskGM8UMalYjQqqmGdS1uTnA6ofVf6jv UtGsZFK5tGhYDIaNhuRx0Yf56iktRvQoSRBgysOD1FDiUpGPPbGE5HKH9PrUnRGdyEc+9BT1HYFQ A7Gcd/agVxdvrQFx2PbigLhTsFwpBcTAoGGBQAm0UCuOoC43aKAuOoGJgUCuJtFAXFwKAuGBQFxa AuFAwpbiuFNLUe6PdfDHjXQLXQNOtdUv/KvYEMTJ5UjYAJC8qpB4x3r7HA5thoUIxqvVHzeLy+vK o3TW5xPj/wAQWWu3timm3Bms7eInfsK5djyMMAeAF7V5GbYyGKkvZvRHoZbh5Yem/arc4DZ7V41r +8j00+x7n4W8baFaaDYWmp35iu4F8sp5UjZUEgcqpHTHevrctzWhChGnWlqj5zF4Cu6nNGO5x/xA 8QWGuXOnJplx51rAjMW2MvzsQCMMATgBe1eZnONoYvljRex35ZhXQTv1PPK8Xl0949Re7Fs0tJ1S +0a9ivrCXZMhwQejjuCO4NdOGxUsFNShqY4ijHEQ5Xse56R8RtCvY0W/ZrK6xhlcFkJ9mAPH1Ar6 3D51SqxSqKx89iMsqQleLudAfFnhlV3nW7Tb1wHyfyHNdUsfg91L8Dn+q4lacuhx+u/EqwgieHQ1 a4uSMCeRSqJnuFOCT7EAV52MzyEVy4fc7cNlM2+aa0PEriaa6nlubmVpJ5WLO7nJYnqTXykpyqSc pvVn0CjyxUYrQ940Dxl4XstE0q0utU2XEUCI6eRIdpA5GQpB/A19bg80wtKioydmj5vE4DETquUY 6HjviS6t7/XNTvbSXzLaaUsj4K7gQOcEA/mK+Zx9WNevOcNme3hac6VOMJFvwx4ov/DV00kC+baS Y822Y8MPUHnBHrW2Dx9TAzVnoycZhYYqPme1WHj/AMN30YMl4bWY4BjuEK4x6MAR+tfVUc3w9aPN UdmfPVsurU3aBrS+L/CyAu2tWuC2flbcQB2wuSa6HmOEUb3Mlga/a5wuvfE2ARTwaAjPM4I+1yrt C57qDyT9QPpXlY3PItOFE7sLlPvc1Q8Zld5mkklYvK7ZLsSSxPJJJ6818pOU6rc3ufQxiqcbROj8 M+Jr/wANXTSQDzbNz+9tmbAbHdTzgj1x9a9DL8fVwclbVdjixmChio8z0Z7npvxB8MXsS77wW8wB xHdArtyOeeVP519ZQzjDyT5nr2PnamW16b0V4ly58beFbOPe2rwzBBkJDmQsx7YAI/OrlmmFw8Lq WpMcBXm7uJ5B4v8AHdz4hQ2VlG1tpwwZM4DzkHjdjgDpwPxNfOZjm0sUvZw0R7WDy2FH3nueeL8u QwOCPpXjRsprmPSmvccUj6hX4h+DwTJHqoDH5EQW8x2DuQdvWvuv7YwXs1By6Hyby3ERqfBpc+Z7 gRtLPJExK7zgkYDZPbNfDVZKVSTgfV07U4RR2Pw/1iw0TXJbrUrhYYJLdovNKM+CSpxgAnnHXFer lOLo4eqvanBmmHnXpPkO+8deMPDuraBLpul6gJSsitt8iRTIR1JLKBx256V62bZlhsRh2qUrnnZb gsRh66c4nhgV42VsYbgjP6GvkrdZH0Uve0Z7v4B8XaDonhuOyvNRa3vJJZWlbypG+QkYGVUgdMnn Jr67KMzw+EoqNVnzeY4GtVqtwicT8SdZ07xD4h/tLSbhriyS2jh8+RChZhkHIIByeteVnFehiq3N RZ35ZQlQopVYmL4a8R6h4fvBcW0jG1UZltv4ZRnv6Hnhu304rmwGNq4GpzrbsdOKwlPFw5Hv3Pob T/if4Z1XT5BfTx6fIAgitpoyCrA8lWAIIILZJIz6V9jh88w1eF56PsfL1cqr0naOq7llPGPhCF1e 812A24yzLA4ZjgHAAAPXpnFbPMsFB83MY/UsZLRROE8VfFc3kL6V4WikSJ2O2UggJnqVU8k+56dh XkZln0JR5KKPUwOUSg+aqzwxw6ysZcPIGyxY7snqckHmvkZSu7n0UVoWW/ebJ7uXIP3Y0xnHPQdA Kt7CT1I5kj2RyxqUD5GwnOMHggnqMGpat8I077kjTrJz9nDXJwN5JI4AGQB3OOaafcGuwk6Tsonu JAS3QM3OPYDoKbbkibxi9CKF3jc+XGrSHABI3EH2HrUwck9gnFS1bJmgkJYXMyxsOdjHJyeeAOK0 UZdSeeCehWaIxymOT+E4bHp3xWVopm6kmtC7Ol3vKoMQo2FZAFGDwORiuifMmnHZHLHkfxatle4G 1IYi6u6ZJZTkYJzjPrWdVKKtfY2pNyk3bcakqKipJErqpJUZIwT1zjr0pRqe7yuN0OdFuV4ys3uA lbaUjjQA55C5PPv1pufNG8RKGnvu5X2g1gb2OjmjRCqpcCYY6gEY/OvSqKPNpK541GUvhqRsXLeO 8+zt5JjaBjyjFSc5x0PI/CtKaqqNkYVZUpVL7NCXj3A2wzWywYO7YibQxxjJH044p1G18RNLlvzb ipLbTxW6STyQzRfJkLuXbknJwc556YqoyVtNCGlz97jdQmWc2yfaPPlQFXnbOGycjk84AolZ7O4o 6b6BdRWMN2tqUubchyq3H3vM5wGVcA8n0NO2nYad3pqY1z9pkvHjl33Fwr7SCSxbBxjPWokte5rE pXQsWM20yW0qDIgmBOT3AIAI9sih/cawMMzLGwkMayIOCrA4OexIxistjeKuUri6VY2+yzSRFyd8 OSRjsQe/HHNS5HTFFBJ2SAxKQkznOHUYkBGAMnjA60k9DeMTIvABKqIuHIBMancAfQGsXudEFYrM 20FAGGBl4XOASO4o20RpbWx1ngfwVeeOdXSFUlg0eAgXN3GufLGMhQTwWOOM9OppQg60uVbGOMxc cHDmlufa+j+E7dLew8N6RYutllIo7S2BZ7licBCR8xyep6knqMkjtnSUVyPRHxrxft6rq1dZvZdj 266sdM8ARjSNNS1n8biMx3eqwhWXSVYYa2tiBgSEHDuOn3F4znCFH6xL2kl7sdhVMZLDRcYP3nuc lHbOUbyyBIQdpYEgHsSB15rtbtG0dzyOdKSc9nueB/E/w14e0i0kurrVru/8X3cqEGaRV2oOSTEA QgxgAZPbFeRiqSj7z3Ps8rxU6lqdGNqZxPgjwbB4huL/AFPW7trDwZo0a3Gq6kq7mRCSEhiU/eml I2onrknAUkeZUly2gt2fQ01z+89EReMfFE/i3UreSOyXTtB0+IWmlaPE26PT7YEkIG43MScu55Yk npgDSlQ9n8RE63M7LQ98+EnwUt7i0j8R+MrESi5QNaadNnCxsMiSQA8kg5VT0HJ5xXdSoczufO5p mroP2dPc+tILIAKoHAAAzXZdJWPlmp1J+0NWK1yBxioclY0jHXRHoF1anQNHj0VBjVb8JcX7DrHG eYofbg72Hrt9K4FL20nU7bHfJfVqXKlq9zm5Pslp5RvLqGASHYhnkCBjjOFJIBOO1dHM5HPClKS0 NeK0DBSvzA4IK8gg9CMdayk2ivZyT945LUb7xB4Y1HVtX8RxQP4FSEPHPp8Mjy2BUks1wCOQQQQU BA2HPWizfunXGhFxUVufBvx68beHfHnjC0vvDReXT7O0Fsbt0KfaGySSFPOBnAJrrowcVZno4SMq Ca6nL+MkGl+HPh/4XQYdLF9Zuh0Jmu2BQH1At4oCP+uhx1rOjT9pUlVPSq1eSEYHne33rscNTlVa 65RNpo5GHtRNntRyMPajdopKmL2p29+of4b+FZCMFNZ1OH6gQ2L5+uZDWEKf72R0Tq/u4nD7TW3K 0YqqM2e36U+SL3LVREZMQOC6hh2JFZ2ithqoG3v2p8lxuodnHH/bHgadCC154euhIp7/AGWckEeu BKMn/roK5uV06mvU2VW9P/CcQY/StXS05iVUSdhFDxsHjZlcHIKnBB+oqVDUTkjp/Dvh7WvGl+2m W12SIYmmaS5ZmSMDAHAyckkAY+vQGsZPkVhuokeveBPBnijw4DPf3kcMDMWFiuWdHB4fcOBnHQGs pO5hVqr4o7nf6xpMc0aanbxhYZm2yoowIpepAHYHqPy7UozsYVFde0j8zi7jT2Gfl962UrmSkYVx YYz8ooTdx3uYdxZH+7VlqXKRtaf2lGLdh/xMI1xEx/5bAfwn3HY/h6Vm0bxnzHKzWzAkFcH0rRe8 IzZIPak1ylKREhCBoZl32zHkd1Pqvv8AzqWjWMrlG6tHgYDIaNxuRx0Yev8AiKlMt6me8QIIIyD1 FNocZWMW4t2hfIHyHof6Vm1Y6YyuRDHpgHtQO44flQJsdgdu1AxwBPbmly3AXaaVhXF2+9FguJjn FUMMGgdw2mgLhg0BcMGgQYNABg0BcNpoC7E2e1S7XD3xdpqmnbQLvqJQAu00DuG00BcNppWC4bTT EGDQAbTQAbTSHcNppWs9ibqO4YNVe401LYXb70XiNLQTHT3oV+jI1XQXb70XY7Bt96Bi4FABgUEC bRQO47Z7UBcMdfl9TRcQFfTjii7FZBtPFUMU5zyOnb3oAUDABz07e9FmF2LtHQjGOOO5p3kgsnuG CpOD7ZpSbb1JuKBuwu33J9abSsIeVLYVjg53EnsKQDVBUhsHHSgB4wPmAAVeinnJ96E0TdsUx8Md xLj5iMcfSq5UyrIA27/WMWx0Hv70ySYIC5WQbnPJOfujH9KBXIAcYBY7CeQO9BJOcEB3XbFztRT3 /wA9TQAMDBJmPIyoOD1GRyDQBJvAImciSY54YZC+mf8ACj0AhKsR5hBwT1xwTVO8d3cLX2RYj3PH sjCoqDLOxwTn36+2BQk5CbfYGigaJ2hL5TGS+AGz6AdMUWC45ZVZFR4BJIoKocnoT6DrjPFMY6dJ WXfczASDhYznPHbA4AokubcS5V8JHbtOH2QNtd+C3QgfXtQrbRC0upII7YMUllZ3LAb0xgZ6nJ5O PpTUU1uS5NPYSPFvdYkBKoxDY69xkfzpL3WOXvIQpbRMpeVpeCSEBUZ7fMf1qkrbitO3ukUr+dIz kYz0HoBwOazl5Fwsuo8Qs8Id51CAEKrMSTjsFGcVcU5R1ZMpRjO0VqNkS3VQElZ39SuB/PNS4wS1 Y4zlzXlGyGxv5bFhGrsRj5hkD8KIOzKqR51qywjXjFvKVgSckIu3r+FaqU3L3TFxw8Y3nuVSr5PD Vg4yudKlHudLcxKiwSCLyi4JMRJOMHAPPPNepUgvS58/SqSvKLe3UleCzh8qOZ5RMQrMygEKCM9D g5H1quRKyuZ87lJOOxDcRMkkYWRpUkQMhPBIPTjJxSlBJ+67lwqJwta1jRKX+YYWgtrrYDiP5WbA 4IJBB4zWsYu2qMXOD969jBkaJpsuhjhLcqnJUd8ZPOPes3ds0W2hZNzLFHM1pqqvGigBJxtYjr8q nI4PoatyaW4JXepjQXQjNy8wl2SqUaWPllJIOcnjnHNZJ3ZvHUp3l0hs2V7xZ3ZgyAqd6HJzkkZ5 474omzaETIctboqJeBJZgCY2HyEHONxPGfqKyZ0RRhXkgaYgxpEejBc4B7nvx9KykrnVBFGaSaIb HCywLlRk7l55+UjpRfQ6IozI2IZmUZ4IKg4JB4OKz6m1joPDHhfUPGWpxaPpr5YDzJp5FOLaMcEk 9Tk4AA6n0ofvPkW5FevDCU3VqfI+5PC3hqy8O6TYaNpkGIolAO0EtNIcbnOMkkn/AAHAAr0qdKNG Fz4DHYurjqvM/ke/eUPhzaSWUJH/AAn93HtuJlIJ0SJhzGjDP+kMp+dh9wHaPmJI5UnjJX+wvxNH bC03Heb/AAOJt7fOOK7E/d5Tzea613PNfH/j+Tw+8mg6MqnU3iBe7DA/ZiegUYOTjnrxXHiMRr7m 57mWZb7de1qLQ8N0Dw/rnjjxHZ6PYE3Gr37ndcXL4WNACXklc9I0UEknoBXmVZyj70z6ulFXUKas kdR4217S5LSw8EeEZGPgrR3Z0uSu19XuyMSXkg684winhI8AckkxRoqL9pPcurXv+7jsdl8J/hFe +JLzT/EGvWIHhUAyxq7gG7IOANoOfLyCSTjPQZ5rrjSctWePjsw9hHkXxH3JbWiqFVVAUdhwAPpW 38PQ+WlJ1JXl8RQ8SeKPD3gqw+3+Ir+O2Vlbyojy9wyjJVF6k89KHF7mtLD1K0rROR8L/tAeDZbL WPFU/h7U20rQEjlniuvLQXE7krBApDHJZgxI7JG5zxzy4hST9mt2exhcu5JOc3ojzzxV+1Z9vivZ vD2gTjWrti7XupshCOxySI1JB9skD2xxXRTwvIkkQ8O5yvJnzP4v+IXi/wAdGy/4SbWHuUs8mGJE WJEJGCwVQBkjv1rqVBI2hGMF7pLpnxJ8e6No7aDpXizUbbSjuIhimII3YyA3UA46A0fV1ImXLJ+8 c0+ua3JDNbyazftBLnzI2uJCHz1yCcHNWqCT5gjOKvbcd4e0a48R6/ofh+z4udTvIbSM4+6XcLk+ w3ZPtVV0oR5jSjUlUmorc2PiBrMGv+NPEeqWYYaa9yYrRf7ltEBFCv4RJGPwqcPR5YKIYnEXm/I4 /JrdUuph7bl1Ep8gvbicAUcg/bCbval7MPband3ID/DDRD0MXiC/x777ayzn6eUPzrmhT/eyOqVb 91E4M+p7V0uKSuznjX5j2Pwx8BPif4rs4tRs/DxtNPlwY59SkFv5gIBBCk7yCDwQMVwV8ZRpaG6T Z92+D/hjpeg+ENE0LV9H0u51C2tkjuZY7dWWVxyxyRk8nqevWvEq4uUn7hqmeE/FH9m2fWNWGr+A 00+yjljJubCVmiQyA8GMBSBkdQcDIz3rqw2N5P4gmzkPCP7O3xA07UWivzphsNVtZtPuoUuSWiEi /IxyoU7ZVibgn7la18ZSkuZG1B3lynhviH4V/EDwu041fwrfJFDnfPCnnRrg4OWUkfrXVSr0qsVr uQ5NSdy18PfhfqvxAuL9be5jsrOxKrPNMpZlZgSqqmQSflOckYpV6igk0HtGz374R+CI9E0XVrpp Yrm5ubyWE3EWdrpExQbT3BO4/jXBXq3asTUk7HoVxpnXcvNQncxV47mbDaxQySwXSk2NwNko7qM5 Dj3B5pNWNKU7Oz2OU1XRJbK4mtplBdDjI5DA8gj2I5Fb05qwpqxyd1p4wflrRSVzNM5y6sMZ+U1a HzXOfuLMqcjIIOQRwQR0NNopS5SC/tP7Qgkvo0H2yIZuEHG8dPMA/n+dZr3Tdu5yM1vjtV/EK5mS wY4xQ1calYjjZArW9wCbZjkEcmM/3l/qO9Q4m8ZmbdWjwSGNwDxkMOjA9CD6GhajehnyQhgysuVP UGlKJpCZiT28luyh1IVhuVm7jp/SoOlMiAINANkgX8fWlYBQMd+KYDscYxSsAoHeiwBt96LAG33o sO4bfekFw2+9AXDb70BcNvvQFw2+9BNw2+9AXDb700pSeg5S5dzZHhrxCwBXQdRIIyCLWQg/pXV9 SryV0jB4ulF2bMho2jZkdSHXIKsMFSOoIrmatobp9UN2+9SO4bfegLht96dguKR6cUguJt96AuG3 3oBsNvvQFy5Z6bqGoF1sLG4uWQAsLeJnKg9M7QcZralQq1/4aM6leFH4x93pWp6eqPf6ddWyPwpn iZAxHOASBmqqYerR/iomniIVvgHaZo+o6zO1rptq086IZGRSAQoIBPJA6sKVGhPEStSQqtanh1eo y7qXhbXdItxdajpzwW5YJ5jMpGTkgcEntW+IwFehG80Z0cZSrP8AdswdorjOrmFwKA5g2+1AXE2i gB2z2oAKAF2mgAwaCAA9eKAFxnr35/CmGxb/ALNv2AZbG4IIzkRsRz+Fa/Vqq6EfWY9ysVZCUdNr jPDcEHoQQazcZR3LUubYVI2cqiKXYkAKBkkngAAdaFHndglNIsyWF7GjSSWcyIuMs0ZUA/UitJ4a dr2MlWjtcrAHoehIzWJqWIra4uC6wwvKRgt5altoHTOM1tTpueyMp1FHcJbO7tgs01rNHGTgNIhU E+mSPaidCUN0TCsp7Mj+U5xkJ1bJ5PoKhKxpZsCmQWGAcZ2jsKBXHZ8zIbCjqxA5JoEKE8zBJVc8 Kn+fX3oAVGJCoEUv0Vj2zQAPtA2j5nLZL56/SrIEj2K2XTcB/D0yfegDZ0zRtQ1u7WwtIXlvNuVh QgbVyBk5IAxnp1rehhp13y01dmVWvTw8b1GXb/wtr+h280+raS8VmHCM5deGzgYIJPrW+Iy3F4Nc 1RaHPQx9KtK1NmIVdlAkPk2/LKmCc59B1P41xWOxO5XiZ1YGNiHPGRweeKQy1tiikaPyzPN05yAD 3wOppqMOexL5r6F2w068vNVWz0q2ae4JJWHIBIAyQSSBwN1a4ehUq1eWmiK9eNKN5s2bvwj4k0u2 kv20CWG2iwrzyMjhSSAOhIBJOBxXXVy7E0VeUTnhj8NVdoy1OTljaNyshUt1ypDDn3Fea00/eO9S TXukqvGFQRW2ZRgl2y3I/wBnpitIvsQ79WJdR3RKvcoRxgcAY9sDpSnG+4Q9mnpuNiii8pppi+zd tATGScZ5zVK0Y6oU3JytTHxiCUGMQ7XCE79xJJAzjB9aEqco6oUnUhK6dyO1AEhGcOUOxu4bHGKm lH3vdKrfD7w9obouRLJtdhkl3A46etW4z57shSpSjoi6Lu2AAblh1Oc5rr+s0kcDwlV7Mt3AO/Ju fOYgZfn8snninUhrpK5hCStrGxejN3iBEuLZx1RZGU446HIHr3rdKSW9znag3sU55bl7tS203CMF VUwQCDwFxxiob9/YpJJNksrWouGmubC4ilHzEBuC2c5bcMgGre+xEU+W1ypBcK93czyPHFNKGZHc ZVHJB54PbI6VKZdivd5ezmmuEthIWBjkhK5ck4IIB4AHPSlJGkEZOWt4QwvvJedciPaSrLkjk846 elQtDpRianLIZsSRxIwUcwjAcHoeODms5nRBGfNKAn7uVJoUBIimAUjPXHr+BqOh0wRj/aAz3Ekm wzNyDIMjOeRj6dKi9jqjEz7nKKgAKs33kVsg46EAeuag3itbCWWlXeqX1npdjCzalcuI407OxPHP b3J4FQotst1IwXPPZbn6N+Bfg9peh+EI77wbfSapqaQpLr9pMoFzDKowZIgADLagnhgMr/GBnNbU WqE7VtL7M+QzbEfXtaHwxPWtBt4/A2lWviq6iV/Fd+pbRraQZFnHkg3jqe+QwiB6nLdFGdJzljH7 KHwrc86MVhYe1l8T2OTSN5ZHlmd5Jncu8jksWYnJLE8kknJrrh7sOVbnA5zm+ZnOeO9ebwz4feW3 Um+uyYITxhCRyx+g6e9YVZWjbqdeW4b21S72PlEx5LM7EseSzHJPuSa4+Wyuz6+E+X3UewaxCfhx 4Wk8JQHZ418QQpJrko4fTrM4aOxHcSScPN6DYnXfXNTg8RJ32RvUl9XXmeS+UAOmK7lTsjkU33P0 F+EdxbH4d6HNJZ3Gn2lnAUZ775QwUkmRWOMxnJIOMVCumfP42Mp1Nzzz4gfH+CzWbSPAgWa6+6+r yrlE/wCuSnqf9o8egPWtY0XUd2FHCJ+8z5Wv9U1nWnH9o6jeX0rStIqTSGQmR8AlVOeTtUYHtW7i o6vZHowlZci3O+8emPw5peg/DS1ZTLpRN9rEiEETanKo3LkdRDGEiHuHP8RrHDU/bSdeXyOjFVVR SpRPLdldkadjglVu7mpomkHXNY0zRxfWlm17MIVu75ykURPQuwBIGeOlKb9muZK7JjUcj658Vfsk 3eleDIbvwxqF1rnjVZkMluhihgkjJwQgZhjA5BLEn9K8ynmUPaWmrIpxufK2peCfFela9d+F73QL seILYgSWUMfnOuQCCNmQRgjkEivUhXozScdTFxlex0vw1tpNL1nxH4knieJ/Dek3dztdSpS4dfs0 YII4YPPuAPeP2rLEXqJU1szbCycJOb6HmKxnuck8kn1rvjCySOOVW7YeX9KrlJ5w8v6UcgucQx+l HIHON8v/AGafs7IfPqelWumyal8OtBsIZbeKW48SXUay3UoiiQm2tuWY8ADuTXDZwqyOxy5qUTvv hh8J7X4g+LtOvvBMnnaBoc1hLq8GtyBZJCWBlEQRSGT5GAyQSCK4sbipUqTU9yqNJVHeB+ocloWJ J5Y9/WvlZTbl5Hp2lazRTey68Uc0iWkU5LEcjbRzX3HaJnyWJB3KMEcg1Tck1Zij8Q7XdOzefa0B VLuNZ8jgZI+bn/eDUqDm01Fao1xHK5c3c+QPCN3d+MPjN401XwtcQxeErKGK0vXWIMmpSgkA8EEN nzCHwchOetexWXscPGM/iOKNTnZ7o2jwQRLBb28cUCDCxxIFVR6AAACuPV6pms9jEudLPPy1SZmz nbrTM5+WtExXKd3pn9oaYxxm8sE59ZIM/qUJ/I/7NSpeyn5G6/e033R59d6bjPy966k9bHKnZXOW vNPxnirQjmLuxwTxWiHcwvLls50uIMeYh6EcMDwQw7gjg0pRvqXCs6eplavpcUYivbNT9hnyVB5M TjqjfTt6ilB9GbS9330cnPbdeK0tygmmZcsOO1FuYtSSEjRJ4xZzsFxnypG/gJ7E+h/Q81lL3TaM uYof2c6GRrtTFFGSrEjkkdgO5pJ3LehlXiC5LZXavAUDnaBwKnlLjM55o2jZkYfMOvpSOmLuKBx6 +1NhcfgZ9KhoQ7b7fjTHcUDFBIuz2oKuLtNAXE2e1AXDZ7UBcNntQFw2e1AXDZ7UBcNntQFw2e1O N+eNu4naUHc+zbVP9Gt/+ua/yFfptOEXSSt0/Q+DnN+1evU+PtRX/iYX3/XZ/wD0I1+c4mCjVkfb UJOdKNyns9q5m+bVm7lfQNntR8XQSalsGz2p2SHqg2e1JpN2QtegbPanJcuwKQbPagdw2e1KwXPY /hCmbnXP9yLP5tX1PDcVKU7ngZ7O0YXNP4uLjT9HwP8Als//AKCK24iioxiZZJJylKxzPwmUnxHe /wDXi/8A6MjrgyCKlWujqzm7pWZ3nxTTHhhf+vlP5NXsZ7/u0jzcolaqkfOez2r4i6PrNUGz2oaf QXMnuGz2pXdtUOLTWgm0+9PdaE3cXqOwaPkF79RMH0qkkw91DtvvScY/EOzDb70Ntq4rvqG0UgDb TTs7g9UfWXg29Go+GdGuGOX8oRuT3KZU5+pXNfoeWSVfDxlY+Jx16VaUbnz/AOPrA2PivVoyPllc XAI77wGP6k18hm1HkxTTPpctq82GTLnw301r7xRaS4zFaK1w31AwP1INbZJhvb4ldkZZtiPZUPU+ jdT05dU0y/09h/r4XjBPqQQD+B5r7TE4aNWg4pHytCvKnVjJs+OpI3id45ARIhKsD1yDgj8K/Np0 +STgz7uEuenFrqe9fCKwMOmarfyLjz51iB7lUGePbLfpX13DmHTpyqNbnzWeVrTVNMofGK8zPo+m K4OEedgDkAEhV/k1c/ENRRcYJGuRU3JSk2eJ7cEMASoPfvXy1rH0Kk5XH8HcQTg8sT1x6Ua9BNp7 iFDjeFwp6ZoTbB2juyTO5mZM7yOS38I9qtqO5LuiJgoPyZI6ZPeha6Ev3SaMYwYwTLySx6KPWjZX H5PYGTA3pJuIbBJGOeueetPla1fUSdj1X4RNK3iyWS1TZKLWVmkz9wEqCQT0/nXvZA5fWLRPEzuV 8O7HovxZjhTwvIsMvm/vo8vt2gnJ6ZOSPc19Dn8f9kd9zxclf+0RR81gAKksimWRicA8jA4Occ18 F7vU+0tJbBcLzHuVVlIO4JjHXjgdDik0+grpEoa4lQyZRFB5k4UscevUnHpT99NWQlKMpWb1O4+G qRDxjp4icv8Au5ckjAzsPTn+dezkSUsXE8vOW44WR7x8R/tMvw91nzbtY7OPylSInG8iaPOAByRn kmvqs7ilgpnzeUSvjIHyY8MRjaSBmIRgDvAHXPIA7cV+eNaH3SkTRhntlijmWPGfMDNtBBxg+/pQ n7om7S1RGxjjgaNZd7uQSMHCke569cUN+6C1loiOKQx5Xy1dSc7WGRkdDxUqT6oco9mSgXkiOiRE R5OQi4HPOPWrtN/CjP3V8TuUwuSBwM8ZPFZRjrqbt+5oT/ZowwDXMeMHlctg/lWvLDqzJVKijpET ybX/AJ+v/HTS9nT/AJifaVf5TcvIkjeIrH5TOu5ojn5DnGPX35r05w13+R4UKjt3J5o7WKURmynZ VyvmKx/eYHUcYrS0UtjNObe5XNmPtslqsuFQk7/QAZP44qXD3ty3VfJqhQzMs/2TU5mJQkxuCC6g ZPOSOBmm1Z7gknuZ1us2yWSOCGWIDB84gDI5+Ukg5HtUpGpm6hsjKIbRoJgMtliQ3oQD0B+tRJm8 EUzJ8kaRXMTqMt5U67QD3GT9fWoZvBGG92xuTPL2BGUGQnGAQPbtWbOuETMu5VeJ2kkSSRiNrqMN 756dqm99zpitTNbKqIg6MxwTGwx1GRg1CWp0IzM/vcriPByAx4GOxNZ37GyR9W/B3wANKs08T6pB t1S9QmC3kH/HtEcjPPILg/UDjua6aFO+p81nmYWXsKb9T6y8Emz0W9fxnq9xdW2haAyTyT2hdZLi 4P8AqraNlGQXIO4jogYnqKjG1ouPsbXbPLy7CVJv2zekfxOy/wCEw8K/FBm1fxCf7N1uXEaa3pkR e2lCgKqy25IKhQoUNGeg6VnTozw6Sou8RYmUcRP/AGj3X3I9Q8F6zo9r/abxR3mhnJGq6c4ntyB6 kDMZ9nAPtW0MUm7Pc46mFqQTa1TPkv4ieKtO8UXNpBp9nIsVkXX7TI2DKDjgDoACPrVSXtHoexga Dw0Nepc8A6bZ+H7C9+J+t20c1ppMwg0exmAYahqZG5CynrFCP3r9idgPU1y1ryfso79T1qc1T/eP boedXlxd6le3eoahcPPf3UjTTTyHc0rsSWYnuSSTXXCkoRSXQ5KmIc3dlcQ+1bKF0YOavuei3/xO 8ban4bHhW81NG0vYsbssQWWRFxhWYHkcAdOaSo3ZzOMZTueeeT7Vso20XQpzbWh6d8NbG00651nx /qtv5umeFoBcwwuPlub9zstYj/20/eH2jY9q5cQm17Fbs3w8rP2z2R5vcPcXlxcXd5M0t3PI0s0z nmR2JJY+5JY12xppQSicc6rcnORD5daqFrMx59LnsnwJ1nwRoHj6zufHemQT6dKvlW91dKHisZyQ RIykEEdskcda48dTqTpuUTajVTP1lhjR0R42VomAZWUggg8ggjgjFfJN8rd0dq1K2o33h/w7bXWq 6xfWWnQJGZZridljJQDknoWx0GMntThCpWdoJhOUUz8z/if4o03X9I+IXi/RoWgtPGHiCC1tldAr yWtpDuMjAdN0kgyOvAz0r6XB0puVOEt4/qY1Kqp0pSX2j5p8r3Ne3Y8j2gvlVVh89xNnvRYXMHle 1Fg5hDFily2Ycx6roWjS654F0fRYkdpLzxXHboEBZgZIADtABOTgdPQV5uKmqcpM9Gg+eEUfrZ4c 8BeFfBdutn4a0SzskWJIHmghVZLhUGAZWABcn5iSe5NfD1sXUrzftD26dONJe6joGtunFc6vzcpa unds4Kbx/wDDuK7Sxk8caELt3KCL7dHncDggkHAOeOTXYsJWUbtGPt6bdjq2tAQCMENzkcgg+hrl T5XZl2jLUqSWQ9Kakk7jtqfInxm8Ga5Dd+GxdeMfEGl+BZNUlt7zVI7qSRbSC5QuQ4BAEaOm0bzg CXHQV7OBrwSk7e+zGrCUqd10NP4O/Ca8+H+o67PpHizTdb8EanFE8M0KhpmlUsAdykqAAzZwTnIx 0oxmMVeymtTOlS5Vdnt0+njn5a89Pmurl7uxh3GnZz8tWpEtHPXWnDnitkyGjEWB7G7iuo03bPvI ejqeCp9iCRTa9pDzRVKfs5XOc1/Qo7O6YQZazlUSwP8A3kPIH1HQ/StKM+ZW6omrTUZXWz2OCvtO 6gLXSmYnJXmn5z8vStEybnKXljjPy1fxj5ktGZcCRRmazu+LG5wrnGfKYfdkUeo7+oyKJK+xvSqX 9xnJ6lpktncTWs6/vY22nHII6gqe4I5B9KpPmCScTHj0q7vHYW1uzhfvP0VB6sxwB+JqZS5di4Jy 3Kk9rY2WfMdbu5H8EZIiU/7TcE/QVHxnQpKBSuTJqsZMpzewKSFHAdB1Cr2I9uopcvKaqakc5JH1 q9yL2My8tvMTcoJdew7j0qHE6aczHA4xUmxIBx047UWJuPA4HegLjtvtQA7b70rBcNvvRYLi7fai w7ibfeiwXDb70WC4bfeiwXDb71IXDb70Bc9F8A+D9N8Vf2t/aE1zH9m8rYLdlXO7fndlT/dXGK97 JcB9cc2/s2PHzTGPCqKXU+ko4fLRIxnaiheeuAMDNfbwpWjY+V57ts8K8deA9J0TS7jWbS4u3unn GUldCg3Ek4AUH6c18nm2VQoU3WR9Hl2ZTr1FTZ5bpmk32sXsOn6dbtNcyH7vYDuWPQAdya+ew2Hq YuSpwR7NevTwybkz27SfhHp0MSvrN5LPcHBMdudiD2yRk/Xj6V9VhuHqcf4zufPV86k/4Zr3Hwr8 LSoRFHcQNg4eOYsc/QgiuupkGFkvdjY54ZzXT948r8U/DzU/Dsb3sDi80wdZVXa0WTxuXJ49wfri vn8fk08J8CvE9nCZpHEP3nY8/K8+leKklotT1pPmXYTb70kguG33qoRUpJEylZNn1f4b8F6Z4Xe7 ewnuZGuFVXFwynABJG3Cj1r9BwGXQwWsOp8ZjMdPEWUix4j8J2HiiG2gv5biNIHLKbdlUkkYOcqe K0xuAhjI/vCMLjp4aXunmfgTTIdJ8fa/ptuztBb20iI0pBJAki+8QAP0rw8soxw+OlCGx6uYVZ18 NGbO+8ceHr3xDpNvp1gE803KMzyHARQGBJ78Z6CvXzTCSxsfZ0zzcDioYZ88jC0/4T+H7aJRfyXF 3cEfM+7y1z/sqOR+JNclDh+hb39Tpq51Wl8Ghna58JbGS3kl0GeSK7UFlgnbcj47AkAg+5z/AFrD F8PRs3S0N8Nnbi7VdTwme2lt5pbeePZNExR0YYKkHBB+hr5OUZ0W6U0fQQl7TWBe0nRtQ129j0/T oDJcPyewQDqS3YCtMLhquLn7OCJr4mOHXvnt+lfCPSoI1bVrua5uDjKQny0B7gcEn0zkfSvqsPw9 TX8V3Pn6+dzf8NWNaf4V+FJU2xw3MLHPzRzEn64bI/SumeQ4T7MTnhnVdP33c8t8VfDnUfD8Ul/a Sfa9MXlnC4eIHuwGcj3H4gV4GYZNPDvmh8J7GEzWOIfvbnnO0V4mifunrufMrvYUACgQoHYUAfQv wkuxcaJf2OcvbT7h7KwyP1DV9tw9WvQcOx8pnVHkqqfc534v6cYr/SNSC8SxtCxHqpyM/UM35V5/ EdDlnGoup05DX54ypvobPwh0wR2OqaqyYaaQQoT1woySPYlh+VdXDlDlpyq9zDPK3PNUux7F5anI Xkg4xnvjNfUNbo8Dmuz5S8d6Z/ZnirVIlXEUr/aI+ww4yfyJI/CvzzNcP7HGSSPtcure1w0X2PoP wLposfCejRlSHkj873YuS3P0BUV9hlNH2OHjE+WzOp7TEtnhHxIvDd+LdQTJMduEgB+gyR/30TXy ed1va4uUex9LlNP2dCJx9raXF9cRWdnE0tzKwVY0BJJ9q82jRdeqoI76lVUVzs9t0D4Q24WKfxFe SFjgm2tcKF9QzEHP4Y+pr6rC8OrevI+cxOfN6UUdXJ8KvCUqtGkU6E/enSZvlHphsj9K9CWQ4dq0 YnBHOsQndyPL/E/ww1DR4pb3SZ2vbBASyFdsqKOckDhgO+Pyrw8dkNTDrmo6o9jBZxDEO1bc8zCj BAOE7uRySOwrweRKXK9z2uZ8vMtj6CtvhN4d+wxTyXWpO8tusuI5YwMlQwxlCcc9K+wpZBRnSUur PlamdVKVRxlsi1ofwk0mGwik8RtM97IgYW8T7VjJ7DBycdyTz2FXheHqdKnzVtzOtnVSpV/d7HMf DW1sP+Fh6laaeZDpqRTrGGYEuFIxzjvjjiuPKUoY7lp7HXmcnLCJs9F+LBdfBlwkyJFF50XlwYwx JJIOcZ4A6mvY4ht9WZ5WSP8A2pHy1B5jMIUkKh+MDJznsAOSTXwEYSnNU4rU+zqSUFzyeh7b4Y+E Et7ai61sTp/F5EH3wOoDEggE+gyffNfVYDh7mipV2fO47PeX3aB3Fv8ACXwbNFP5lpdkxJn91ckO 2SBkZBHGeeK9R5BhV7sVqeYs9xTlzXKGhfDe98M+IrbU43STRwkiKZAEmicqcZBILA9NwH4VhhMm +p4yM4bGuIzVYzDOMtze+I06J4C1u2ltxKA8To2SCCZYwc46ggdK7M7jbAzObKP98gfKTpcNCMxh IU7YCliOO/JNfnjXun3a6kEQh3Hzi4UdAgGSfxpJe6PaWjHkw7HWO3JPJ8xiSQO3AwKGvdDeWrGQ +YJB5LYkPAI4+vPapjz9GOfI9ydoWZmE12m4Yzli2c+mM1o4uW7IjJLZFYxMJfKPD7tvsDnFSo9y 3O8dCV0to32kSnBIboOR6fjVe51M/fa0kOxZnnZJ/wB9j/CqtD+Un3+5em27ztlMoP8AGQRn8+a9 CS13PFg9Ni8kmwoI9YZcDGSHG0egxW0dtzBu7+Ez42YXClJlRwSRKxwPqc56+9ZJ67ml7ra5NdS3 AimcT2rBiVZ49oY54IGADg1cnpuOCu9jMUytaMrWjSw78h1JBRjgHpnOfes09zoSMm9uEJgh8p1h iJ+WQ/MQSCc8D04qJu9jpginczQyvIXe3a32nG1drKOSAMAEkdOamR0U0c8rGNGnEzoTlRsGewPP oDWR1JGVdkllXCNkZDIMZB9fes5HTBFWSUjo33BgLKOR9PpSbsjZI9K+E/gdvFesNf3kAbQ9OdHn 81SVuHOSkQIxydpJ54APcgEpR5/d6dTlzHF/VaDfU+6vD2h32u6pp+jabCJL27lEUa8KAT1LHgAA AknoAPQV11J+wpux8LGMsVVt1Zf+J/jnRdIii8H6DKX0XTLd/scq8fb7kkLLcsOoLH7meiBR1Jrl owv78viZ6fLOpKNOD92J594K8T6Hpnh20tr26YXsTuoto0MkshLEjaqgk53V0x9xamONoyrVlKGx 7C3j1vAFvFq6ahdaffypmO0hYrLLkcoyg4x2OeKzlRhiVZrQwoKrQqfu/meP6FqejfEzxHZaDr3g KxGrancELq/h6QaZJCDlmkmiCmBlRQWdhHGcISWrCtRnhoN03ZI+kpVqdW0Z6tmv4x0jwj4yn0zS vh94+0xNB0OH7Fp2ka+H02WUk5ln8xgYnkmcbuGyBsUj5aWGc6SvXjqwxHsqulGWx5nrXw38ceHl M2q+F79LQc/a7eP7RAR1z5se5ACPUiu6niKE3aL1OGrRqwXvI45EVxlGDD1U5rpSvszmuuqHiD2/ GrUL7oiTXRimEKCW4AGST2qly3btoS3omj1Hxtbt4b8PeF/ACrsvI0Gs6uvIP2udAYomHrDblRjs 8sorjw8fa1HV6dDpxMnSpqn955h5B9D+dd/Knsee2xPIb+7VKLJuurAQdgPqKdk1aRN4rY9c8N/G 74oeE9CHh3RvEjJpyLshE8Mcz2w9I2YEgDsDkDtiuOrluGrO7RpHEzjojzbWtW1rxBeT6nruq3d/ fSkl57uVpGPfGSTwOwrqp4eFGLilsZqTqNSZ2nxCt20zTPh74VXg6fpC3s6D+Ge7YykH/tmIT+Nc +EXvTqLqdWKly040n0PMzBz0rvPPGeQ/cUAJ5J9KaV9hJp9BPK9qTUVuPVbMmtrC7vrm3srK1luL 24cRQwQqXeVycBVUckk1NWoqUHKWhVNe1aitz9aPgj+zvp3w78KWOoeI5I9S8Ti/W+QGMrHp0phC kICfmYAsN5Ax2Hevz/NM2nXm40tvzPrsLg44akpdT6BMHHSvHcuaNzoS5tWN8jcRgZPpVpttRhuQ 3y77H5nH4LQ/EP8AaG8TWmgyW174H0/UY7rVb62jjighDYZrdQoKsxYMvA5wxPc19j9e+qYFRrL3 +h48KHtsS5dD9IxZxxIkUMapCihURRgIoGAAPQAYFfH8ylJ33Z7CX2X0IGtunFVdJB8KsWLOxS6h 1TT5EDpcW5YIwyGZDuAIPtuqZTtJNG1GN4On3OVj0q1tUZbW1ihRjuIijCgnGMkADJrbnbOV9inN Z9RtqlIhrlMa4svatFMmyRhXNiDnitFK5nJXOcu7Dg4St4SuzOS5kUXsBf6Vc2TDNzZZnh9WjJ+d R9PvD/gVTflnc2VqsLdjze+088/LXbBu2pyPXS5x99p/U7cVrF+ZF1Dc5iTRbu9Zls7OWc9P3SFg PqRwPxqueC6lRpzl8CMS98Lm2y2qX1rZ+sRbzZf++FyfzoVS+yuaezt/EdjOuotKurJ/stm95qWn x5V7wbRLEDydqnnZnjJ6VNnB2fU6lOMo3W6PONSuby7QJNL+5H3YkAVF+igAD8q3hDk0MHVvqjl5 oOTxVWHzmcVeKRZYyVdCGUjqCKlo1jMZf2ySxrfwIBE52yIOkT9SB7HqPyqFobN6XMN46b1KTs7G FeW5jk8xRhHPOOx/+vWbR0xlcqgf/rFKxTZIACKQx4GaBXHbfoPpQIUL6UAGz2oHcXaaAuJs9qOU Lhs9qOULi7TQFw2mgLm3o3iLWvD/ANp/se88jz9vmfu0fdtzj7wOMbj0ruwWNxGE/gu19zlxWEo4 inzVdz7AtwZLeGRuWZASfcjJNfosLuim3q0fDVOWNVx6Hyn4i8VeINVa90y/v/NsVnO2PyY1xtJA 5Cg8fWvgsZjsRiHKjUloz7LBYTD0VGpy6nt/w38Nw6ToEF+0Y+3X6CVnI5CHlVB9Mc/U19PkuD+r 0PadWfPZri3VruK2Rz3jr4hXOk3smjaGEFzFgTXLqG2kgEKqnjIzySD6YrjzbOJUJunS3OvL8tjX jz1tEcBp/wASfFVnOslxeLdwZ+aGaNQGHfDKAR+f4V5FLO8ZSknUldHpVcpoTjypan0Xo+oWPiPS IdQgQNa3KFXikAbb1BUjvjkV9lQqxxlDnPlq0JYSry9j5e8Y6CPD3iC90+If6KSJYM5+43IHPocj 8K+EzPC/Va0ofcfZYDErE0lI5bZ7V5x2XDZ7U07O6Bu6sfQ/w08R634hn1ZNXvfPWFIyg8uNNpJO fuqM5x3r7PIsdWxbkqjufLZvhqWGinTVrmh8Stc1fw/ZaZNpF35EkszK58tH3AAEfeBA/Cts7xlb CRj7KVjHKsPTxEnzq5w/wuu7nU/GGq315J5l1NZu7yYC7iZI+cAAD8BXl5HUqYjEupM9DNo+yoqB 7Xr2qwaDpN5qtwpZIFyEBwXYnAAPuSK+oxlenhKLqvc8DDUfrFRQPnOb4keLZLv7TFfpHHuysCxI UA9OQSfqTmvi/wC2sTKfNzaH1MMrw6jypan0V4e1Ndd0XT9WEYQzplkBJCsCVYA+gINfZ4LEPFUV No+VxVL6vWlCKPnb4l2cdt4uvzGoAlSOVgBgZKgE/iRmvi87pcuLly9T6zKqr+rKXY9i+HHh6HSf D1tdtH/p1+omkcjnYeUUewBz9Sa+lybBRw2HU18TPAzXFOtV5Uzj/GXjTxD9vuNN8P21xBawExtc pCWaUjg4JBAAPQjk9c1wZlmGIVT2dBaHbgMFRUOeucZY+KPHljOswnvpwDlormIyKw9DkZH4EV5d LG5jSleTO6rhcDOPun0L4f1RfEWjxXkto0LuDHNbSqflYcEYI5BByPY19hhayxlG9RWZ83iKf1Sp aDufM3jLQk0DxDfWEIxanEsP+yjDIH4HcPwr4bNMNHDYmUVsfWZdiPrGHTZy+33rzTvuG33oC56t 8I7zyNfu7Bj8l1bkgerKQQPyLV9Jw7VUans31PDzuHPT510PQfirppufC5ulGXtJ0lyOuDlCPplg fwr28+oOpQ5keRk9ZRr2fU6fwdpP9k+GtHtCMSiESOO+9ssfyJxXXllB4fCxucuPq+2xEpI5rwZ4 i/tjxH4us2kynniW3GeNi4iJA9wEP41x5djfb4iojpx2GdChCRgfFjQXu73w7dwLiS4f7ETjoScp 9erVyZ7hXKpCa6nTk2KShODPZI4oLK1WMtstrePaCeQqgdfwAr6FL2NG3keEpe0q38z4v1C4N/fX t64O+4leTB7biSc/nX5piKjnVlM/QKFJQpo94+EvhyG3099fuEzcXTGOEn+GMHBIPuQQfYV9bw/g FCl7drc+azvGuc3SRq+P/Hcnh0ppOnKkmqyKJHkk+ZIEOQBjuT/nNdGbZs8G+SHxGGWZbHEx55aI 8itviR4whmWR9UEsZfLRSwpsb8AAR+BFfO088xkKl+c9qeU4Rx5VHU+i/Cev2vi3SIr6BFgnQmKW AnJDgZPPoR0P9c19rl+Ljj6XO/mfK43DPAVOVHz/APEjw9Foeuq9rEFtL1TLEi8BGzhgB6A8/jXx +cYL6rilJbN6H0mVYt4jDuL3R9L6bEW0vTmBZ5BbxlyBwPlAAz/WvuMKr0ot9EfIYl3rNSPn3xj4 419fEOowaXqUltb2kjQAIQMleGJyDkk5A9O1fHZrmmIVd06T0Pqsuy7DqhGUlqQfCgbvFbMuTi0c biMZIK0uHm3i7sM8ssNoerfFRR/wiEjxxs83nxGSWTkKST/nJNfQcQf7qzxMjf8AtMTzD4U+Hob/ AF6TVL1BLa2AV1A6GQkgH8ArH64NeDw7g3WrurL7J7Ge4p0KXs11PfPGfiu28I2Q1OaYTys+20tL c7QzDkFhgAADk9T2719TmONjl9Jy6nzWX4V46pydEfNcnxN8avem8h1f7MxYsscMSKiAnOACCSPq TXxlTPMXOalzWR9ZDKMMoOPLqe0/D/x3b+JXn0/WEaXWo13K0J2pOOhPOTkErwOtfT5Rmjxl1N2Z 89meWfU0nFaF34iCUeDtZELFZD5S578zJn6V053FfUJmOTy/2yB8qiOB5Nsk7u7EAOo4ye5J54r8 55dD71SEgQJcFXALDIUHkbgDjIPvUpA2iyn2lZMzzIkYYMybgAw9AB7DpVkXRSidYpfM2kpyMd8E Ef1qE0aPmH/6GrfdlcAcAkLz+Gaq6J1IXdnlaXGHJ3cetQ277GijGxMZt7K32ZS3XOCdxPrz+NaX dtjPk13H+bL2tI/+/NVzz7EcsO5pXcaJLECipIVHmRp0U57YzjivUnHXY+ei9C4wxMAlvam36Anb krnqec5xVJabEJq+5nQpC9xMqosgAJjjckByDwCcjt71lbXY2W29itcxKLeSR7RYXBwpViQ5zgjB J6CnNabGtN+dzMeOOOGF2+0Fn5LRYwMZ4x3IxnrWdrWOlGTcrILrb5mWUBvMk5wMA89egPSs2r3O qmZF45ZHbbA3zffj4I/AY4P0qJHTTRkF9i/fdCTycZUgVB1JGa0kjzFvvkAjjjjpx6Vne7OiKHWt ld6rd2elWELz6hdyrFFEBglicAZ/Uk9BzUz8jSOmrPtrRbPSPh54e03Q4WM8seWcxABriVsF5COw JCgZzwFHOK6qMORaddz4/MK1THVny7I+gft1x4D+HFzr09o1p4t8R2TGCCVgZLHTm4DsByrznjB5 EY/265nP6zV5V8MfxIVH6hFR+1L8D5W0rTL3xBrFvbAPPc3D7pHZwDsHLEseBgBv5V2txguZm7la LtpY9fkbwz8N2X7FZTXWuSoWjlmIJVTwMsAAB7KMnvURg5S1OFValV2TsjyTVb++1u+m1HUJN9xI egGAgHQAdgK6ox7m8I8seU9HtIB4I8AyakRt8UeMont7YfxWulKwEsg7gzyLsB/55o3ZzXCovEVU o7L8TuUlhqb7v8Dy4QA8EcHqK9Dl7rU4HNbpm3ouua/4ckEmg63f6cwOQLSdo1z6lQcH8RUyoU5f Ersca0o/C7Hat8StX1I7fFOg6B4hz1n1TToxOfX/AEiPZIM+zVisFy/w3Y2+uc2lRXGG++F2okfa /B+s6NIRy+i6qJ4lP/XK4R3I9P3o/Gn7GvHedyXVovaNjsfAfgT4ba1r8Wop43mbQ9GiOq6jZ65p T2u6CIg+WzxPMhDuY0OSCQ5wM8Vz4rFVqcFSdOzfmb4XD0qsnPn0XkYes+BfEnivWdV1228ReGta v9RuHuJfsetWwld3YscQyMknU4HyVtTr06EVTatY56lCVeTkne5z+ofCz4h6WN974L1dIvvCVbZn Rh6grkEe4rohi6MtjGWFqx3Rx9xpl9aZN3YXMBHXz4WTH1yBXR7SD2ZzShOO8SkFRvusp+hrS6ez MuXyHeSfSjVbBdmv4f0KfX9e0TQrZM3GoXUVqg65LsFA/Ws61R0qbmy6MHOooo1viBqEOueN/FGo 2rbrBrt4LVh3t4sRRf8AkOOOpwkPZQjzGmLmqtZpdTjvJPpXUcw3yR6UAN8k+lPfYlqPRnSeHPA/ ivxfJcReF/D19qRtygne0gaRbcOwVWkKg7QSeprkr4ylhl+8NqOGnVeiP1E+GP7NfgL4balaeIrc XmpeJYEBivL+QEWzFcMY0UBQeWwSCR2NfC47OauLvF6RPpsNgadJJtan0o0Y/seH/r6f/wBASvC1 lK7PVkk6djN8oVpfWxi19lHw3+1n8X9Q0YL8MPDsl1Z308SXOo38bGMtAwIWKNgc4JBLH8K+pyDL VVvXmeLmeKcF7NbnrP7L2haLpvwf8PXmkwr9o1Jpbi9nxhpZxI6EMe+0DaPYe5rz88qSeKlGXTY6 sAl7Bdz6CMPoK8dtX0PQa0IWgqoyu7ESVySy22t9aXDn92kg3/7p4P6E0mtGy6crTTKGoWBtbu6t 2HMUhU/gSKuE7mdaPKzGltvatuZGU1dGXNagnA5PYVakjNwZmyaTdznbDaSuewVCf6VaqJAqLZn3 PhXVdu6W08hD0a4dYh+bEVXtoRXusPq007NGKmkw6Zdw3kur2KtEQTHGWn3g8FflBBBBIOTVynOU bxQ6cYU5K8tjmNe0Tw/pt1In+n3UTgSwhdkKGNhkfMdxOOh4HINaUZ1pb6GdenTpO9rnBXs9rb5+ w6JZxkdJJ1M7fX5iQD9AK6o0+b4ncwlWhFaRscJrF3qt6rJPeymIDHlodigemBgYrohTpx2MZV6k jze+sQN2ExXSvIx5n11ObPnWF1DeQYEsTZAIyGGMEEdwQSCPSnKPMrFU5uDuYXiHS4oJo7m0UjT7 tTLDnkqM4ZCfVTwfbB704T59Op0TSpq62ZxVxb4zxVkKaMaeHr8tFjWMyvA628jxzgtayjZKo9Ox HuDyKzkrG8JdTMvbN7Wd4XIOMEMOQwIyCPYipiaN20MmeBZEZG6MMZokjSEjnXQxuyPyw4rM6U7j gD2oGSAZ70CuP2e1ArjgO9AXF2+1A7ibRQFw2igLhtFAXDaKAuG0UBcNopwu5LQio24NM+4LSP8A 0W2/65r/ACFfqNOK9hHrofn83y1G13Pi7Ul/4mOof9d3/wDQjX5rXS9u011PvKM70Vd9D7I0VUfR 9JeLBja2iKlemCoxgV+jYRctBcu1j4WvJxrNy7nyN4nimj8R68lxnzvtkpYnvlyQfoQcivz7MOZV 5RktT7XBzcqC00MHaK4Yr3bM7Ho1bc+mvhHBMPCsrSA7Hu5DF/u7UBx+IavvOHYSjQblt0Pj88nG VbQ4H4xmM+IdPVcealmA30LvgH9a8XiF/vl3PTyS6otdzyPaK+dse7cNoosFz234MoDda/8A9c4v 5tX1XDKblOx85xBJyjA1vjKmNN0X/ru//oIro4juoxuYZC2pS1OU+DyZ8TX3/Xg//oyOvO4eV67s d2eO9NM9D+LKsnhVQDjdcxg+4wx/pXt56uXDM8rJX/tCbPmTaK+D5YydmfY3cZNn1R8MFJ8G6dk5 xJKAPQbyf61+g5C74JJs+Jzd/wC1Sdzx/wCKq48XTj0gi/lXzmdq2KdvI97KJf7MkfR2jKjaPpLR 48s20RBHTBQY/SvssHZUYzXY+WxOlZnNS/EPwbDJJDLrJWVCVZWtpsgg4IPydjXHPNMCpcs5a+h1 Qy3G1I88Vp6jP+Fj+Cf+g1/5LTf/ABFR/bOXOVr/AIFLLcba/L+If8LH8E/9Br/yWm/+Iq1nWA1j GRP9k4v4nD8Txf4k6zo+vavZXmjXPnxpbCN32OnIdiBhgD0Pavls4xVDE1FKi79z6DK8NWw1Nxqa HnO0V4p69x2z2oC50vg69Gm+J9Eu3OEW4CMfRW+U/oxruyyq6WIhI4sbD2mHkj611PS4NVsLrT7h cwzptYD8/wBCK/R6lJV6fIz4WlUdCpzoo+JdQ/sfQNWvx8rwQMUPTDkYX9StY46qsPhpTRvg4e2x Ci+p81fD3UP7N8W6W7NiK5Y2757hxgD/AL6218PlGIdPFKXRn1eZ0va4e3Y+pr7TLe/FotwM/Z7h LhPZ1OR/M199UorEas+Lp1XQukYfjm8/s/wnrdzuw5hMSnvlyEGPpnNcea1PY4aT7HTl1P2uJij5 A29Qa/OW+b3j7y7UEfXngFUk8H6CY8H90QcdFIYgj8wc1+jZPrgoWPg8z0xUpM+ffiRFOnjLVxNk BjGyHsV8tQMfTGK+PzyM4YyVz6nKXB4SLvqcPs+gwK8hNWSS1PT2vc9/+CiTm38QSdIS8KhyeAQH zj3IZa+z4YjLknE+T4hnFzgRfGtYgnh5QDuLTlScZxhAT7AmlxKuWVJPcMhfNGpJbHtmkYTTNJKN keRFtjTudoGT+dfSYZXoKL7HhYh81VvzPjDX1K+INa3jLC7myM99571+aYxctd66n3mDd6EVY9D+ EEQl8XNE7kE2kmAgyF5Xr/WvX4e/3pHmZ7/ux6d8VWRfBc0LqxxdRMCp6nkYNfRcQL/ZWeDkb/2m Jz/wbQNpuuZEaOk0f7scNgg4OPqG61w8MxTjPlZ2cQytOFyr8ZY59vh6RIx5KecDKT91jsIHPAyB x+NTxQptQa2Hw5KK9oup4RLG3+t83zOcFueuPevjuVbs+qUpdD034VpdHxppT2dwsECxSmSQHBwY yDuxkn5iK9rI4zljE0tDxs8ko4OSb1Pa/irKG8J63PE+Sv2f58Y3ESxgnB6ZxX12dJ/UJny+Su+M gfKCiclWjgSIN/EwABxznLZr85toff3KZQhypYHBxkcj60rFOTJgLRG6SuMdOF5/DNUJNkB27sgf L2B549zxUJvsU3EvD7WWUx2qKSDtxGORwc81evYhuJSkD73Mgw+eRjHP0FQ+e+xopxsWyt6fL3TY ycKC4BBx6duK09+xl+7b3HeTe/8AP0P+/v8A9ei1Qm9Ilm8nePs6SLH0+cgnP4Yr03vseBF+ZL/o +R/oUjfLnAc8n1GB0q2tNg1vuZ8e0yYeFpF5+RSQfzANZLTobJeZVuGiCALA6P8A3mbIx6AYofoa 0/UoGeNFXE9whySdhGM+oHFQvU6EvIxXlPnM4m29fmkGc/Uc9ay6nXCL7GVdynZtHl4Y5OzgnHqK ls66aKUszAozLKAABgcqw6dO2am5vCJkfIwf5Ruz0zjg+lZpJHQnyu56n8MNPvIdSn8QxyPF5KNB C+ASGcYbaSOCAcZHPNa06PM7nBmGJUF7JdT6d+Gug2d5r51nWcp4W0CI6jqco6tEhAWFT/fkdliX 3enim4RUY7yPKw8VJtz2R02qfFO58S6nq2s6/pURuLp90dtDjyoowMJEAQQAigAYHatKWH9nCyPO xCdSrzLqQeAbm71DxHq920MKRTQDzBGqqEwQEUDg4POcenNXUhaKFVk3RaNL4lXoEOn6etpGWmVn aWWP54wGAAVu2cc06MLyMcPeMWcb4J8Jx+KvEVppt3cfZdIjV7vUb09LW0iUvLIfoikD1JAp4ip7 CDa3O7D0/by5XsN8X+IH8XeIr/Wzb/ZrN9sFlZDpZ2sYCRRAdBhAM46nJ708PQ9hSsZ4jEe3k32O bEI64rpsc9x6wgdqpIXML5XtTvysnmuL5XsKm75rg59D0yWM+G/hjDAAF1TxjdebIe66fbHCj6PO SfcRkVxqKr4lvpE63L2FFW3keZm3DDDKCPQ813WvPY4ueUXe5csLzUdJbfpOo3di5Od1lO8Bz9VI NKdGMt0ONaS2Z2MHxM+I9vgDxpqk4GOL6UXecevmh8/jWP1Kg94m8cZXW0i23xO8T3AA1Sw8Paln GTf6NbndjHXYqdcc0vqUF8LsP67N/ERnxpo84P2/4Y+FXJ6myims/Y42ucUvq81tOwfWIPeFzu/h 3rfgUa7ea6nw5Nhc6Hp93qa3NnrFy4WRIiIiFkyATM0YB7E1x4yjiOVU/a/gdWDrUVJ1HT28zgFl +E0igP4d8WW2McWmp2zAY4wPMhJxXXGGI5UnI5XUw8pOTiIbP4USH5L/AMWwD0litJifbgLj61Te JhG9rith5dbCf2H8MZOF8c67Aeu5/D6Sj6YFyv55/Cj22J5b+z/EPY4Z/wDLz8Bp8M/Dx/ni+JN0 E9Ljw68bZ+guGGPxp+2xDS5qX4i9hQveNX8D6x/ZU0X4T6fr2rhvH8d14snAWxhmtp7LMQHzALvK SEnsSSB0FfNcQ1sTOEUo2gtz2cspYZS/iXfofoF9gsOn9qx8f9Mnr49SlHRHu+zprRMvtY2f9lxL /aMe37S53eU3XanGKyjOXNZm7pwdNJyM/wCxafjnUyD3H2cn/wBmrXmvK6Rl7CC2nqfIP7VHwZ0b xRp1j4/ttauYLnR4TDfC00s3Uk1sTkMFEik7DnPPAJr6TIM0qUJuhKOjPIzDAQrL2qqbeRyH7Pnx f+Efgzw/F4E1jxzqG1LmSa21C80T7JAiPglGYTuQd245IA55NdGbZfi8TV+sQp6ephgcRhqXuuev ofU/jD4lfCzwNp8Wo6/4rbFxGJbe2tI1lnuQQCDGgYkg5GCcD3rwKGBxFebtG1j06mJw8NXPU43w j8T9Z8ZXcP2H4QeJLPRHchtR1i9hsQqggblQxs7Eg5AAx/tV0YnAU8Ov4tpdrGdOvz7wPaXGjgf8 eNy+f+ekwH8gK81uWzZ1p0vtQLerzWLSW92NJR2uYVk3vM55GVPAIHBU1NL4bXLrzo+7JQ3MB7xV /wBVpdinuYi5/MmtlHTcwc7SskUZ9T1EAiOSOIHtFDGv64Jq1CCIdefcwru61KYESahclf7vmkD/ AL5BArZKCOedWo+pytzaAlmIyx6k8k/jXRGxzybfU566s85wK3izK2pUvbIahoWdubnTH2/WBzkf k386IS9nUu/tGkv31K38p5nf2X3uK7Y+6cLepxd/Y/e4reJm2cTf2XXiuiJFzi76z5Py1otNRXvo ULW0/tG0utCcDznJntGPaUDlM9g6jH1ArOcfZ++ddKftFyHnF1b4LZXBHBB7VvF3Rm+3UwbiDGaV tTRVOZWMeaHrSaNYy5R3lfbrJoDzd2oLR+rx9WX6jqPxrKSOqD5jnXjqrXFcxdQtwAJlByDhsenY 1DVjqpyM1RzxUmhIBke9AEuPuigVxwHP1oC47b70CuG3P8NKwXDb70yrht96AuG33pWC4bfeiwXD b71cNKiIk/cbPuizj/0W2yMjy1/lX6jTjy0dun6H53N3qtX6nxNqa51LUPQTyf8AoRr8zxelR97n 3+GlanF9D6J+FviaDUtIj0K4kUajYgqiseZYs8EeuM4IHbFfZZJj41aSo1N0fLZxg5UqvtIbMm8b fDSLxJOdT02eO21QgCQSg7JgBgFiASCBgZAPHarzLJI42XtIP3icBm7wi9nU1RwmnfBnWZLlBqt/ awWgI3G3Jkdh3wCAB9SfwNeVQ4bq816rsj0q2fU4xtBXZ7vDbaX4b0cRAra6XZR9SeFAySSe5JOf Uk+9fVRhRwFHlTskfNylVxVW71bPkXxRrT+ItcvtVZSscjhYkbqqAYUH3wMn3r86zDESxFaU+h9z gqCw1KNjn9vvXFY7LoNvvRYLnt/wVTN14gOP+WcXP4vX1fC65pVD5riJpRga3xoTGm6If+m7/wDo Irp4ljaMDDIJe9I5P4NpnxPf/wDXg/8A6MirzuHVbENHdnjvRTPRPi6mPCkeP+fyP+TV7XEKaw7a PJyVp4lI+YtvvXwVr6s+zTcny2Pqv4WR58F6ef8AppLx/wADNfoeRK2ETSPiM5XLi5I8d+K6/wDF XT/9cYv5V8xn8f8AanJbnvZPeOGjbY9T+F3iODVdGh0eaQDUbBdgQnmSIfdIHfA4P4ete/kmOhXo +xb1R4+b4R0arqx2ZkeNPhZPqd9Pq+gyxJNOxaa1mJUFj1ZSAeSeSD379q580yKVaftaJrgM5WHh 7OqcVY/CLxXcTKl2La0hz80jyhyB7Bc5P1IrzKPDuIlL31Y9Cee0FG0Wddqvwas1sVk0zVmjuYkz IbvHluQMk5Ayg/Ou7E8Owpw5oytY5MPn05T5ZK6PBJYvLkkj3q20kb0OQ2DjIPcHtXyU4xjNwifT xbqQU5DNvvQO4bfegLoUAqQykhgcgjgginCyktSJR5otH27o92upaVpuog5FzCkuR2JUE/qcV+pY Soq9GM0fnmJi6FZw7HmXxjvxbaHY6YpxJeTbmH+wgyR+bLXicRV1CkqN9z1cjp81V1ex85RPJBLH NExEkbhkPoQcg/ga+Lpt0pxadj62cVODufbulXUeqaZYajHtCXMKSgDtkAkfhnFfqeDre1pxkup+ c4qHsKzhLoeW/GW98nRNM08HDXNwXPuqDnH4stfPcRzVOkqa3Z7OQUvaTdVdD5y2/wD1q+J6Ns+t b1se9/CHxLAsUvhi8kVJSxktWY43g8sg988j1ya+v4ex0Yx9hUfofL55g5W9rA7nxv4AtfFkUVxB ILbV4RtWYglXTOQrD2JOCOlevmmVRxyuviPMy/NJYN8stUeV2vwZ8RSz7by/sYLYfeljZ5Cwz/Cp UZ/EivAp8N15O1R2PbrZ/RUeaCuz3fQ/D+neFtKhsrYBLSLMksshGWOASzHgdB+XFfV4bDUcvo8k dl1PmMRXqY2r7SW76HzH8QPEaeJtfnntnLafbjyYXIwGAJJYD3J49sV8TmuNWLxKa2TPscuwqw2H s1q0fVmiLnS9OUHANtGWIGTgKOBX3eH/AIC06HxWIfLiGr9T4y8QoBretfLgi8lAHfG89a/NcarV ZH32DdqCPQPg/wDN4rkLPtH2OQHb1blM/wCTXr8Pf7zY8vPX/s1z1D4uRGPwnIyq6A3ERBbrjJ5z gV9BxB/u0nc8LIdcSkeT/C/xBbeH/ERt9Q2rpl+ohmmkOBGwOQ2c9iWH4181keN+qVrN2iz6DOcJ 9ZpOUVeSPozW/D9h4m0qfR7+BpI5GDxPGcPFIAQGXg56nI7ivt8dhKeNo2nsz43CYyphal1ueFXn wV8TRSeXFf6abYNgM7sj4zjJUKTn8TXyf+rlZVLQd0fTR4goyp2nGzPWvAfgOx8KW1w+x77WZwBJ cAFVRBg7VAycZ6knmvfyzKY5crzleTPBzLNZY9qMVaKE+LEU/wDwg+sSyQRxoRCAIgAB++QjOCef rRnUl/Z81cWSe9joK58jmONRGZWdmYBsDGMHPc5/lX57ZN8yPv3o0hs0SqY2QEK67tp6jkjH6Uhl xxMsi+Q0aRchH+UcY6nv+dUgKs5QT7lwcY3EdCQBkj6mgFsSSLDJIZDcEKxJxtJK55ApWEmQzssk gKklVAXJ4zgYzjtSb1KirIkl+zzSGVnZWflhtyBx2OeaprQiOjGeVZ/89pf+/f8A9elyruVzz/lN K7WVtksk6yg5AZR0I7dBXryjZ7nzkX0sPd3V1jkv5xIAAcZwpIGADnpzTe25S72KCRGOabdK6iMH c0ec9ccdO9Sl5mqemxm3R3QbxPKyKwBR+gJBwRz7VEl5m9PfYzpZJIzFF9rYOMYG3IGcYA/rUPRb nVTV+hz7lg0rEoMZBLDIyfQVktztil2Mq6/gAVORwUzz+feokjppmbN8obaHHbGQR+JFZnTBDLK1 mv7m2sYFVp53CKpHOScdfTvSjFyZpUkoR5n0PqfSdKt9J0+1sYFAigTaWA+8epJ+pya71H2cbnye IrutNs9r8WQ/8Ij4Y0j4fRDy9WuCmq6/2ZbhlPkWreghjbLL/wA9JWz9wVzUI+3qOtLbobVpexpq m93ueYrD6Cu9b8p56qcy0Oo8LalBoWoXGozRl3S1kWFR/wA9SQAfbjd1qKkL2RDldNGLO891NJPc SNJM5LM7nJYn3NaKnyWYm1HRHpskY8J/DiG2Uhdf8ZETzY+9BpcT/u0PcedMrOfVIE7PXEk8TiLv aH43O3m9hS5es/wPMhD7V6HeJ5y7jxD7UDHCLFNMTHeSPSpepK0RpaPot5rmraZounx+Zf39xHaw oP4ndgoH5kUV6sadO7NcPD2kjqPiLqFlqniu8h0qQSaFpSR6VpzL0e3gGwOP99vMlPvIa58JTcKa b3ZripqVR9kcP5XsK77qJyXvqHlewpJMbaDyqeq6kO3YPJHrRdhZB5I9aLsND0Dw1Etj4F+JGqkY a5Ww0hG7nzZjcMB9BZAH6gd687ESTr00/M7qPM6FS3kRaN8L/G2t+JLHwpbeHbuPVrmOG4ZZY+Le 2lI2zyEHATDZ65I6DNVWzDD0qfP2M6WCqVZ8tj1j4rfs3XHw00C88UjxjZXmlxypDFazQmK5nLHG FAJUkdTg9K87AZ4sXU9ny2OrE5f7FX5j5p8oe1e+5JvlTPKs09g8kf3aXTULK2qP0T/ZQ0L4axeH I9V0+5s7v4iTb/tqXJUz2ahiAkKnkKQAS68knBOBiviuIauKnVcZL3EfTZXHDxhdP3j6S8e+NdE+ HfhfUfFGvSYt7cbYYFxvuZTwsajuSfyHJrwMHhJ4yuqUEejicSsPT5hnwu+IumfFL4eWPiSwt2tp xeSwXVkzbjbTKiEru7gggg9waMbgpYKvKnM2oYlYigpI7Xb9K42lu2WlZ+6eJfGP4zeHPhpomp2s WowS+OHt82OlqC5DtwrygcKoG48nnGK9nKsuqYyqpx+A8/HYyNBcifvH5KXHm3U81zOwaaVjI5AC gkkknAwBye1fo8UoJLsfIybbufc37Ik/w6kiv7K602yT4jxSM0N5dHdLcW5BIEG4kKVBIIUAkc5x 0+R4gVdP3HaPkfQ5XUovRrU+62TJJOcnv3r5JT/m3PatGJE0dF5MhqMupdnj83R7Zzy1vO0R+jgF R+at+dZp8s7W3OiSjOmvIwXi65rpvZ2scko3fMUpYRz/ACq1IhxM6aHg8Von5GbRkTQcHitEzNow rm2znA/GtkzKSKNisVvfotzxZ3ANvOfRH4J/A7W/CnUXNG46D5JWOG1jSpbO5urSdMTQSGNh7g4N ddKfOkzmqQ5ZNHCX9mMNkV1RZzM4jULPrxW8WZHEahZ/M3HrWy10JbtqcddQSQyLNExSWNgyuOqk HII+hrS3tFylwn7J85n+KbGKZrbWraMJbagpdo16RTggSr+ZUj2cVnTfQ6Kuj9stjzu5g68Ct0Qp X+Zhzwnnikap3M5Wktpo7mLiWMhl9MjsfY9Klo3hPl0IdVtI45UuLZcWlyvmxj+7k4Kn3ByKyjK7 OhrqYU0QZWUjggg/jVNBGVjmXiMUjRsPmU/nWdjrQ4DjoKLDJQOnOKZNyTb60Bcds9qSRNxdposF w2mixVw2miwXDaakLhtNAXFCZ61UXyOMt7Cqe9Hl2PeIvjSYoYoh4Z5RQuftuM4GP+edfUx4k5Yq Ps/xPnZ5FzT5+f8AA8QupftFzcXOzZ5sjPtznGSTjPtmvmKz9rOUu59BTjyQiuiEtbm5sriG7s5m huYSGSSM4Kkehp0qs6Mk4vVBUpxmnGezPZdG+Ml1DEkGuaWtw4GPtFuwQnHdlIIyfYj6V9Nh+JGo 8tWNz5/EZEubmpysblx8aNLVC9pol08uDgTSKgz25Gf5V0S4kp292HvHPDIKjlec9DybxN401zxS +y9kWKxVty2kGVQEdC2ckkep/DFfP4/M6uNbcnZHt4PLqeEtKOrOO2mvNdtD0eZq67htNIV2G00w uzufBPjH/hDpdQl/s37Z9qRBjzvK27STn7pzndXrZZmf9nSl7t7nmZhl/wBfivetYt+NfHf/AAmF tY239k/ZPs0jPu8/zd2RjGNoxWmZZr/aEV7trEYDLPqUn717mT4M8UDwjqlxqX2D7X5tuYPL83ys ZZWzu2n+7jGK5cux31Gp7TlubY7CfXI+z5rHReL/AIjf8JXpK6X/AGL9lxMsvm/aPM6AjG3YOu7r mu/Mc6WOp+z5bHJgcpeEq+05rnl+014DV5WR7craPY9X8K/E0eGdFt9HOifafKd2837V5edzE4xs OMZ9a+hwGe/UKKp8l/meJjsm+t1XU5zjvFviD/hKNYk1b7H9m3IieV5nmYwMZzgdfpXl5hjfr83N xs2d2Bwv1SHK3dGHZXd3pt1De2Fw8F1EdySocFT/AJ6isKFWeHaalZo6alONaPLKN0ezaT8ZbmKJ ItZ0lZ5AMefbPsLe5UgjJ9iPpX0uH4knGPJWjfzPn6+QwlLmpSsbc3xn0dYybfRbx39JHRAfxBP8 q6p8SU+W8YnOshqSl70jzTxR8RNb8SxPZ4Wz01vvW8BJLjsGY4JHsAB7V4WNzirjPdtZHr4PKqeG fM1dnn+015DTWvU9TfR7BtNFh3DaaLBcNpqXe90D1XY9d8N/FR9A0Wy0iTRPtRtgwE/2nZuBYkDb sOMA4619LguIHgqUaThc8LGZKsRVdTn38jk/GniyXxfqFteNZ/ZYoIfLSHzPM5ySTnA65UdO1ebm mZPMJ8yjax25fglg4cvc4/b+VedbuzvfvqyPWvDHxSl8O6NaaRLo32sQEhZftPl8EkgY2HpnHWvo 8Dn/ANUpqk43seFjMmWKm5xla5zPjXxe/jG7s7k2P2SK3iKCLzTLkkkk52jGRgYx2rgzLMXmE1Nx sdeX5f8AUI8rle5xYXnB/OvKktfI9IejPG6SRsySIQyupIKkcggjoRVxlOnNTg7MiSjJezmexaD8 YNVsYkttaslv0UbfPRvLkx23cEHH4e5r6XB8Q1KatUXN5ngYnI6VTWn7p1Unxp0dF3QaNePJjhXd FGcf3gSevtXfLiaNtFqcMOH2nueZeKfiFrniaN7P5bPS2OTbW5JMmOm9jgn6YA9q8HHZzXxa5fhR 7GEymlhvefvM4AKOfUdAa8pS1TW56kuZaS2Pc7X40G1tbOAeGtxgiWPzPtm3cQMZx5ZxX1NLiXkp +zdM+ankHNUc/aX+R4zf3H9oX19feXs+0yvKQx3bSxJwDgZxnGcV81Wn7Wcpn0FGn7KKhudB4M8T f8IhrEmpGzFyxhaEJ5mzGSDndtPYeldmW436hUVTkucmYYP69TdPmsdZ4w+Jp8V6G2kf2I1tmZZD O115nI7Bdg6/Wu/H559dpum4WOHBZN9Smqilc8pCggZDOw7dgK8L3ZLQ9tXXoem+F/iZrPh1YbK9 iF7YLgIrOVeIdMBsHIHoQfQYFe9gc8q4a0KmqR4WMyalibyjpJno5+M+hIjBfDl4Wxz5sqgDHcMD 6+1eq+JYpXS1PLjw7K93LRnDx/F/VX1aG9urPGlRZIsLeXZvJUgFnIOcZ44x7V58uIKtSt7WUfdX Q7oZBRjRcIv3u5L4p+Kq+I/Dd9oMXhtrVbloy1y135uCrgjC+WBzjHWpx+evHUJU1Cw8Bkf1PEKp 7T8DyFPO8s7ZFCj+8QD68d6+ejeyTPfUrO+4yZTu5mEhPVuf602FwAtgqlvML/xAYA/CgLjJAjMf LVgvoxyf6UAmTgj5CtpkDuSTu474/pTJT1IZACzERhP9kZ4/Pmoa1NFIl3JiP/RBxg5yfm+tX0Jl oHmQ/wDPov8A30f8ar3exPLU/mL9yJNkQYRhOcIhHU9yMnk16tmuh8/Bq4nmsFhzehcZAwpJA9+O aL+Y0ry2MrcUk3ecy4z86Ak/061nFs6Uk0Z17KJAoE0jEZ4cYA+nJpSZ0UopGVLNtVQJ5QADxt4H sOelRI6oIwmfbv8An257EbgayOyKMydyXXDKdvQgYH9KzkdUEUJjgHAUZ4JVs/pUSN4nq3ws0Frm 5uddnjPk248mHIHLkckfQcfjXTh4pe8eTm2I5EqMd3ufXnw00iwXUdQ8Ya3Asvh7wtCNRmifpdXG 4LbW/PB3zFSR6I2eKWLlKFqcN5Hl4SKvKb2icXqN5e6vqN7q2pTGbUL2Z555WJJd2JJPPua6adJR SRy1J87K4i9q1cUjNe6SCLFC1d2Te2h1Pg3wwfFniXS9DaXyLOVjJd3I/wCXe2QF5ZM+yA498Vji K3JSc3v0NsPT9pVUenUk8Za8PFfiTUdZhhENg5WGztwNogtY1CRIB2ARVGKWFp+xhbuGKqe1nddD mhGOldNrI5+a7HBBVCHBMUAL5X+z+lK/LqNeZ6P8Pk/siDxZ43f5W0SyMFmx4/026DRRFfdE8+QH sY1rhxnvyhRXX9DswvuRnUfQ842YxjNd8dFY427u4uzPUGqMw2/Wgq4m33oC43ZQr31BO61F2H+7 SXuom6ueh3sZsPhZ4egwRJq+s3d62RjdFFHFCmD3w/n/AJ1w07yxMufods240IpfaPqH9kOE6he+ O/EGoalNc6yUtrILPKWPkqCQeSSQPlA7ADivn+I37NQjFWieplK5uZ31Pob4kp8HxEl58TW0Z2tU IjS/YPKobsiA7snHGBzXi4GOKc19V6ndiZYaKftdz8r/ABLJoc/iHWpvDNrLb+HnuZGsoJmLOkJJ 2gk5Ocepr9Cw0JqjH2vxHytWVOTfJsYewf3a3SM7kkEk9rNHc200kNwmGWWFirKRyCGGCKznCM/i Q1JrZnvnw+0/xf8AH7xPofg3xd4r1SfQNKhluGuGUzNCuBwWPG5jwGcnHQZ6V42PlRyilKtSj7zP TwkKmNmozleKPu34U+CdK+G15408IaLNcnSWuba+t0u5A75aALKSQozlgo6V8hmGJqY9QrVFr1Po sJRhh1KC2PY8CvLbSd2dLUY6pas/OD9sRrNviF4fihEYvI9LBuCoGSC5KZIGegOM193wzCXsZX0X Q+Yzh/vUmz528B6XY6v438JaXqcQl0+71GGKaIkqHQsMgkYODXtY+ThhpTjujz8LFVKii9j9SLz4 GeABrvhXXdD0pNCv9AuvPiOjxpCLkZyY5eCSDjr1wWHevz6WaVnTnCprc+qhhKStKK1R62VIrzL9 TrsRkd6olxL9kvm2erWvUmITKPdCCf0JrOTtym1H4JIwmT1rZHNa1yrInZhVpmbKUsec1omZszJo uvFbXM2jHuIAc8VrFmTRgXVvwcj8K1i9GjKWiK3iS2+12+m6uBlp4jBOf+msYCkn6oYz7nNGHfK3 ErELmjGoup5lfWuc8V6EWcEkcTqFp97iumLMZHDajafewK2izNnEahaj5uK1EULC2OoW9/4fIy9y POtM9p0BwB/vrlfrt9KzmuV+07HXRlz/ALo8xu4G54/Cupe8tDP4b+Rz9xDjPAqWi4yMaaLrRY2U hbaI3ltcabjMvM0HrvA5UfUD8wKxl7suY6oS54cpzbpxgd6u12KLtqY+q2TxR2t2cYlyAO4APBP1 JrE7KUtDKUD0oLJlA44p2FckUc0JCH7fY0WEG0UWC47Z7Uirhs9qAuGz2oC4bPagLjlWlYLods96 YXQ3aKViRNposAgTd0p+S3HJ8uj2JNv+FFlvfUpu+qWg3b7GhJN6Mlt20Qm00KCinzA5tsTZ7UNx joF5S1YbPak01qg5r6Bs9qasw5mtg2e1JK2wJ+QbPaqTUdkHxO7YbPapWnQbelk7Bs9qpXTYviW9 w2e1Cjo76g5O+jDZ7Uh3DZ7UBcNntQFw2e1AXDZ7UBcNntQFw2e1AXDZ7UBcNntQFxdpoC4mz2oC 4bPagLi7TQle1wva9hNntTel7E72uLt5/rU7gAXP4VVgug2mizFcXb60WC4oXn1pCArzk1YC7cjn kevQCgVwUdsDjuf4aAuIV5zyfc07CuSbMv8ANkn16AUWENUDaUIJzyMd6r3bWF15gdThRtwo6D+d K1uouaOl0OVVbbkO7dx29ueaF/Mxu3woaqMJAFGG6AEdPzo3E3Yk2eYGU3BZuTjBwcDJ/wA4oJuN jiDIzeWXboAM8cdeKsQ6aMCNWMQRyeg7jHXnNA7jxu8qLypEUDGQcA5zyeecUCIrj5ipLh5AvzOv QnJxz9KBE7sXZWS7Ea9kyRs49h/KmhNlechnXDbsKAX/ALxHfmpkVHYnkMjShorlQhOVXfjbx6dq roTcmBOBvul39/nHWq0M9SSaJBAX8lo23ADJJz1z19K9VxSPDg3fchZlWOPy2iXA5LjJzzk9DxSt Y0jrIzJJY1nd0+6c7So5BPcCovY6IpsybuXdHtLsxzkbuAOvT61DaOqnEyZ5c7W/eAAdABjj09jW cjsgjBd8K45GTnIGfwrI7IIzZny+SM8d/X1xWT3OiBVEfnSxRKMu7hflXJ5OOBxk+1J7GydtWfcV 38Pz8Ol03w+lzHeWD2sV7a6lEu1L2KUbhIFJOCDlSCSQUI7V1YWpCcHbdHyuOu6rnLqej+LIx4a8 LeGvAsYC384TXNXIznzZU/0aE9PuQMHI9Z8dVrPDp1arrfZ6E126VKNJbvc82CetejY4H7pIE9am zYr3HBPp+NX0E3d2PTtNU+GPh1rGr52at4rkOk2hxgpZRFXuXXnIDM0cWccgvzwa4Jf7RXUVtDf5 nfCXsKLn1lseahB2FehpJ6HA9I3Y7b7Ur3dibWVxcGmIMD0NUAbW9KOW7YOVkkel+I4v7C8AeCvD gG291ZpdfvB32v8AurZT3xsRmAPdz6152H/fV5zfTY9DEfuqMI99zzXaK9LlseeG1fSkAbV9KAHb PagA2e1FpS1Bvoj2P4X/AAV1/wCKFpreoWF5FY2NipjjnuY2Zbm4wCIwQRgAFSW5xleDmvKzHNqe BfLI78LgXX1Psbwx+zboMGjeB4viDF/aF/pembBpUUpFtE8srzOzMuDISXPHA9ia+Wr57OcpSoaX PfWW04UoQqanmngWz8JeAv2lrrw14Nv2l0e/spbea2LbltLkAP5Ssclgu08ds4zxXfinUxeW+0rr 3l1ODDKnQxns6b0Z9H/Ev4VeFviBo2qG/wBBtpfEi2jiy1BUCzxyAEooYEEgkYwTjmvAwGPnhakY x2PVxWGhiIuR+SksEsEkkFwhSeJijoRgqwOCD9CK/TYSjUScXofG1IuMnEj2+9MkNvvQB+mfwC/4 RjwT8D7fxZJ+7t3Se+1S5hjMkjFJGTGACTgBQFHue5r8/wA4nVxONeHPrMv5KGGjNFyPxf4Vn0Hw z8bvE3ittKtLnUPJstPtYsiSIxvF5coJZnOGZ2IAC4/2axeFqxlLBwje3U6ViKXKq85WTIPjh8bL Xwd4PsbjwPrmm3ev6q4W3lhkWcQwAEtKFBIznaBnjk9xWuU5PUxOIbxCskcuOx0aVJeyd2z837y5 1/xfrU95eS3ur69eNukc7ppZTjA4AJwAOAOK+5jGhhYJXskfMv2uKbTV5Gp4T0HxHdeL9IsdH0XU J9atLyKR7W3gdpYgkgLFgBkAAHJNY4vEYdUpc8tGaUKNf2qSjax+zpJb5mGC3JHoT1r8tnbmbXU+ 3iuRJjSMUAMI70wLmk7V1K2RziOUmJvcMCP61FTYuj8aRjSRtGzxP99CVP1Bwa3jujGas2is6/8A 6qexiypIlaIhoz5Y6tMhozJovatYsyaMS5h9q3i9OYwkuoy3the6ZrGmYBkVBewjvuTIYD6oxpP3 ZJmtNc9OVNnm17b53cZrvjI82SOMv7Yc8c10xZgzh9RtfvEiuiLuZM4XUbbrxW6MzjblJbeZJ4Dt micOjDsQcg/nV2TWpUZOFpLczfF9jE11Dq9qm2y1SP7QqjokhOJU/BwfzqaDafs3ujqr2dpLZnnN 3DjPy1sZxdzBnh6/LTsbRZm5e3ljuIjtkjYMpHYg5FZThzI3py5ZDtR0/wA6+hazT91fASxjoFJP zD2AO76CocrRudDWtjD1dIrp3ghOYI1EUR9QO/4ksfxpWZalZ2OMCkZBXBHWix030J19adhEoXnp +FIm4/aKAJNvrQTcNooHcds9qCkxu0UCuO2e1AXFVamwXF2ikFw20BcTaaAuSwW8k8sUEKb5pWCK o/iJOAOfUmrjD2jiluyZVPZwcpH0xo3wU0SGyi/tm5uLm/KgyCFwkaE9lGMnHTJPPoK+xw/D9CEU 6r1Z8fXz+vzuNNaI89+JfgHSvCEGn3el3FwyXMjRmKchguBnIYAH868nNssoYRJ02etlOZ18W7TR 5Hs9q8JLWzPdb0uw2e1O0UryFzNuxv8Ah3wvq3ii++waVAGYDdJK+VSIHuxAOM9h1NdmEwU8c7Uz kxeOp4JXke023wLtxCv2zX5jOR83kwAKD6DJJP6V9DDhyKXLOevofO1eJJt3pw0OJ8VfCfWvD9vL f2My6jp8YLO0alJIwOSSuTkDuQT9BXm43IqmE9+nqelhM8pYtKM1Znle0V4jvFLmR7Ss72Z33gbw N/wmk2oxf2n9j+yKjZ8nzd+4kYxuGMY969XLct/tCUlz2sebmWY/UFF8ty543+Hn/CGWthc/2t9s +0u0e37P5W3AznO45qsyyhYFJudzLLc2+vO3JY832e1eQ1d2R7CsldsNntRYLhs9qLILhs9qYXG7 RQFx2z2oC4bPagLhs9qAuN2igLjtntSsguxu0UWQXDaKLILhtFFkFz1P4d+AtP8AGMGqTX15cQG1 ZFUQbfmDAk5yD/dr3Mpy2nmHNz9Dxc1zKpl/LydSL4i+BrDwb/Y/2G7uJ/tnm7vP2/Ls2YxgDrub NLNstp5fy8nUeU5lPMObn6Hmez2rxLHsgV9aaJbDb+OaAuAX0oC4Fe5oC47b6UBcAv6etAg2gEE8 g1QCkEqe/v2/CgTYBcjBJOO3agkNhDjtnoRQ+WSuCdro968K/CTRtf8ADmn6zdX97DNcIWIQpgEM QAAVzyBX0uDyaliaKqNny2PzqeGrumkeWeMNEtvDniC/0K2nmkgttm13xltyKxJxgcFsdK8jHUFh 8RKiuh7WAxDxOHjWfU5htwdWClSMYz14rjWiR3S1bJCGwwLxoD1C9/bgGmS9CFFXPzMwH+zyf6UC uDCPA27s9ycYoC4oMarhoiWz97djj0xigQx9pPyptHpnP86AH7osKPIBI6nceaaEyJgCSVXaPTOf 1qZDjsSf6MSP3cgHfDA5/MVXQm+obbfs0uPoKPc7hefYvyIpV2VJW5++3T8a9po8GLKhyEJ2xgH+ JuST6CoaNkZk+7zslgCecgcY9hUNanRTMe6YsrHc5GejDAOf61E1oddNGNP0XliPXdwKzkdkTFkP DHJznoDisWdcEUJCN5OTn68/nUPY6YOx3Pw00X+1vEsFxKoa1sAZ23DILdEH58/hV0IXepx5jWVC k11kfov8I10Xxi9t4H8bqP7B0hn1e11SRwg09FZDNBKx6W8xKqTyUdwQOTWGYJ4ZKrQ3e6PLwHLi bxrbI828aL4gfxb4hl8U2zweIJrqSa5icABXclhtxwVwV2kcEYxxiu/CxhGKVJ7HnYmVSMm625zQ X/Irru7HOrMkVevFKKuDdti3Y2F3qd9ZaZYQmW/vJkt4IV6ySOwCqPqWAqarVOEpvYdKDnUUY7na /Ee8tJPEKaFpdwJtD8O26aRaSoMLMIiTLMP+ukzTSfRwO1cuBptUvaS3ludGMmvaezjtE4LYK7zj uOwKB3DA9KBcwc+1Acxr6Botz4j1zR9As03XOo3MdsoHXLMAfyBrLEVFSpc76GlGLqz5O5t/EDWo PEHjHXb6yIOlxSizsgowBbQgRRFQOgKoG+rmssHTcKcbmuMqc9VnG4FdbOYMCkAYFAAABQAoUsVA BLEgBQMkk8AChvl1Qcqc7n6VfAzwZ4x03w54TbV9RTS9MtY5dvh61gG65lkZwZrqUklicqyquMcA 9MD4POa9OrWk4xu+59Tl9KaUY3tboe//ABD1uHQNL8V65I2yHTbSWReeRsjwAPfI4rxMDRlWqRi+ rPRx1RQ5pI+CPgZ8F/F+r3nhb4rp4g02KBLw3IhlLzTXA3FZdxAAViGbqT1ya+tzTM6MIPCOOtjw 8BgJSkq7e5+hoHG4cYr4pvklzRPoVa3Kflf+0V4ftvD/AMWPEUdnEkVrfCK9VE4AZ0BfjtlwxxX6 NkOJVbCq794+RzWksPVutjxCvYm3HdHmpxfvR1Z0Vn4N8YajaRX+n+EtaurCX/V3Ntp88sb84+Vl Ug88cGsamMoQ/iT17HRHC1qi0ifo1+zr4U8eeGvBGqeHvHmnJaWXnMLGzkaN5UjcEybtpK4JbIBO c7s8Yr4POcVhquIjVou76n0+XYepRouFXQ57Sv2Ubf8AsY6Z4i8WSXfhuLXGvUtrSMxSGIxkCLcS QmSSSyj6c1pPiFxtKlH3+5Uco5oc05XXY43xD+xrbzau03hPxctjochBNtqMDTyxHPIVwQGGOhIz XXh+KeWnarC7OOtkfPK8J2R9JfCn4X6T8KNCk0nTbn7ZfSyvLLqkkCRTyAgYQlRnYMcLnvXg5jmU 8bU5mrL1PVwuFWGjZas9FW0tI7m4vY7SBL2cBZrlIlWSYDoGYAFgOwJOK4nUk1qzp5V2JiO9ZNjG EZqiBpGKoBqsYmSVfvIQw+oOR/KkC3TLWtRIupXe37jkSqfUMM/1p0nYrEfFcxHXHFbKRzNWKzrz VbkMpyID2q0zNozZo+taIyaMm4izmtou7Mmr6lC0n/s/ULS9I/dxSDzB6oeGH4gmtJxuiaM+SZzX iDSzp2o31keVikKqRyCp5BB9wVrejL2iUuxhiIck5ROBvrcc8V2xd3c4nozidQtvvcV0RZizhdQt uvFbpmZw+oW4+bit07K4XvoUYoP7R0TVtJIzc2mdQtfUgACVB9Vw/wDwBqykvZ1FU7nXRaq03T7b Hl93D14rqT1uYxcUc9cxdc0LWVzSLad0Y8sBZgqKSxOAAMkk8YFLmUXqbJuWxtSwPZaReaf5itq0 AMrqOTbxMQHQN652k46Aketclm53ex3qXuW+0cE6da35TGMtTmb6Lyrp+wf5h+PX9d1S1Y7acrkK jH4UhsnQZxQK5KBmgkeB2FArjtvvQFw2igLhtFKwXDaKYx6r1qbS5rJDvpaxdttNv77d9hsbi4x1 8iNnx9cA1oqFaTtBGE8VRS95jbmwvLNgt5ZzQMegmjKH8iBTdCrFWqKxUMTQnH3ZFXb71lHflbNH JRjzHQeE4w/irw0rAFTqFuMHoQZFBBrswMJuskkcePqRVFtn2trMs1ppOqXcLYngtpZEJGQGCkg4 PHUd6+9rzdKg3HdI/P8ADpVq9pbXPiXVvEmva5DFBq2oy3UUTmRBIAdpIwcEAEDHbpXweIxNWu0q h+g4bD0qOtLqYOz2rjWurOxLQbtFNK6TFe7d9j7B+Fmk2+neDtNmhQefe7riV+7EkgD6AAD86+6y WioYZS7nwWc13UxTg9kYXiz4rReG9bn0aDRmujb7RNI83lckA4A2noG6mscZnSwtXkUTfB5K8VS9 qpWOpt/iD4ZuPDz+IjdiO3TKNbSY80SYyEC55J7Y4xz646FmtCpQdSX3HM8rxMK6o2+Z8ka3eWup 6rf39lYJZWs8hZLaMkiMH/HqccenFfFYipGvVlOKsj7jD05UaUYSd2eyfAxP9M8R8f8ALKHv7vX0 HDi5JzTR8/xHN8kGmbPxyTGl6Dz/AMt3/wDQRXRn/vxjZHLw9KEZycmfNm0V8frrE+xu27ocsbOw RFLOTgADJJ9BTjBz2VyZVYw0k7GjJomsRRefLpN4kGM+Y8DquOuckYrf6tO15Iy+t0b8sZGZtFY8 nSxo5xaumG0VTpyjpFD51UerDaKmKbly2HzxWjDaKPZTs9AjOEtGyzbWN3eyeVZ2s08g5KQoznH0 ANONKcnywVyZ1qdNXlIddWF7ZOI76zmgc9FmjKH8iBVTw8qXxKxMK8KivAqbRWXKno9jZPr1DaKL W0QefUngtLi6k8q2t5JZT/BEpY/kATVxpSqP3Y3M51oQXvSsT3WlajZANe6fc26t0M0TID+YFXLD 1I/HEiGIpy+CR7/8C1zZ+IvaWH+T19Pw4lBTR8zxG+eUHLzK3x3UD/hFf+3n/wBpVnxLzXpNeY+F 3G00j5828Z/Wvl3HsfV82urJIoJJXWOGNnkPREBYn8BzThCrN2ihTlCGspFy40bVbOPzbvTLuGH+ /LA6j8yAK2nhpwV5xMY4mnP4JGdtFYqEumxftIrfcNopyi7XaGqkXomKExx+lHK3eyDnS+Jj0jeR 1SNCzsQAqjJJPQACmqU5SstxOpFRcm9CzdadfWRQXtlPAXGV8+MpuHsCBmqnRqxfvqxFOvTqr3Sr txgnn6ngVk781kaaNeRdtNM1C/3Cy0+4uQP+eETPjHrgGt1hqktYbmEsTQgrSkQ3dndWjiK7tpIJ B/BKhUj8CBUuhUgr1FYca0Ki/du59i/DYL/wg+gYTJML9T33tyMV91lTTwsOU/Pc5kpYyaeh86fF FW/4TvXlTjPkZ7f8sY+9fLZ1rjZs+vyOSeBhF7HnpjYlR95j0A5Oa87km3danqe0gt3Y020PU44h PLpd8IcZ3m3ZR+ZGK1+rVEryRzrF0ZvWeploq7uULA9ADg1i1byN5TTV1qK6YUfuSvP3jn8qoSHI jFDtgDYPLHP5daAYyZGDYaIIQOQM/wBc0mhXHhThP9FyPXn5uPrTSC5AwG4/LtGenp+dKwXH4tie kgGOxDc/pVpCuRFeTgvjtx/9eotEV5Gq7ZZmUySEg9e2eOfoK9tnhRMosdrLlcDkZ9fasmzeKMu6 PzZ3ZI7gYx9BWbep10zGuiTuzuPuaib0OumYkxHt+dZM7IGRL36fjWZ1RKL9+n4VDN4n0p8J9GFl 4dbUXUCa/kL577F4A/E5NdtCGlz5zN63PU5F9k+n4F/4Rv4X3E4wupeL73yFPGRYWpBb3AeZgD6i MVhyLEYjXaP6mMW6GHu/t/oJpPirSNY0608MfEFLibTbZfK0/XbVd93pI7KQSPOtweTGTlOqEcgq ph50J+2w/wA13CniYVkqdf7+xjeJvBer+Go7a/Z7fUPDl2cWeuacxltrn0G7GY39UcBx6Ec1vhsW quktH2OevhnTV1t3OU2cc5NdtjkUn1PSvhyq6QfEvjuZRs8PWRFoT3v58xQYz3UGSQehjU1wY1uf Lh19r9DvwfuJ4j+X9Tzg5JJYkseST3PrXaly2S6HFL3pX7jcD0pisOwaB2F2+9Arht96AuejfD4n Sk8XeMSdr6Lpki2rf9PdyRbxEEd18x5B/wBcjXn45ubhRXU78JaEZVex5wqhQFAwAMY9hXopciSR wOXPK4u33pCuOoC43b70BcdQFwp8zV10C7drHo/wou9YHj/wnZafq95aRS3yNL9muXhBRMu27BAI wvOa87MKFL2MpOJ34GpNVoqL3LU3xQ8TeLb2bTPF3i/W5fBuq3vnXdtBiaXymk3gIp5JBK4XOOlY f2fTw1PnpR96KKeKdeparK6Z+lfwx0Dwn4f8H6ba+CrW7g0OYGcC/Eizu7cFpVcAhiRggAD0FfB5 jXrVq7dfU+owsVCkvZ7I9C2+9cC0Z0ebPmr9pfxJ4Jt/h7q2j6lLp974llZY7G0Do89rKSMyYGTH hdxOcZ6c19FkNHErERmvhPKzWtQVLklqz5b/AGbPhxp/j/xndXutQCfQtCjS4kgYZW4mZiIkbsVG 1iR3wAeDX0OfZhLC4ZKnL3pdTzMrwaxMuZx0R+oAJXbhiMDAwcYA7DHQe1fnkpzk/eep9WuWK0Ql Q2p+Qe6paI0lGNIn/wCvlP8A0F6htt6HSkuWV2Z2DWml7RRz8rWrEo3V2F09mFIQUANI71YDCM0E DGHajox9Ll/Uh5kGlXJGS8AjJ90JXn8AKUdGy6usYsxHHtWxysqutWpEtXKjirRmyjKtapmTMudK 2gZS0iY1xHnPGa1i7nO1pzDPEMX2uw0bU8ku8RtZT/txYA/NGjP50UH7OUqZpiVzwjV7nmt7D1r0 aex5s46HG6hBjPFdEWc7OG1G3+9xXVEzZwuoW/3hit12I21Oat7l9K1K01FED+RIGZD0dehU+xBI PsaJrnptGtGfJUTOX8U6Sml6te2kLF7UMJLd26vC4DIT7lWGffNOhPmjqaYiChU5UchFpV7qc5t7 C3aWUAsx4CoB1ZicAAepNXKaiiqUJSnykN1JZaIGi02dbrVOj36j5IfUQg8k/wC2fw9azs6q5jqj NUXy9TlbOYWt9DPKC0JJWZe7IwIYfUgt+NVUScNB06nLIytQs3sru5tHILROVyOhAPBHsRyKmLuX PTU5jVYSUjl2/dO0/Q//AF6ckdFCRkoOgqbGzLCjtRYi5Nt9aLBclC8+tFhDgv4UWFcNposFxdvv SsMNvvRuF7I+gvhn8LINQtovEHiSLzLeVQ1tZNkB1PId8ckHsvccmvostyuM4+1qo+XzfOnTfsKD Pebq80Lw9bRR3d3ZadagYjR3SEYHZV4/QV73tKGHXQ+eSrYl+4mMgufD/iO0mit7mx1KzOBJGrJM oz2K8/qKFUo4jS6Y37fCy1TR4H8SPhdBpVtN4g8ORsLJDm4s8k+WD/GpOTgdx26jjp89meVKn+9p I+iyjOXWl7Ks9B3wPv8ATrKXxDb3t9bQT3LWyQRzSqjTNmUYVSQSckDA9RTyKpCMpqW5XEMJyjCU Nj6OlaKGOSWZ1SNFLM7sFCgAkkk4AAA619S5JK8tj49JuXLHc+cPjRq2kapa6AumarZ3hjeUuLWd JSgITBIUnGcV8vndWlW5VTZ9bkFKtRcnVW54Ft96+eS6n1CvYNvvTXuu4Slf3UfTfwc8UW95pf8A wjN1IFv7Tc8AY/62IkkhfUgk8emMdDX1eS4u9L2Lex8bn+BcKvt1szofiB8OLfxZE1/YssGvRKFW Q8JOB0VvQ+h/Pjp0ZllsMSuaPxHJleaywbVOrrE+UNQ02+0q7n0/UbaSC7iba8UgwQfX0IPYjg9q +QqU50W1KJ9vSrU6yU6bKW33qIpKUWlY0k2oyTPvjT9V0jVGkXTdVs7towC4tp0lKA9C20nGcd6/ QsPWpVF+73PzTFUqsJWqKy1JL7UdL0pY5dT1G1s0kJCtdTLEHI6gFiM069enFWmTQoTxDtR6HyLr mly+LPiFqdjossc4u7klJ42DIEABLZGQQACeK+OrU5YvGONLY+4oYhYLBKdTc+m/C/gjRPClskWn 26veEDzb2UAySHHOD2HsOPx5r6nC4OlhI3UT5HGZlWxktWXJvFHhi2uDaXHiDTo7kHBR7lAVPo3P B+taSxeGvaTRlHC4u3PGLIV8K6C+s2fiezt44r+NXzPbYCzhlIywHBPOQetTDC4epNVYIueOxUKT pVDE+K0ePAWvYP8Azw/9HR1z5tCH1SV0dGTTlLGwVz56+FS58e6D/wBt8f8AfmSvm8pSnioaH1Wd VJU8HJo+tNZ0W113TbnSr3f9kn2hzGdpIDA4BwcZxivsq1CGIjytHwlHEzw9VVItmTHeeD/CqxaO l9pumgAbbYypGfqQTnn1PWsYzw+G9zS50ypYrG/vNbGze6bpus2Rtr62iu7GZQQrgMpBHBU/Q8EH 6VrUpUsRHVXOeGIrYadoux8cePPCo8J+IZ9OiLNZSKJrdm5OwkjBPqCCP1r4nMcI8PVstuh97lmN +u0l3W5d+H3geXxjqbrOzxaRbYa4lTqxPRFJ4ycdew/CtMtwLxM9dupnmmYLA033ex9Z2Gk6P4cs PIsbaCysYhliMIMDuzHkn3Jr7CnSoYOOisfETrYjGy1dynF4j8K6lI1hFrem3Mjjb5AnR/Mz2Azg /hmp+s4eq7cyNXh8VRV+Vi6L4U0nw9canNpNv5EV6yM8C/cUqCMqOwO7p09MVWHw0MO24dSMRjZ4 hRVToeOfHmPaPCvOf+Pn/wBpV4fEXM1Tfqe/ww0nVt5HknhDwpd+LtZh0yAmOADzJ58ZESA8n3JP AHrXjYPCPFzVloe7jsbHCU3Uk7M+wdC8MaJ4ZtPsul2ccMYH7yZ8F5MdSzHk/wAh2Ar7SlhqOFgk fB1sXVxU3Uuxn/CU+FZJzZDxDprTklTH9pjOT0I64z7UvrWHa5W0N4TFRh7RXG6f4T0XTNYuNc02 1S3uLmExSRwgKjgkEMFAwDxzjr9aKeFoRl7SCCpjq7pclR2PP/jfHjwpp/8A2EU/9Fy152dpexTS PT4eqSlWtJmb8DEzpevH/p4T6fdNZ5DZxldGvEUmnDlfc9Qv7LQNHv7zxXqssUUwiSD7TOQBEgJ4 XvkluccnivUnSw9Ccq0tDxqeJxdWEaFFnz98W/Fdj4gu9Js9JvEn0+CIyNLGcguxxjB5BAHf1r5v NsUsTKPJsj6rJMHPCxk6u7NH4YfDW31eBPEOvWxks2Y/ZbRsgS4OCzeozwB378dd8ryxVf31Q5s6 zeVB+xos+hLu50nQ7aN725tLGyT5V3usSAeig4H4Cvom6NCN9EfLRVfFOyu2ZrS+FPGFrNY+fY6n BjLRLIrlR6gA5B9xWM5YbFrkbTNeXE4F812maeiaPb6DpVnpVlJJ9lg3CMNy2CxOCRjOM4rejShQ goRRx4mvVrVPaSPkv4qxhfiBr6jnHke2f3MdfI5o+fFzi/I+9yWTeAg+iue7/DrwLp2gaLZapcW8 b67dxrK0rAMYVYZCLnOMAjJHU+2K9vLMBClFVHqfMZxmM69bkTsjvLfxDoU97/ZsGv2n25MhrWOV WcEcEYByTkcjtXc69GUuXS55jw9dR9pyux4v8YNH8J29t/aZVbTX53Plx2ygG4BIyWUYHA/j/Dmv IzbDYeC52/ePeyDE4uc+WWsT5x+UIyruJPBJ6YBzXzZ9gIPLKBXDAr/dxjBOec0ANk2naFztUH73 Xk5p2JJGKu+8TNGTz0PHsMGmkAwlGuQ7D5MjOaLE3JVExk+fy3XgMeCMetVYi5SYR7m2g4zxU2iV eRefJChixyOAvpXtM8RGZKFVnBPTgE9KxZ0w2Mi5fIHOT64xWcjqgjFuG+9xgkd6yZ2wRhzN34/K s2dkEZUrcnmszqiiOC3kvLm3tIQTJOwRQOpyQBUauaijSUvZxcux9u6NpJtrfS9FskLOix20ajnL HCjp6k16Mn7CFuiPjZP6xWcutz034nXMY8TL4dtHB07wzbRaNDtIILxA+e3HBJnMvPcAVz4LmjT9 p1luaY2fv+zW0Tz0KO9d6ikrHHbm1e50/h3xbrvhaS5/sm7X7HdDZdafcxrNbXif3ZYWBVx9RkdQ Qa58RhaVaKd9UdFDESpPl7nUfZ/h74tVntLoeD9fbn7Lds82lzE9o5jmS3z6Sb0H/PQDiuZyxGG1 a5499rf1/SOhKhiNF7j7G54+8Ma54B8CeD/Dl/YsiajNLrV9f2+JbaRm/dW6CZSUbCBmxn+MEdax wmIp4urKonsaYulVwlKNO254xx7V6ydttTytHpsLT1Y7xjuFGw9woEFAHouof8Sb4YeHrAHbc+I7 +XVZR0Jt7fdbQZ/4Gbs/iK86Nq+LlL+Tb57/AKHdNeyw0Y/z/oedV6X2bnC9HYKQBQAUEhQUFPq2 D2seifDV2s9R8S62pwdL0HULhG9JTCY4vzd1FcGO1hGmup14L43U7HNeEPEd94N8QaR4j0yKCS80 9/MjjuUDo3BBDKfYtgjkHkcitcRR+sU5Ur6GNGr7Crzn2JF+2BcXVzYQWnw/luZZYtssKXZLtP2E eEJK49Rmvl6vC8Y3qSqntRzhz9yMTCk/ax8e6drlxa6l4HsI0Vtq6ZIJknjYjgFjnOfQIM9q0hw9 h3FS9psS81qpuLjqzpPgp8HtK8dWmveNvil4ZvZdfu9VeeIX7SwrLGVVySgI3AszA5B6Y9a5cyzJ 4S1HDS0R1YPBKrF1K61Ps+w0+w0u1isdMsre0s4xhILaMRoo9AoAAr5epVlU3Z7VOKjokW6xLkSU LYZoKP8AiUzkj/l5T/0B6hPU3h/DZn1ZzCYFBQtAyOggKAGMM/jVkDG7U1ogtr6l9v3ujJxzb3JH 4OoIH5o1ZQdpGz1pehisMfhXSnc5mQP2qkZsqSDFVz8r1M3oUZR1reK18zFqxnSjrVrczZkzpwa2 izCQQR/a9F1qx6vBsvox/una4H1Vsn/cpVNJxl3NKXvU5wPObyLrxXpxep5kluzkL+H73FbxcTCp zR2OJ1CEYbit4yRlJN6s4XUIPvV0xakZO70jock2lX2p3BtdOs5bm4P8EKFivucdB9atzjT3ZUKc 5u0Vqaet6JpsWg6dfa/dGW+0tjYz2emyJI5BJeISycrHjLg8E9sVywqSday0vsepKEVSU6m66Hke tavcXcBsbWCKx0oHcLO1yAxHQuxJaQ+7E+2K7I0+V8zOaVbmXu6HC3Eec1sQncyJk61DNosm1ZTc 2um6j1Z4zBIf9tMAE/VCv5VnHQ6Zao5O9h8y2mTGTgkfUcim0VRlZnLpzjNSdhZUZ/GgllhRn8ad iCUL6UWFckC+lFhXF2miwXDaaXLdWG9UbvhnS11nxDo2mSf6q5uUSTt8hILfpurowlP2tZQOXHVv Y4aVQ+5767h0bSNS1FowIbK3eXYvAwqkgL6ZxgV9rVmqFNvoj88pQWKrJPds+FNZ1XUNd1C41PU7 hpruY5JPRR2AHYDoAK+Hr1pVpuVz9Fw2Hp4emlBC6JrGoaBqNvqmmzmK5iOeOjjurDuCOCKeHrOj NOL2JxOHjXptSWh92Wj22saTbXJjVrS+t1kMbfMCjoDg+oIOK+2U/b0k3sz87lH6rWsnqmfGum6Z /ZHxI03S1OVtNaiiUnncFnAB/ECvlKMPZYr2aPua1X2+A5/I+v8AxGn/ABT+u5/58p8Z/wBw19XX dqMj4jCaV4+p8C7fevhZNts/S4aRQbfepKuG33pONtUCa67k9pcXNlcwXdpM8VzE4eOWM4KkdCDW sJzp+9T0ZnVhGtTcKmp9T+APiZaeIUh0nWmS31wDakhwqXRHdegDH079vQfU5fmUcTFQqP3j4rNM plhv3lLWP5HVeNPAumeMLFo5lEWpxA/Z7xV5Q9QGx1UnqPxHNdONwUMXG/U48vzGtgam+h8aalpl 3pN/d6bfxGO7tnMbofUdx6gjkHuK+OrUXQlZn6BQxEcRBVUe4/Adf9M8Scf8s4f5vXuZDrKdz5ni V8ipteZs/HVMaVoH/Xw//oIrfPNotGHDes5My/gVpcbS6/q7qDKgS3jPcA5Zvz2rWORwu5zZvxHX s4UlsdP8Y/El5ouk2Wl6fM0VxqJcSSocMsSgZAPUZLAZ9ARXZm2J5KSprqcWRYRYiq5z2R8q7fev kuZtt3Pt7JJcqPbvgx4kvINZ/wCEZmmZ7C7R3hjY58qRQSSuegIU5H417uT4pxq+zezPm8+wilR9 uuh678V0P/CAa/wf+WHP/baOvXzV82FkeFk0ubGwPnj4URk+P9A4/wCe/wD6Jkr5vKf97ifV53rg ZI+rPFOpSaF4d1jVo0zNbQM0eem88DOfcrmvrMVW9lSkz4jBU/b14Uz4Unlnup5bm6leW4lJd5JC WLEnJJJ6k18LUqSnJyufpVKnGnSUbH1b8Frye98JS28zM5s7p4o85OEKqwGT6Fmr6vJ6znSs+h8T n1JU8Q5LqcF8dosazoZ24JtWGcc4DH/GvPzvWpFHqcNP3JHqXwo0lLDwTpkipiW7L3EhA6ksQOf9 1VFeplUFSw6Z4mdV/aYuS7Hj3xj8R3t5rsnhyKZk02yVC8aniWUqGJb1wCAB2Oa8nN8U6lTkT0R7 uR4NRpKs1qzxnaeoBrxFJ330PopJS91o+sfhB4ju9d0O7sdQlaW6050QSucs0bA7Qx7kFWGfSvrc oxXtqfI+h8Nn2FVCrGdNbnK/HtePCnH/AD8/+0q5M/esEd/DDbVV37G98EdLjt/Dl/qRUefd3RQt xnYgAA/NmroySEY0nJbs5eJK0qlRQeyML42eJLy3ls/DFnK0dvLD591sODKCSFQ+w2kkd8isM4xU otUonTkOEjJOtI+dtpr51N31Z9YoprlSPpD4KeJLy9F94bu5mljtoxPbM5yUQEKy59ASpHpX0mTY pyThI+Pz/CKLjUj8zY+OKf8AFJ6d/wBhJP8A0XLW+cu9E5uH3+/Zm/AlM6Vr/wD18J1/3TWeRu0Z G3Ej96BW+O106weHtORiIpHlmcdiVChf/QmqM8nblK4bp83PM+eLe3a4nht0xvlcIM9MkgD+dfPw XO0fWVZ+zpNn37aWVtptlbWkICWltEI17AKoAGcY7CvuqSVGlZdj8vrVJ16rUu58Q+LPEd74p1i5 1G7lYxbiIIc8Qx5OFA+nU9zXxuKxDqzbk9z9EwODp4ajGCMWzu7vT7qG+sZ2gu4mDRyo2CpHp/hW FKpKEuY6K9KnOLhJaM+4fCOst4h8NaTq7ZEtxEDII+m9SVbHoMqcV9phK/tqMZdz82zDDrDYqVKO x8r/ABXT/i4GvAqf+WHDdf8AUx18xmT5cXOXofb5Jf6hGPe59J+AfEFp4j8M2LwtF9ttIkhuYlPz IyjGcehxkfl1Br6HLsTGtSXNufH5phJ4XEOUloeeeKPgw0ksmqeF9QEFwzGQWlxnAJOcpIBleegP 5iuHFZZKTc6T17Ho4LPqcP3VWOjPCPEMXiCPV54/ErXQ1ZAA5uiS+0DAIJ6jHQjg14mIVRTSqs+p wk8O6fNh9jEYFlbEhIByQeO/WsDqvcFDKo/ebc845PfrQSxkiuzAsdxIGD60wTJNsufuxMR24/8A rU7EtlYKC3KZ/wBlaSG2OKwnd8jq3YcEfj0qmrk3ItntU2KJXYhSCxx6CvZZ4iRlzthuBj2PNYs6 oIxrgkZyRx2rKTOuCMOc9RmsztgjGmPWs2dkTNk71mdUTtvhrpg1HxfYMybobTdcNnsVHH67a1oR vK5y5hW9lh35n3p8Loo4PE//AAklyivaeG7WfWXVxwzwrmFSDwQ07QIc/wB+jHzfIqXWX9fkfO4C P7x1XsjgHklmkkmnkaSeRi8kjHJdickk+pJzXfTSjA5pztK0hMCnuuZbGbethaEuVW7jsm732N/w poUnifxLoXh+J1Q6hdRwNI5wsalgGYk9ABkk+grDFVY0KDlvY2w0FWr8p2GrfE/xDH4t8Rat4X1W 4tNDu5vLg05yJLdrSMCKFHhYFTiJIwTjOc1yUcBCVKKmtV12Outj5qpLkehXbxB4B8Qbj4k8JS6P qDZJ1Hwq4jQn1azkyhHsjR/WqlRr0f4MrpdP+D/w5CrYevrUjZ9wHw8i1Zl/4QvxbpGts+dtlNJ/ Z15x28mchXPtE8lCx9Sm7Vo8v4/187B9TjNfuZXOP1rw54g8OTm21/Rb7TrgfwXtu8Jx68gV008T Srq8ZXOaeHqUXrEx8g8jpW6a6GbXcckc0zxwW8Ze5lYRxoOpcnCgfUlRSk7RbHBXkkeh/FKWGHxU fD9nIHsPDtpb6PEw6OYYwrsPcuXJ9zXHgI3p873dzpx8uWpydEed13L3ovyOOW68wpDCgAoAKACn u7A9E2eheHM2fgD4l6iDhrlbDS1bvl7gTkD6pasD7ZrzsR7+KpR7XO2guXDVJeho/CHwN4f+Ifih vDWua7caZLNCXtHgVG8915KEtnB25IAHOD+M5niqmCoupCN2ThMPTxUnGTsfVdh+zBqHhDxZ4X8S +BPGTRy2E3mzSatCJCOMEIqAAgqzA5Ix1Br5efEKxWHnSqwPap5TKjKM6b0Pph/A/hG48Sw+Mrrw 7YzeK4tu3VHj3SqQMAqSSAQOB6V4X16qqbpc3unqrDQk/aW1OvJLHLEk+p5NcTldau50rVWYlIBy 96G7FdB1PoSjST/kDz/9fMf/AKC9ZdTph/DZm1ocwUAIehoLGUEBQAh6GrAjPQ0Ca0T7F6z+ez1a HH/LJJQPdWA/kzGolo9DSnrCSMhutbI5mVnIVSWIAHUk4Aq1d7Gbdjy/xN4qvJNetPBvhfWdFtde nhFxJLqLGV0jJIAhhUjzJPlYnJAAxkHNelQwrjTdeqtDknVTlZHbhHSKNJJDLIFAaQgKXIHJwMAZ POBXLfmd4lvVFKVea0TMpGZOuPmrWJjIZo8sdvrFp54zbTkwSj1RwVI/I1VROUbdiqDtJM4jU7SS zuLm0mH72B2ib6qSCf0rspS5kpdzhrQ5G4nJXNtLcOY4InkkJwERSxyfYV0qpCJzqnKWnUzrzwdq caeZqsltpUJG4NqUojcg91iALn8Fq1ioLZXKlgqm9Z2RxOoR+EdN3Yju9auR3kzaW+f90Euw9yU+ lbJ1Ku/uk3w9Jae8ef694j1a8gayheKx0zoLLToxBGw99uC34k1008PGOrMKmJqVFyrRHI6JELmT VdAbiPU7VkjHYTpmSM/XIYD3NVWiotT6rYrDVHJSpS6nlt1EQSCMH0PY11p8ySiY2cXZ6I564jxm gtMxZk9qDZMmtY/tWm6tZYy6Kt3GO+VOGx9Q1Y1FaR1QfMjmXUHg9O9aW90S0ZxjRmOWRCPukjH4 1B3JkyDtQDZYX1oIuThfwoES7fWnYVx2z2osFw2e1LZXFex0nhC9h0vxRoN9OwEEVzGXZuiqSAT+ AOa6cJL2dZTOPMKftsNKB9w6xpJ1jRNZ0oYD3ds8IY8BSykAn2BNfWYhe2puPc/PsLUVCsnLdM+C byyubC5uLK8geG6gco8bjBUjggivjJ0nTk4vofpdGtCtSjKGwtjp93qd5bWFjA013O4RI0GSxP8A TuTSp0nUqKMBYitGhTcpvQ++tK0+PStI03Ty4K2VvHDv7YRAucntxX2lNexpqL6H5pXqPEVrrds+ N7K9TVfidY6lFzFc65FIn+6ZwV/TFfMQnz4r2h9xUp+ywHJ5H134lXHh/Xl7/YpwT7bDX1Fd3oyP icK/38fU+A9pr4qW7P0yD91BtNIdw2mko66A3pd7HqPhz4SeJdesptQmQWMHlM0CXAIedsEqAvGA SBlj9QDXpUMtrVVzy0R4+Izyhh6vs46nmtxa3Flcy21xE8N1A5VkYFWRgcEH0INcM4OnKy0aPThO jXp90z7E+Futalr/AIThudV3SXEErW6zt1mRQpDMe5GSCe+PWvqsurzq0vfPgs5o06Fflps8b+OF lFB4psriNQslxZIZB3JDuoJ+oAH4V5GcKKqWR9Hw9OVTD8rNz4CRFrzxKP8AplD/ADetslTi5tHN xLK9OmvU2vjzCF0rQP8Ar4f/ANBFa5y7qKObhx+9KxQ+AtzCU8RaYxAmzFOoJ5YcqT+B2/nWeS1O Xnia8SUtY1Fsavxx8PXV7pml63awl0sGdJwoztR9uGPsCMH61pm9Jzgproc/D2LVGbhPZnzBsP8A dr51xsfap3+E9j+Cvh+6vvFA1nymFlp0b5lOQDI6lQoPc4Zif/rivUymi3V9o9keBn+KUKDo33Pb vi1H/wAW/wBfP/XD/wBHx17WYy/2aR83kf8Av8EfOnwljz8QdA/7b/8AoiSvn8tfLiYs+tzx8uEm fSvxPiP/AAgniHA4ESZ/7+LX0GYu+Hkz5HJ9MZCR8S7TXyOi0P0R3dj6l+BERPh3WDg/8fv/ALTW vpMnajBs+L4kd6kTk/jzGRrWg5B/49n/APQq5c41qRZ3cN/w5HrXwquo7/wNopjK7rYPBIB/CVY4 z9QVP416eXVefDxR4ec0XTxcn3PBvjJ4eutN8Vz6qY2NjqKrJHIAcB1UKyk+vGfoa8XNMO4VOfoz 6bIsVGWF9k/iR5HsrzFH7j272XMz6q+CHh+60/RNS1a6haP+0ZE8pWBBZEBw2D2JdseuPTFfS5TR 9jT5u58VxBiY1qsYU3sYPx+jx/wif/b1/wC0qwzx83Izp4Xuvar0Ok+B91Fc+FbqyGPPtbttwHXD AFSfqQw/CunJ6kXRcVujj4ghKFfmezOM+Ofh24TUdO8QxRFrJ4RbSsASEcEkZ9MhsD6Vx5xRlKSq xPR4exUVB0pb9DwHb9a8PZ67n0/M07o+hPgZ4euhcat4iliZbQxfZYnbIEhLBmI9QNqjPv8AWvey eg43nI+U4jxStGnD5nTfHSNh4S07I/5iKf8AouWuvN3eicPD7/fMy/gMn/Eq1/8A6+E/9BNZ5K7R ka8Sv3oGN8eUIvPDYx/yym/mlY52+blOnheV4zieD2krWt3bXIG4xOsgHrgg4/SvGpPlaPpa0faU 3E/QKPyL60jljO+2uIgysD95GGQRj1Br7aMlUp3j2PzGV6dV826Z8Ha9od54f1a+0m+RlmgcqCRg Ov8ACy+oI5FfG4ii6U2p9D9HwmJjiaMZxMqKF5XjjhQvI5ChVG4sScAADqTWUVeXKbzqQjFznsj7 m8D6JNoPhTR9Kul23EURaRc/dd2LkH1wWxX2WDp+xoxj2PzbNMRHEYmVSOzPlv4sr/xcHXdvT9xg /wDbGOvm8z1xMj7PJG3l8JepymkXuuaO8ms6M9zb+QQj3MSnYN3IVuCCDjgHrisKNSpSfPHZHZiK dCv+7r7n0R4F+Lo1m7stG16yWK+ncRw3MH3JHJwFKnJBJ6EEjJ6CvbwuZ+3koyVmz5PNMjVCMp0n ojofir4atdY8OahfNGDqOnIZ4ZsDdgYLIT3BGePUCunMaUJ0XPl1Rx5LjHSrxpc2j6Hx84JQ5UjB zz35+lfLH6AnfUQAKq7gSDz0Bxz70AxGUmVcdeCvbHccUEjgqbi6gFhyACRyOehHNOwMjiUkvjIJ /iAJI5z2oSBsCCEYSSBgRwO+c9eeadiCDb7VJYyXO4jH5167PHhsZNx0JzmsZHVTMW4PXHSsmdlN GFMetZndAx5SeazZ1wM6Q8ms2zpie5fBewGNb1Rl5+S3Rvblj/Ja6cIup4+bztywPr/TVOlfC/xJ qQO2bXtTg0uIt1MNuv2iYe4LyWv4x1lU/e42EP5L/iedT/dYWT7nndekcG4UgCjbULX0PRvAedL0 3x34u6NpummxtnPa5vCYBjPcQfamB7FAa8/G+/KFBfa3+Wv+R24T3VOt/L+p5zXoJWVjjbu7hQIa VBBBGQexocYrdXFeS+E7DRfH3jTw/bpZaZ4jvF01emn3JF1be+IJQyDI7hQa5Z4PD1Xdx1Oqli68 Fa5t/wDCc+HtT+XxT8NtGuZG4N5okkumTH3IUshP/AQKy+p1V/DnZdjX61Sb/eQudt8O9H+FWreL tN1W01rXtKh0YPq9za6vaxXUQjt1MhPnRlSAGVTypPbGa5MZWxVKk4ON33OvB0sNOrzqVkcdd+AN W1y7u9S0XxT4Y124u5XmdLbU1tZS7kscpciPnLdAT7ZreljPZRXPFx/H8jnnhPrN5U5XZz2qfD/x zosf2jVPCOrQWmSPtRtJGhYjriVQUOPY1vTx1KpLljLU5Z4OpT1mjkMqe9dSkmYuI6rSuLRBRqJt dgosu1xXfewUXTashu63Z6DNttPhRZL0fVPEUr/7wtbZAD+BvT/nNean7fFNLeH6/wDDHdJ+xwy/ vHD2N9eaZe2mo6fcPBfWsqzQzx8GN1III9wRXbUh7am6dTZnJCfJZx6H6b/AL4r618UdH1l9b063 gvNMkiia4tmwsxKZzsIyCcMSc45wK/P87y6nl9SLg9JH1uW414qn726PoJe9eAz1B1RYaSFHUUxD h0FBQtHUSNNf+QTP/wBfKf8AoD1n9o3h/DZmVoYpWCgTQUBYKB3I6CRD0NAmRnoa0+Kwn1L+lsou yjn5JYpY2/FCB+u2oavKxrStGd2fKPw0/aJsfHWs/wDCNTaFetrU91OYJbGNWhFqG+SR2JBGFxk+ pGK+jxmTSw0PbJ6aHh0cxVep7Ox6/wDEPwzceL/BXiXwzaXKwXeo2xiimYlQjZBBYjnHHNefgq0a FeNRrQ6MVSlOk0mfHnwa+HDeDfifev4i8WaPb63oi7RYpOsn2tJkdCQxIIIHUYyMj1r6fNMX9Ywi hRhuePg8P7Ks25H24WVxuQqynnKnIP4ivlVok5Kx7GrehGlnd3jbLS0mmfOMQxlz+QBolOEdWJU5 T23Cbw9qWP8ASRBaL3N3OiFfquS36VaxCXwieFqLWb0MibTtFt/mu9f8yQHhNPgL8juGbAH5VpGp VkvhsZunSp684nim80OG6g1O20H7S2oQJcCW+mJUNjaR5a4BIK8808NCrdxcti8ZOlFe1UNzzrUf E+ttG8NrdLY25yPK06MW4wexKgOR9Sa74YZXueZPF1WrHl2oLvaR3JZ2JLMxJJPqSeTXoU0kec5T k/eZw+oQ/erqiYM4fUIfvV0R1JbOTeaewvLa/tji5tpUmjJ6blIIz7ZFVNc94jpy5ZqaMvxrYwWu v37Wq4sbnbd24/6ZSqJEH4BsH3qcO7wXkdOISVR22POrlDzWxmmYk6daDVCaVItvqtm0hxC7+VJ6 bHBU5+gbNTUjeB00Jcs7mHeWz2txcWzjDxOUIPqDihaoezscXqKbL2X0YBvzHNJKx203dEaA8UBJ allfWgllhfWgklAxSsFx+31osFw2imK4bRRs7iburH1h8KfiRZ6jaQeHtduVh1SFRHBPK2BdqOAC x/jHTBPPbmvewWPU1yyep8bm+Uyi/bUlp2PS/EPgPwv4lcXGsaTHJdgAC4RmifA6AspGcehzXXPC 0q7vPU8uhmGIwv7qm7DdB8E+GvDDNLo+lRwTMuGncl3x3G5iSAfQYFVTw1LD/ATXx+JxT5ZO55T8 UviRYwWN14b8P3Sz3k6mO5uYTlIUPBQEcFiODjoPfp5+Pxyj7sXqexk+VSlNYmurLseC+Dx/xVvh Y/8AURtv/Rq15eEv7WLZ9Njklhp6n2x4kQf8I/r+OQbKfn/gBr6qvJSpPU/PcGpLFK/c+ANntXx0 lqz9Mi/dQbPalYbY5A6MHQlXUhgwOCCOhBoUuWXMKovd5V1Psv4b+OLPxZpkNpd3Cp4ggQLNCxAM wAx5i+uQMkDofbFfTYLGRqR5WfA5tl08PVdSn8LOs1bwT4X1y4W71bRLee5GB5rAqzAdAxUgnHoa 3nQozd3HU4aWYYjCx5acrI1JRpmgaazv5FjpVomcABEjUdgowPoB3rRzhQj2RnTjWxc+bds+KPHf iP8A4SzxJearGrCzAENurDkRrnBI7Ekk47Zr5fF1/rFaTWx+hZXhfqVFRPVfgDEWu/E3HHlQfzeu /KJqLkmeNxKpuMHFdzb+PkLDSfD3HW4f/wBBFa5vLmgkjDhtO80zwTwpr134V1u01m1XeY8rLEeB LGeGU/zHocGvHw9eeHqJn0uNw8cZS9nI+3tA1nQvFumi80u4jntnXbLA+N8ZIwVdT09PQ9sivp6d enWjofAV8LVwc7NanO3Pwh8BXN39qfQlRictHDLJGjH/AHVYAD2GBXO8JQlK7idVPOcXSjycx1Fq vh/QZ9O8N2It7WedWMFlAACQoJZioGQMDqeprWFSlRtTictWOIxKdWepy/xdgB+HfiAgf88Of+28 dY5hP9xJROrJG3jIyXQ+bvhFDn4ieHhtP/Lf/wBESV4uAly14tn1mdpVMFK71Pp34pQf8UD4jO3H 7pP/AEYle3jJxnQaPksn5pY2L6I+GvJH92vmk9z9CvzJ3Pq34BW5bw5rXy/8vv8A7TSvcyqShTd2 fHcRq9SPKjkfj/AV1rQPlx/or+n96ufMmpzudvDkXOlJbHLfC/xynhDUJrPU9x0K9YGUqpYwOOA4 UckY4IHOMY6YOOCxXsZ2OvOMv+u01Kn8SPra407RfE+mKs8FtqOlXChlPyyI47FWHceo5Fe63CtG 0tT4u9fAz7M5G0+EXgSzuRdJoKPIDlUnlkkRcc/dLEH8Qa544SjF3sds83xc4cqkdfY3ul3tzfab p1zHLLYbEmSHlYiQcLkcZAXoOldUK0HdRPOq06tP3prc8A/aDgw3hH3+1f8AtGvMzaSly3Pp+GE4 +1TXY8m+H/iyXwZrYvGjaTTbgCK6iXqUzkMBkDIPI/Ed64MDiXh5WPYzLArG07LSSPsu1k0TxTpX nWz2+oaVcrgggOrDqQykZBHcEZFfRqrTrx1PhJ06+Crdmjkf+FQeBBc/aRoeTnPlGaXZn/d3Yx7d K53g6F+blOp51jJLllM6u2n0e3vR4bsXgS6t4PNNpbgAQxggDIAwMk8CuqnVpr3Uzjq0sTL97U2P KvjxER4Q044x/wATGP8A9FS1wZrP92kerw8n7e6Mr4CJ/wASnxASOPtCf+gmpyiXuNGvEybcLmH8 fowt74a4xmKb+aVGbOM+R37nRwxzxVTmW9j578v614sfdPqm+W59IfCn4hWcdnB4W164WCSP5bO5 kOFdSeI2Y8AjtngjjrjPu5fjIxXLJnx+d5XJv6zQXqeza34T0DxLHGmtaZHclOEk5V0B5wrAggd8 ZxXpTo08RrU1PAoY7EYR8sHYyNJ8BeDvDDvqNnpkEU0QLfaruQuYgOpDMSFwO4xWcMNh6L5krG1T McZi1yN3v0On02/s9XtItQsJxNZy7gkqDhwCQSM44ypwa7IzUleJ506dSDtONmfH3xYVf+Fha7vL bf3GSBzjyY84Ga+Zx9vrTZ+gZNJxwEE1rqfS/g3T/Clx4Tt7LQY47rR3T96s2GZ3OC3mgj72eoPt jjFe1ho0vYpR1Pjsxq4qOI5ql0x2mfDXwdpeox6vZ6GqXiNujJldlQ+qqSQCO3HHaqjg6MKnOkZ1 s2xdaj7HmujlPi54nsdJ0K60KJ1bVdQQR+SpyYoiQWZsdMgYHrn2NYY/Er2fIpHdkeBnVrKq46I+ SWj46EZ9a+cZ97sgACgDew/lQSJg7s7uc9TQA4hgrNsX0yvb9adhXI1wFZSCM4II9RTQmwfGwKHL c5HXimJEYQ4HNTYfMVJyc/yr1meTDYyLjo3OaxkdVMxLg8Gsmd1Pcw5jy1ZnbAxpjzWTZ2QRnyHO ayZ0I+pfhZZfY/CFpKeGu5JJj9M4H6KK9CguWJ81mlTmr8nY+kPGv/Eu8N/DTw4rYaHSjqcy9/Nu 5GlBb3Eflj8K58L71adXuZYr3KUKHY85rvOAKACna6uF7Ox6NqeNI+F3hbTgcXOv6hc6tKO5hixb Qg/8CWdh/v151L97ipSf2djvq/usNFL7R5zXoHAFABQly7hcKd77MOW/UKWy0Yuruj0Tw5/xLfh/ 8Q9YPE18bPRIG6YMrmaUD1zFA4P1rz68pVMTSg/M7qKjTw9SS3djznC9a75RTehw81nobGl+INe0 SUT6Lrd/YTg58yyuZIT+akGs6uGpzVqi0NoYipRfMmdb/wALW8cTAJqupWusJgA/27p1rqDNj1km jZ8+4YH3rkeW4dW5Lq3mzdY+u/j1E/4TjRLrA1f4Z+G5mxgzWDXdjIev92ZkHJ7IKf1OvF3hU07a D+tUX8cLjv7S+FV3/wAfHhTxJpjHqbLVYb0Dr0WSKP24J/GhUcTD/l5zfKxXtsPP7HKH9lfCu6I+ zeNddsAT11XRhJt+vkSPnHtSVXFR3p/iL2eGn/y8t8hP+EK8N3H/ACD/AIp+Hpc9Pt0VzZfn5iHF WsXUj8VO3zGsLSkrxqX+R3viT4d6u/g/4daVpmueGb1kt7u8Y2urw4kaa5dAVLBdwKQRjPrkdq4M NjYRxFXmVtjqr4WVShSUdbXOCk+E3xEQBo/Dn2iMjKvaXtrMGHsFkJ+mRzXo/X8K/e5tfQ4nl9Z3 cV+J7n+zdpnxA8G/EeCwvvB+sR6PrcTWs8v2ORkjZQXRyyggAEMCSe4FeDn1TD4nDcy3R6WVUq9C qrx0P0UNrdp9+znX/ejYfzFfBXR9O6bIjlR84IHT5hj+dF0TyNCBl6bh+dF0OzHAjHUUwsx2R60X 1GkzSUj+yJ+f+XlP/QHrP7RvBP2bMzem4pvUuACVyM4JwDjrjIrQxFJHqKBNMTeP7w/OldEpPsKq SP8AcjZsjPyqT/Knc05WTrY3znKWNw3fKxMf5Cl7RAqdR9CQaTqbdLGQf7wC/wAyKOdB7Gp2A6Nf j/WJFH/10mQfyJo9pZIf1efVHkPxT8cR+AP7Bsl8QaBaajqU2N97dtmKIMAzKiqSzHdgdAOp6V6u XYR4mTdtjixNaFCaTlY/PfVvD3hHwT4w8QRRfFW5sr+zvrmFY9E0y782FBIQE80lVPAXODivuaFe riaSjKjdep81WoUKNV2ra+h6xpn7SGh+HvCB8OWlz4w1nWvOd/7d1D7NFJsOPlUM8hGMcEqfpXmS yKdWt7SS5V2OiOZRpR5E+Zng13428JSXlzqEXw4jvL+dzLLca/rFxdmVyclmESwdTuyAa9ingK9O lyxqbeS/W5wvF0HJydO3zNHTPjf458PZHhJdG8PocZGm6ZExIBzjdOJHx+NTPKMPXX76N39xUM0q 0l+50PffA/7WGr6pc2+j/EeYpbyYRdTtXdY0JOAJI8kAc8sOB6V42L4cpwXPhzspZu62lR6n06ZY 7iJJ4nWSJ1DK6ncGBGQQe4Irw+XlfJLc6vaOavfQy7gZzW0Er2Oed5PYW+H2rwvbP1ewuni+iSje B/30JKiFlXtfc1mnUw6X8p5zeL14r0Ipo8qbfU5K+TrXXEymkkcVqEf3q6IswZxGoR/eNbxMmcVf x9a2W7Ym9Fbci8Qxm88OeG9S2kvB5unSn/cIljJ+okYD2jrClpOUe53Vfeown955hdJya7DBMwp0 60GqZkzJkEUt4s2i7MueIV8y8ivuv22GO4J9XIw//j6tWNJ3TOirpK555rMZWeBx3Uj8j/8AXq5a G9B3KEfUCpWptItoOhoIZZUZ/GrMyYL+FKxNyQL+FFguLt96kLht96dguyaJevHpRfl3Vh3vpJHX ad438X6TEsFj4hvEgXgRu/mKo9AGBAH0raGIqwVlLQ4auXYat70o6kOqeM/FmsxNBqWvXktu4w0Q cojexVcA/iKVTEVZaN6FUcuw1H4I6nL7PasparRXO2LXJaw6KSa3miuLeV4p4nDxyRsVZGByCrDB BBGQRTi5R1RE4KqrNaG3J4p8VzxyQzeJdVeKRSrI97KwYEYIYFsEEda2eKqtWuc1PBYaDvy6mBsz WB1XF2D+7SGKEz2p3SVmEbpcxPA09vLHPbyvFMh3LJGxUqR0IYEEGiEpQd4kyp060bTWh3tr8TfH 1pEIovEUpQDAM0UUx4/2mUk/nXVHH1ftM86WTYFu7gc9rHiDXvEDIdZ1W4uwnKpI3yqfUKMAH6Cs alepV+J3Oujg6GH+CNjF8r2FYX5bnWnbRmpp2paxpLStpOp3dk0uA5tJ3iLgZwDtIzjJ61pTqOk2 0YVcPCv8fQmv9V1zV1ij1TV729SMkot1cPKFJ4JUEnB+lKVSpU1YqOFpUJXprczRbk9RUc7ludHu 3TZoafc6jpdwt1pl7Pa3A6SW8jIcemQRx7U4znTfuszq4eliFeornYN8Q/HrxGA+JLsIRjK7Vb/v oAH9a3+t1/tM4/7IwqfMo3OYivtXgvjqcGp3cepnObtJ3WU5GDlgc8jg81j7aSlzXOr6tBQ5OXQu 3eu+JdStpLPUPEGp3VpJjfBcXckiNggjILEHBCkZFEq9ScXcVPCUaHvU42ZnWTXunXMV5p91NbXk eds9vIY3TIIO1gQRkFgfas4VOTVGs6cKseSa0Na71/xPf28tpfeIdUuLWQAPDPeSOjgEEBlLEHkZ 5rSWIlNcplTwNCnLnprUwvsg9P0rJvQ6Wk5WNbT9U13SYng0vWb+yhc7mjtLiSIMcAZIUgE4HWtI 1pU42RhVwtCtL30Q6hd6rqzxy6rqV3eyRqQj3czylQTkhSxOBmpnUc9WVSw9Oiv3ejM77J/s/pS8 zVRknc29J1vX9BLHR9WurRW5ZIpGCMfVh0J+orSFaVL4WctfA0cT/Ejc1dQ8c+NtSha3vPEV4YWG GWJhEGHodoGR7GrliqsvtGMMqwlHWEdTn7DUta0kSrpWr3tmspBcWlw8QcjON20jOMnrUQqzg3Zn RUwtKolGUdiPUtQ1nV/J/tbVL29EWfLF3O83lZxnbuJxnAzj0olXdVe+OlhlRvKmrXMo2x7Cock9 DW13qzR0vUtZ0SYz6RqNzZyH7xt5Cu4DswBwR9aunVqUdbnPVwtKtHlqxudBdfEDx3dQmGXxLeCM jB8oiM4/3lAP610LG1+Wzkcscqw0Ze5DU5a01LWNNnmutP1W7trmXIkmt53jdwTkhmUgnnnmsI1q id2zqnhqdSPs6kdB+oa1r2qwJb6prN/eW6sHEV1cySqGAIBAJIBwSM1Uq1Sokpk08PSoO8I2IbHV 9Z0lJI9L1e9s43wzra3DxBiOAWCkZNKnWqU7qA6uHp1/jjch1DUtW1YxNqmp3d60QIQ3U7ylAeoB YnGcdqKtSVRK4UcPCgvcW5m+UfSp2aRsnrqN8s+hpq66A1ZWtodRpnjTxbo8K2+n69dx268LEz71 UeiqwIA+ldEMTUpbSOCtl2GxC5qkblXVvFHiLXU8rVtZuriHOfKZ8Jn12jA/SieJq1PduOjgcPh/ epxILbxH4lsYI7ay1/Ure1jBCQwXciKoJycKCAOT2pRr1I+7zWCpg6FX3pRMu8ury/uZLu+uprm6 kxvmuJDI5wABuYkk4AA5qJSc5XlqzopQhRh7NbFjTtV1TR5jc6VqE9rO3Be3kKlh6HB5HsacKtSl K0XZGdXD0MQ+WpG500vxF8cTwiB/EV0EHAKFUPT1UA/rW7xlZLVnEsowlNpqOhxsss1xPJNcSPLM 5Jd3YszH1JOSTXPO85XkehTpwpqy0SISpAxgjPPNMLjvTDYx2I4oAaFBZuM+gNBNxGjG0ttwc/nm nYQgVgMBwM4ODTsJsZIpzyoB9qTKiw2xdyf0piMybqePxr0GeXAxrg//AK6zZ2U9jDuD196yZ3Uz BueM1kzugY81ZM64GfI3f1NZs6Io+2PCWlu+j+G9GgGyaeKC3X2d8AH8zXo6U6Vz5CtJ1679T1v4 r3cd38QfEsduoW1sZE0+FF6IkCLFgfiprDBRtQSe4Y6ftK+mx59XacgUANbdghFLOeFUckk9APqa Unuwir2SPS/ioUtPEll4bhZTB4e0yz0sFOhdYg8hz3Jdzn3riwKvT9q/tHZjn+89l/KebV3HGFAB QAUAFD0TQ7X1PQ9a/wCJf8NPBOng/vdT1C+1OQEcMiCO3iI+hF0K8+leWKqdlb+vyOyo+XD033ue eV6BxBQAUAFMAoWo78zNPQxpba1o664XGim7iF4UJBEBYbyCOc7d3Tn0rCu2qTcNx0Yr2mp+lY+A XwhvtFNtaeGIVjuIP3V9HNI0qgjKuHLEkjIIz1+lfBSzbFRq3nLRH1MMDQaSieT/ABN/ZY8Q3R0G Pw1rdldx6ZpFrZpbXqmF3ITcxDDK5ZnY8kCu7AcQ0439pDVmWNyuTsoM8Ak/Z4+L9iWeLwbMWEgT NpPExJ7EbWyQP73SvcjnWBm9Xr6Hkyy/GQ0ij6e/Zp+F/ivwtqGveJPGlnqNlqUQW1sLa6lbARhl 5FAYg54Xp646189nuY0cQvZ0dj28rwtajrVR9kJf3y/dvJh/wM/418o4w3se2qtS97lldY1VemoT j/gZpOlHdFxxFTm3H/21qh5a+kY+rYJ/Mio9nCWjQ/bzego1a/JwZFJPcxqSfxIpqCfuA67W7OTs fil4b1PxFfeErDxNp03iS0z51gmwuMDJCjGCR3A6d66qmXVacFUlC0TCOYKUpRUtUd3/AGtfDSbm UFHkWZQFEajd8jnHTuRXHGEXNI7FXqeylK5+Ueq/tG/F/T/H2pazPqi2t3BeNE+nS2kYWOJWIELA rnGB657g1+jUslwdXCJQV3Y+MqZvi44h8zsfp3o3i1te0nTNb0y9jksb2FJ4ZokUBlYZ6gduhHrX wGIwzo1JUZ6NH1VLFzrU4yjsaf8AbWqr9y+lXP8AdO3+VY+yTXM0X9YnrqQtqupN96/nPOfvmqUI PWwOq3b3iu95dv8Afupj/wADPf8AGnYh1WVzI7fekY/Uk1XKQ5tkGB6Cqs4uyJ5nfc/N79rPWftX xLtLCFju0nTYkI7b3Jl4/BlzX3nDuHUMK5z3ex8tmlS+IUX0PJviuFfxzqF/GMRalbWV8u0AZMlt EXPHq4kr2sBZYdJ7q5xZglLEOcfI4ax0zUdVnW10zT7m7uWIAitYmkbJIA4UHGScV01K1OlDmlKy OaEJ1ZWitT0nUfgh8VdMjsZJ/Bl9KboFhHagTPHjGRIFJKHnoa8+OcYN6cx0ywFf+UktvgZ8WLrG 3wZeRbu9yUi/9CIpyzfBr7QRwFf+U3tK/Z1+JN3qljaappcen6fK2Jr1p45RCg5JwrEknoB3PoOa 56ud4aEGoyuy4YCan72x956bpltouk6dpFnu+yWVulvHuOTtRQBk9zgV8jOqqs3NI9dqNNKJHP0N XFmU37w7Th59j4isMcvaidf96JgSfwRpKmppUjI0o/BKl3PPLweteinc8ySscperwf610QMJHG36 cGuiJjI4nUFHzV1RMmcVfp1yK1W5L3uRWqm88M+KtOxl7fydRjHujFHx6fu5GP4VlN8s0zupPmpT ieXXSfMfauk50zBnXrxTNEzJlXrQ1qadC1er52iaVP1aCSW2PsCQ6/mWestps6pSvCPkcFrkLiK1 mKEIWIDEcH1x9MVT1NsPJoxoxnFC0N5NlxB+FBDLSL/+qghsnVRxzQQyQLz60AmO2mgdw2mgLk0Y xuNJoE7jiM9qVh3GkHpiqDmG7TQHMKE9RSsAuwHtRYB4iNMB4ixUAPEft+NADxCT2oGmSrbk9Bmg omW2NSBItqc0BYnW09qVykrEosie1K42TLZn0pXBK5Mtif7tLmKJVsevymk53AlFgePlpDsx4sCP 4aAsyQaeey/pRcLDhYH+7+OKLoLC/YD/AHDS5ymL/Zx/uH8v/rUc5LQf2cf7ppcwWG/YD/cNNSCw 02BP8NO5TQw2B/u80XJsR/YT/douFiM2J7KaaERGxPpTuBEbM56U7iaITZnHSgkha09qaYELW3Ti ncGrkLWzHtTIIDbn0qiSMwkUDuRmP1Bp7iGGLvVJWAYYj/8Arp3Exhj9qRLGlPSgNBDHnoKBXGlO OQfrVCuxu0UJBzAV6dxVWELtb6gfjTFcZtHcZoC4jKMDGfoaBDthIGVDADt1/SmSmNGC6lhwMDH0 qkJsfh/7yfp/hQK5hzgc12s8+BjXPes2dkNjn7nvWTO+mYM55NZM7obGPN3rJnXESwjt5tS06G7W VrSS4iWVLcgOyFgCFJBAJBOMjGetZM6E9D9SvDngu20b4u+DNMtrprrw1PPDqWn6i6gfaLMKZEkI HAI2FXA6OjDqKbxDnhZP7XY+bjQ5MTbpqeRXl8+p3t9qkmfMvZ5Lls9cu5c5692r06MVCHKjyajv PmexXrQQUAdf8PtIGu+OfCWlMu6Oa/hLg8DYrBzknthTmubGT9nRckdODgp14xZjeIdXPiDxBruu /wAOo3s90oxjCu5IGO2AVFXh4KFGMDOvJzqubMmtjIKACgAoAKT6saeyPQ/iL/o0/g3Ren9l+HrF Co/hedTePn3DXRB9xiuDL7T5qq+0/wAtP0OzHe4lS/l/U88r0TiCkAUEhQUFNvl90b0ZueGNHPiH xJoGghmUaheQ2zOvJRXcAsPoCxrnxVRYWhKUjTDUnUqI/Yi0to7a2gs7aMLFFGI40HQAAAD8q/Lq r5nKT6n2VKNpWOk1sj+1r9V+7HIYwfZQAP5VzUm+RM7MQ0qligOopqTT5mzJN7kg6g+tCvHWxT9/ QkHUVDfNKw7cp5R8ZviPe/C7wePEWn6db3t7LcpaxxXTlUBYEknaQTgL0BFenlOXxx1b2bZx5jil hafMkeB+A/2uba7uri1+Iekx2ULkGC90qNnVBjkSISSeedwJ+nevcxfDThrh38jzcPnd9Ki07nIf FH9qnV9Z+06N8Oo5NL0ogo+qzAfaZgRg7F5EYPryfp0rpy7hyNL95iNX2MMZm7elJaHgWg2Hivwh FpvxUWKS1i07UoDA92jq967hmJjyMSDarbjnjIr2K86GJpvCR1v+hwUY1aUvrDP2H0bVbPXPClrr GnyrLZXrwzxuhDAho2OMj0zivzDEU54etyyVmj7mhUVehePU+cP2hvhTofi3wlrfimz0pF8Y6bB9 oju7dcPcxpy0bgfe+TcRxnIFe5kmaToV405S91nkZng4VYOoo+8fEPgH44/EL4dWi6XoepRT6IrF hp19EJY0J5O0nBXJ5IBr67F5Ph8cvaS3PnqOYVMM1GDPuP4c/tGeCvGS+H9G1K7ksvF96Ehkt3ty sLzkciNgSACemSDXyOPyKth7zgvdPocLmtOtZM+ha8BpReiPUdpK6CgWiGt2qh3RG3amlJtPoRPb 1PhH9p74TapJq0vxG0OG5vra5QLqMCKXNqUUBZAAM+WQOfQ+xr7Lh/Mo8vsKnQ+ezXBvmVU4b/hT /jX4nQ/DfVtHsRbaXL4etoLnVL47IleKSVSQMbpDtK4CgjjqK7v7Vw2BlNSldrZGdTASxUIT2R9o /DX4a6F8L9EfS9GZ5b24w17qEnyyXTgYGQOijPCjp7nmvlcbj6uYTcpaLserh8LTw6SS+Z3btxXG nymjuVHrS/MS7lGU+tW7q0mY1G56IzpSMEV0Xu1YxbilaW5lT9DWkVqYPXUXw+6DXtPikbEVyzWz nsFlUxEn8HNTXX7ty7F4V3rJ+pwd6jxvJHIuJEYhh6EHBH5130ndHDUWrOUvRkGupHLLc4++HXmu iJjI4vUFJ3e1dUTKRxWoLw3FaRE/hTIvC+xvENvZSkCDUY5bGQnniVCv88VGIjaDZ04R3qcvc8uu 4niZ4pRiVCVYehBwR+YroWxm1qzn7hevarLSMiZeTTSuzSOqLtnBLe6RqllApaZJoJkQdSSxi4/7 +DNc0tJI6qa5oyOX8amNPs9jA4a3sSLcMOjsAS7D6sTTRvBpM4mMDiqOiTVi9GOntQYtlxRj8Ksz ZYC/hQJskAzQSP2e1AXDZ7UBcmjUnNJlJj9nPNSO40oewxQIBGfT8qAHiL1NAEgj9qCyUQk9qAJV tie1QBYS17YpXHYsraEn7uaLjSLSWR6YpNlWLSWOf4ahsqxZXTz/AHanmHYtJYdPl/GlzDLSaaf7 tTzFWLSaYf7v6UuYpRLK6Wf+edL2hXKTrpZP8HvS5w5SwulH+7+lTzlcpMNJb+7+lHOHKSDSD/dN TzlchINIOfu0c4cg4aQcfdqeYXIL/Y5/umjmDkG/2Of7tHMPkEOjkfw1SkHIMbSD/do5xchG2kt0 20c4cpC2kn+5+lUpkuJA2lNz8lPnFykDaWf7lHOLlKzaYf7v6VfMLlKzaaeeKfMLlKr6cR/DT5iX EqPp/wDs00yWirJY4/hq0yWio9mfSquRYrPaEfw1VxWKz2o9KdxFdrU+lO4ELQMO1O5LdyFo6ZDI zF/doG0NMZ9OtWIZs9qBMZtzntTRIhQZHp3NUA0p14x75pCuBVvb6GgQ0rycjHrirJuJsAyVbp+B oGNAAPzDI7g0CYYHp+tAjDnB5rtZ59NmJc96zZ20zn7nvWTPQpmDc9PxrJnbTMebvWLOyBo+F4Dc +JtBgIyGuY+PxzTj/EQYmXLQkz9Xfgrqba7beIfCV81ul3p2l6hd6Dql5MIk065ljMbRyOQf3MhZ SB2kAI+8+ePM4TpSVaGztdf12/L5Hj5dVVVOm9+jPn6/06+0e9utJ1KzltNRs3ME1tOpV4nU4IIP pXt0pwqU4zg9zxqtOVOpKFQrVabJsugVXxB8J6N8ND9ivPFniDkHSNBvp426bZnj8iI/hJLGa8/H 3lGNJPVv8jswa5ZOr2PN1AVQo6AAD8K7krx5Tim9Wx1MAoAKACgCa0s5tRurXT7YZubuVLeMYzl3 IVePqRUVZcsWyqceacUdt8U7yG++I3jKW2INpFfy28Hf91EfLT/x1Frly+LjQgpbnTjZKVaTODrt OQKACgAoAKHuF2nofUn7Nnw21fUPFNh461LTpIvD1hHI9nPMNoupyCgKA8lQC2WxjOMHivnM+x8Y U3Qj1PWy3DNS9rI/RDS087UdOiPR54wfoWGf0r4WtpBM+loq80TXkvm313J/fkY/qaS+FGlV3k2M U4/Ck9NSFqrkqdqiT5dTXSTueX/ED4yeBfhrJBa+IdQlk1OYblsLCMTSqvZmGQFB7ZOT2Fejgsrx OMXNFaPqcWIx9PDO03qfC/xz+OA+KjaZpek6bLZeHLCQzKLpgZbiUjaHIHAABYAe5zX2mTZOsufN N3kfO5hj3i1yrRHz3XunmjSMgj1FKS5k0OLs0z6E+MHj3xb8VNE0HxGvhW507wBpT/ZIZywkR7kq ASxGMHGAOMc4zmvDwGFo4CtKDnebPRxdapiEppe4ja+EPxe1v4YfD3V7yPdqGlf8JFYwtpkxO1Ym t7oymNs/KxKREDGOD6mubN8rjj8TBRVnZ/odWXY6eHw8m9j9APDHjjwp4xsrO98P67Z3X2mISi1W dPPjGBkNFncCCcHIxXxmJwNbBz5ZLVH0FLE0qqvF3PC/ir+zP4Z8ZfatZ8JmLRPE7kuyKv8Aot2x 67lH3Cf7y8eor2Muz6rhFyV9Y/kcGMyunX9+npI+FvE/w6+IXw9vBPrWgXlmbRxJHqMKGWAFSCrC RcgDO3GcH2r7CljsLjqdoS3Pnp4WthWm47H6jfDDxtbfEDwRofiSGRTdSwiO7jByYp1GHU9O4z9D xX57meDlhMRKJ9bhMQq1OLO+PQ15rfLqmdWj1K1zcRWtvcXU5IhgjaVyqliFUEnCgEk4HAHWtadL 2jUV1M5TVjwr4a/HvQviZ4p1nw3p+lXFkLaIzWk9y4zdorANlR90gEEDnjOelezjcmqYGiqsnozz 8NmEMVNxtsaHijwx8TPFXjKKNPFK6F8NoFCy22nMGu9R4ywYlCIwTwCDwOetZ4avhaFG7V6j6jqU 6tarv7h7W9tb2nh/w9a2cCw2lor20cUfAjRSAqgegHFeZzc1Vs9Gov3cLdDKc1oluczejKjntVJG bKkh6+1aJGTZRlOa1RlMzpTkGtYmMzLmPeto6GMjIaVreeKZGIZGDAjsQc5rRrQiMrNEHjGJYfEO shABHJOZ0A6BZAJFA9gHFVg23TSuTjly1XFHnd59016EFyuxwT3ORvh1FdETA42/HJNdMWZy1OL1 BfvelbR0EtEcx9pfT7y01BM7rWVJ8DqdrA/0pyXMiqErSKPjmyWx8Ua9BGB5RuGlQjoVf5wR7c1N B89JTN8THkquJ57cDGa6XuZxfvXMiYdqPiVma81nc6jQrd9NsdRu2lKaje2Mxs4hjIVRkyNnoCVw vqcnoK5KjvNJbHfRVoNy3PI9cH+iR4P/AC1H8jXQRQ1Ofi//AF1B2F+MZqzNsuIvSgzbLK+tUQSh efWgVx+33pWC44J60tguTxJ96kykyby+en40krlB5Xt+NILjhHnFArkywZPNDYy0ltx0qW7lWLSW pPQfWlcZbjs2JqWykXorAnqvFS2UkXo9OJ7VDZaRfj03jkVLkNRNCPSyccVDkaKJfj0k5Hy496hy K5C/HpBPRalzHyF6PRjx8uKl1C1AvR6Mf7lZuoXyF2PRT12UvaFchbTRCf4Kn2gezLKaIcDKUnUL 5CddDP8Ac/Sp9oNU2TLoZz9z9KHUH7IlGheqUlVH7McNDPZKXtBcgv8AYf8AsUe0H7NgdD5+5R7Q PZjDoZ7JT9oHsyNtDP8Ac/Sj2geyIW0Mj+D9KftCXTIG0Qj+Cq9qL2ZWbRD/AHKftQ5Cq+iHn5P0 pqqRyFN9GPJ2VaqkuBSk0Y4PyU1MhxZQl0c8/JWnOS4FCTST/dqlMlxKEuln+7TUyHEzpdMI7Vop ENFGTTiCeK0UiWihJYe1UmQ0UZLHGRiruKxSktccYpkNFN7bnpVklV4CO1NE2IWjIqgImjHpTRLZ GY8fWmQxhQ5P9aBEZTPbFACY78H2NWAgBzn170Etgy8c4yehFOwhApA2gjnkg0xXGkDJzGP1qrAY M69cV1s86mzCuhnOKxZ3UjnrlevNZM76TOfuf61kz0KRiz1lM7YbG94GG7xl4eHrcr/I06f8REYv /d5f11P0J8IjyfB/xYvD97+y7W2XnkmW+twR642b/wCXeqxV6uIopr3Xe/3HzuHahQqvtY17LUNN +I9lZ6F4kvY7LxvaxrBpmvXDBYtRRRhLa8Y9HGAEnPsr8YNYzpywU+alrB7rt/X9edRmsVDlqaS/ M801TS9S0PUr3SNYsZrPVLRzHNbTqVeNh6g9QeoI4I5HFenQrxqxujz6tGVORSqk7MT2PRNCC2fw 1+Id8cB72603SlPchpJLogew+xrn8PWuCs08ZRi/N/19520P90qfI87r0FucNr3QUAFABQAUAd38 LbVLv4keClkUNFb36Xrq2CCluDcEEHqCIjn2rizB2oTs7HVgYc1ZJ+Zxl7cNd315dOxZppXlJPcl ic/rXVSjyxSMKz5pyZXqyAoAKACgBpXII9aGuo7qNkz9R/gf4gtfEHwx8LTW7L5tlD9iuERdojkQ kEAfQg596/PM4pSp4qXNsz6fCVFUppRPdtAG7V7I/wB0s/8A3yhb+leNW+A9XCK9RFIPvJcn73P5 0tkRe9yZe1FuZNFRdlY5H4h+KZvBPgjxJ4qt7QXNxp9v5kcDHAZywRSfYFgT7V04GisRiYUmYYmo 6NByR+ROrarqOu6nfaxq13Jc6lduZJp5DkuxP8h0A7Cv0+hSVGKpRVkfGVJyk+aepn1tZ9SVrqwp ANJCgsThQMkn0FKTsmxpXdj9BPGPhmXwP+ykdDuo4lvzHBJchvmxLLMHIBHUjcAD7V8Rha88Rm3M lofSVqKw+XtPc+Pbb/klWtf9jFZf+k13X1E3/tEL+f6HkQv9Xkcho+tar4f1CDVtD1Cex1KAkpc2 zlHXIwRkdiOorqq4alVjy1Y3uctGtKl8D1P0K+APx7j8arp3gfxKs/8Awl0UDsuouQUvlU556ESA HkYwcZr4bOcleGftafw9ux9Pl2Yqv+7qblHxp8a/F3gL4oSad488MmP4YXKvbweTCJvtKHB84MeG POGj7DIwTzWuCy2li8KpYeX7xGeLxtSlWcKsfcZ5F8GPiv4e8FfEvxFolgzj4feIdQP2SedTGbQk kRMVJ4ByqnPQYPavQzTK6tfCQlP44nJgsdCnWcF8LP0Rbg4NfD2sfTKUWrRPkL9o/VfGPw+sLbVv Cfi29tNI1yR7S507G8QORu8yGQgtFnoVBAz0719NkVOhi5fvo7Hh5nOpRV4nxr8NPGDeBfHXh/xS 4keC2nK3KINzvC4KuFBIySCcV9Zj8KsRh3RXU8LC1/Y1VUZ+s+i6vFr2k2GsW9tc29veRCVIbyIx Sqp6blPIJHODzX5tWoxpzdLex9lGpzQU2jpHO7QkPeK8YfgUB/mKwirVDZ60rmC7cV0R2ORvUqua tIzbKcnc9q0SMmyjK3WtDOe5nSnINaIwnsZczda2MmzEujlT+NbxVzB6O5L4uPmvouof8/enQsTn PzJmIg+4CLUYVcs5Q7GuN99Rq9zze8+6a9KL5tTzG9Tk73q1boykcdfYORW0TLc42/H3q6E7ktnH 3qghgehBrXZWBe67kvjdTO/h7Uj1vNKtmY+rovlOfxKGsMP7sXT7HZiZc/LV7nmVyVXqQOwzXUno mYpXNCDS7bTrSHWdei3RSrutNOJ2veejnusI7t1PQetYybrS5YnbTgqUbzKWm3V1qXiSyub1w0l8 HXPQBSrKAB2AxgAdBRNcsLGkG3K72PL9cBFjFu4PmLx74NadEPDbs5+IdPzoOyW5oRj8KoxZdQUE MtKM/jQZkyrQK5MqY+tAx6oPTNKwFmCMfN+FJjRZEWewNIq5KsGeQKTYFhbXocc1Nx2LiWfTj8Kl uxoX4rIkjiobHY0otPJbpxUORaiaUOmZ/h/Soci1E1oNLz/Dz9KhzNFA1oNJ/wBnNZuZqomtBo+f 4azcylA1odFyv3Kl1DRQNKLROmE/GsnULUDUh0PoNn0qHUNFA0o9D6fJUOqWqZoRaF/sVDqFKmX4 9C/6Z0valchbTQv9iodUr2ZbTQunyVLqlezRYXQuOEpe1H7MnXQev7updYFSJhoQ/wCeeaXtSvZj hoXqlHtA9mh39hD+5R7Qfsxp0L0Sl7QXsxDoX+xT9oHsyJ9B6/u6fthOmQNoX+xVe1F7IrvoXP3K aqh7MqvoX+x+lV7UnkKj6F1+SqVUl0yhJoXUbKpVSHTKEuh9fk/CqVQl0zNl0P8A2atVCHTMybRP 9j9K0VUzdMyptF4J2VoqhDpmTNo+P4TzVqZm4GVNpOCflrRSIcDIm0sgn5eK0jMhwMmbTevB/KtO Yz5TKm08/ex+laKRm4mZJYtk/L09qtSM2ihJZnuKq5LVijJbcdKtMhlSSAjjFNMgrNF6irIITH1q xsjZOen5UEsaVBz+lArjNmB1xntVksay+2KBC7eOmQO4qrCuJn2/SgVjAuFHpmupnnU2YN0uc1i0 d1JnOXS9azluehSZztyO1YzPRpsxZhjdWbO2HQ3PAvHjPw7/ANfI/kaVNfvUTjF/s0v66n6FaK3l fDHx84zmbUNMt/QYJnk/HmMcfj2rSu/9ppL1Pm6f+71DzsgEYIyDXfa6aOJNo9M07xjpmuabZ+G/ iLBPd2VqoisNftgGvtKTsnJAngB/5ZMQR1Rh0PmVcJKlL2lB2fbv/l6ndTxMZrkqq/n2MbxP4J1X w3b2+qrLBqXhe6OLXXdNYyW05/usxAMcg6FHAcHtXRRxlLELka5ZLdGNbCVKPvp80WaV5/onwo0G Po2p6/eTH/cgt7dEP4m4mH4VnScqmLnG2kbWfrc1q/u8NB/zHnleg1Jarc4Vd2vsFIAoAKAChgej fC8/Z9Z8R6wSR/ZPh7UbsN/dLRi39R18/FcGPtKlGD6s7MD7tXn7Hm6ghVHoAK7oaRRxS1lIdTGF ABQAUAFF+XQLWR678K/i/rPwwnvIoLRL/RLtg81jI+whwMB0YA4OOCMEGvMx+VxxurOvC4x0GfpF 8HfHlh8QtC/4SmxgNuUhuVmtWkEht3UYIYgAHIIOcd6+CzPCPB1XTa+Z9Vl1eGISmjqUOFFcvLt1 LWraJJJ4baGS4uZkigiUs8sjBVQDklmPAApKE5SUYj54Wuz5F/aJ+Nmn2ml3HgLw2bHUzqtqRe3q SiVbVSwIQKDgscZyTwO2a+nyTKZSqLEVVax4+Y46DXsqep8G19po9j5/R/EFGiB2XwhQ9VqrBqld E1pczWV3a3tuVFxbSpNGWUMAykEEqQQRkcgjB71NWLlDlYoTcXzJantPxA+P3jX4jeHE8Maxa6bb 6cZI5ZTZQsrzOhypYsxAGecACvIweUUsJV9qndnfiMyqVaapvY5KzRn+FeroilnbxHYqqgZJJtro AAe9dFeShiIuS7k0knQmo+R1P/DPHxa/4R6PxCPC8hV2H/EuEi/awpIAYw53Dk9OuOSMc1g88wka vIpFxyutKPOker/Bb4C+OtD8c+HfFvi2GHRNL05muIxNcxGW4k2lRHsDEr1JJOOOgOa8zNc4oYqg 6VFXbO3A4CrQq89VWRxP7SPxJvfGPjO78OWt7DL4X0ObZbLbkMss20B5CRnJBLKMcAD3NduRYB4a h7V/FI5c0xCr1eVbI+cvy9q93lUotM81Ssfot+zH8T9T8X6PqPhfxFqMM+p6QqfZXkP7+eAgjLEn 5tp4yBnHWvg8/wAuWGmqlJWTPpsqxjnHk6nY/Gj4neEPBjaL4Y8Z+Gp9V0XXUkNwVVSkMakAkA8s wLAgAggcg54rlynAVsS3Uozs4m2PxMKC5Kivc/NDVJNOtdfvZ/Dksp0qC8aSxkuFw/lq+YyQe4AX INfoFCMpRVOstep8rVlZ88D7l+Avxy17xhe3HhnxVbajqmtyOZk1K1tlMUMXAxKqAFACfvnI55xX x+c5TSw79pRdkfQZfjp11yTPrax1XTL6w8QadaahbzX2nzwNcW8UgZ4C4cAMATjOOhr5qdOVOabW jPbpTUqc4qWh4L4x+PXgrwT4ku/DGt22pi9t1RmlggV48OMgg7geAeeK9vDZNXxGHVWK0Z5FbH0q MnTmR6t8dfhnFpD3Np4vhe7nhJghtIWuJ0cqSN0QGQQeoOB6mnTyvEqo4zjoiKmLpuHLTep84/CT 4j+LX+JlhYeOde1GaK9tXtreK/8AkAZyHjYpnCkhcDr1Ar28bgqP1VzpR2OGlXqKtaTPteVq+YSP QbM6Zq2ijGTMuY9TWkTFsxrg8Gt0Ytk2tHzvDXhu5A+aGS5tmPtlWUfgC1TR0rS8zfE+9h6flc83 uzwwzXow2PLkcpe963S965kzkL44zW8XdmZx98M7sdq3jFy1IfKchefeNaJrZg7l3UbG81fw34Oj sLWW5vElu7JYoULMxEglxgegn/CueE1TqTctj0HCVShTild6nJ3Uej+GmJvHg1XxCh4s0IktbMjv KwyJZB/cHyDuT0rojF1leKsjWMIYe13eRxV/f3WpT3V3qEzz3kxDGWQ5Ix2A6AY4AHArojQUVcyl Uu2S6R8up6PL08u6Cknn73Tj8D+dZV9ImlKXvI4HxPH5SyxgY2XJGP7uCwpLY1oaTOXiHSlFanTN +8aMQ6cU0jNsvIOhq0ZNltEz3/GmZllU9qkCdUNNgTLH7Uk7DuXbeHO7A9KmTKiX0t+B1rNMuxcj tTx8tS2UaMVl0+T8azbLSNSGwY/w1DkaJGxBppJHy1DmaKJt2+lZPC5rJ1C1Fm3b6Pn+HrWLqGyg blto2cfJWcqpqoG5b6J22frWTqGipm3Bonyj5KzdQ0UDZg0M4HyDNZOoaqmasWh9P3fes3ULVM1o tD6fL+FT7Q0VM04tD6fu6ydUtUzQi0McfJWbqlqmaEeh/wCxSdUtUi2mhj+5UuqV7MtLon+xU+1H 7MsLog4+Wp9qUqZMuiAfwUe0H7MlGij+7+dL2g/Zjxoo7JS9oHsxf7D/ANmn7QPZgdF/2KFUD2Yw 6KO60/aB7MjbRR/dpe0B0yFtEH9yr9oS6ZXfRD/dpKoLkKr6GP7lWqpPIVH0P/YoVUn2ZRk0Pr8l aKoS6ZQl0Pr8lWqhDpmXNof+z+NWqhDpmXPofX5K0VQh0zHuND+U/JWqqGTpmLPomf4KtVDJ0zEu NEPJ2Vqqhm4GJcaN1+StlUMpRMK40YjPyVoqhk4mHcaVjd8laqZm4GHPphGcrWqkZuBiz6fjPy1s pGLiZE9kQSO1WmZtGZLaY/hq7mbRRktsHGMe1US0UXhI7GtDNorGPBP9KoRGyCgRGV7dvQ1ZIzac 571RA1l4yRigBm0+9HKK5j3Ce1dbPLpSMC6TrgVDR6FFnNXSZzWMkehSZzlyuSf51lNHo02Ycy53 Vi9mdsGa3g5xB4t8PyHgC6Tn68f1pU/4qHinfDSP0KtAR8JvE+eAfE+lDPri01LP5ZWpxH+/UfSX /tp85T/3ap8jz+vU6M4Ao0YJXXY6Xwz4v8QeEbi4l0W8C290Al3YXMYmtr1B/DNCwKuPQ4yOxFc1 fC06697RrY3w+JqUG7ao9p8T2Xgzxb4S+G1rZ31n4P1qexu7+LTLsyNp0jSXk0ZCzks0BPkKQHBQ BwMoBk+Ph6uIw+JqxlHmStr8ketifZYjD0pRfK9dDxLxH4S8R+ErmK28Q6TNaGVd8Mxw8Nyh6NFK pKSKezKSK9jDYyniFeDPIxGFqUHaZz1dJiFABQAUAej+Dv8ARfBXxZ1IjB+xWWnqfXz7gEgfhHzX n4nXEUYd7ndhtKFSfax5xXobHnBQWFABQAUAFNeY72Ck1J7Cdj7w/ZN8LeKbLwx478XWuqC2s76z e2stPuI90NxKGA85+hAB+QFTz82fu18ZxFXpVa1Ok1fuz6XKKc44edT7jy3xJ+0Z8ZLHUrzSJbPT 9KvbeUxSQLY72VgcYBYk89j3ruoZNgZQUpM4auOxKvFLU888WfGD4p+ItMvfCfifVpPsl0yGe0a1 EMjAEEKcAHaSAdveu7C5dgqM/aU0ro5KuJxFV8s3Yz/DHwc+I3im+Sw07wreWyFA7XWoxNawRoc4 JZgM57BQT7YrbEZrhcLG8pX8go4CtUfK4/M+n9F/Y/0j7FA3iPxlftqR5kTTYY1iX2BcFj9ePpXz 1bihv4IHrU8lg/iY7Vf2O9HNrIdA8bX63w5QajbxvGfY7ApH1zU0uKGvjgKpksF8LOR8OfsjeJpN cSPxXrljD4dTJeXTXLzzY6KFZQEz3JJwOgzyOqvxNS9n+7XvGNHJmpXm7o6vxH+x5ZS3CS+EvGEt tbMTvg1SDzig4xtZSpP4iuWlxRPltOF2dNbJY702egaN+yr8MbHRn0/Vlv8AU9SlwX1JpzC6EdRG q8AfXJPc1xVeI8VUmpQdkdEMpoKCjOOp86/F74e6J8MvC2r6FoPiCXUIzrlhO8c2BLZsba7wjFcA nAUjgHBGa9zLcbVx9SMqi7nn4vDww8JqMjW+HX7VeueHNOtNF8Z6Y+t20BCJqUcuy5WPphgQRIQO h4J7mox/D0Ks+ek7NmeFzaVNKEtUdL+0h498B+PPAPhy+8N+J4rnVLa/Dx2UbskqoyEOXjIBGBt5 PHoTXNkmAr4fEyVaGh05ljKdaCVOWp8SAAAADAr7FKztE+es5O3UWhq+iJ3lY6bwd4q1DwR4n0jx VpccUl9YOzJFPnZIGUqVbBBwQT+OD2rlxeEWKjKnLY3w+Ilhnzw1Z7x8Sfjv4d+KXgiTRda8KS2f iW28uezvbeQSRrODhxzhljK9uT/OvHwOU1MHXU6cvd6npYrMFiaPLJe8fMNfR6StqeQ9U+U1dK17 XNBa4fRNXu7B7hPLla0lMZkUZwGIIzjPFYVKFOtbnVyoVqlNux6z8MvHPi/w/wCFPipDoXiC6tJR Z2+obkYEmRbhUZyxBJJEgBz1/CvMxuDoVK9NyjpqejhMRUVGq1LseRaxrOq+INSutY1u/mvdUuSG luZzlnIAAzjA4AAGK9WjQhRioU1oebObqyvM+rfhN4k+CfgXww2uNqQl8bSWxM41C3d3SQAny4gF KhScDcDkjqa+ex1LG1q/s18J6tCph6dO9/ePn3wxqmpeIPib4e1jULhpNUv9at5pJW5O9plP5DgC vVxFFUMNyLaxx0ajliedvU/TqR+APavh3uz2WzOmbrWsUYyZlzNweK1UTFsx5261qkYtk7sZvBuo J1a01GKX6B4ymPzFQ/dqxt1Oj4sNLyPNL6VIo5ZpGCxoCzMeigDJPHoK9KKPNmfP1p8SjqnidrFk ii0SVjFC7cNu7MzHoD0weBXqfVHGnzGa1OtvTnOelc8NDOXkcjeqztsRGdzxtQFiT6ADJJrWLUFd uyFFSk+WMblR9DtdNtftvjvU00VuSNJiAmv5B1AMWcRZHeQg9wpFT7RzdqCuztWC9kuas7GbrPi4 XXgG9tPC9m+jaTDqoikWOYvPdLLCSTLJgEk+Ryq4GMDBFOnh+SsnV3Z1zrKOH5aWx4pgAYA4HavW krJXPN1td7kRHelZ8pSfvFvS+NT08k4H2iM/+Pisay902pS9443xguy5vIyfmF5IPyZhWMEdFL4j lIR0FUlqbyfvGjEtVYybL8aZxQZMvIvTigRaRDnpQBaSPtSYrluOHOOKi5Rq2ttndgdMc1E2aRNe G0zjjJrG5pY1oLDOMrUuRoom5b6aTj5fpWLkaqJvW+lZx8v41lKZsoHQ22kHjCc4FYuZsqZ0Vpo2 cfJWUqprGmdFa6J0Pl1hKqbxpnQW2idPkrGVU1VM3rbROnyVn7U1VM3bfQ/9jrWUqxooGzBofA+S snVNVA1otD6fu6zczRU0asOi9DsrN1DRUzRj0Ybh8lQ6pSpl+PR/9iodUtQLqaQP7lT7Qfsy0mkf 7Gal1C1TLC6SB/AKXtCnAmXSh/cFJ1AUSVdKHdKnnY+QkGlj+4KOcfIO/ssf3P0p+0DkF/sr/Z/S j2gcgf2V/s/pU84cg06WP7gp84chGdLH9zFVzi5CM6UP7lHOHIQNpIP8Ap+0J5Cu2kdfkFV7UXIi s+kD+5T9oT7Ipvo45OyrVUh0yjJo3H3KaqCdMzpdFH9zpVqoZumZc2iAj7laKqQ6Zkz6IMH93Wqr GbpmHc6Hz/q/etFVIlTMS50PrhK1jVMXTMG40P8A6Z1sqpjKmc9c6J1+StI1TF0znLrRsbvk/St4 1DGVI5y60jrhK3UzF0znLrSmGfkraMzGUDnrrTT/AHetbRmYygYFxYkEjbWyZi0Y89ow6itUZNGT Lb4J4rS5m0UJIParuQVGjOfWrIIGTrTAj2H8+oqiCNkB6DFAC8+jVZkzMuIM5IPWuls86nEwbuAn Pas2zuoxOXu4TzxWLPSpx1OYuo+TWbPSpowLhMZzWbOumN0uQ2ur6ZcdDHcRt+TDNZ9Ub1NYteR+ jcB8z4TasV/5Z+JbLd7b7S7I/Py2/KnUkvrUI9Wn+Fj5i/7ifkef16dzheuoVIgpPYa3PRPiF+6j 8A2PTyPDVg+OBjzlM/QdM+bn36964cFyzUp9/wBNDqxjcVFLoZXh7x14l8M28mnWN4lxoUpJl0bU ohdWcpIwSYWyFY/30w/oa0r4GjUlz7MiljKsNHqb5l+F3in/AF0F74L1hsfPbhtR01yf9kkTRD6F wPU1zqOKofB76+7+vwN3LDV9Je4/vKOo/DHxZaWsmp6VbQeINDUbjqXhuX7bGq+rooEsY9S6Ae9a 08wpyfLL3ZdjOeBqxXNF3R56CD0OccfiK7FKMtmcjUo7odVarYej3PRrP/RfhDr0xGDqPiK1ten3 hFbvKfwBP51wTvPEx8jtglDDPzPOa70rp3Zw6J6ahQAUAFABQBo6Ro+qa/qVpo+jWUl3qVy2yKCI DLHGScnAAABJJ4A5NTUqwpRcqrskVTpSquyPpfRv2VfEdx9mfXfFGn2an/WwWkbzugz/AAscKSR6 ivnanEMVFqEbo9GGXS3mz7s8G6HYeFfBVzoelptsbKG2tYiQAWw+SzY4yTuJ9ya+PxdaWJrqR9Hh oKnhppeRMEiLrIYozICGDsgYqR0IJBII9RT55N2uQpJdCjN4f0C71e01+70Wyn1y2XbBfywhpYhk H5SeQQRweo7YprFVILkT0KUYt3sdArZ6dfWuZ6PmTNFZEobjJqSkyQN+NJobY8HuKixS0HhufSix VxwbGD6UXUbD1cro+Cv2iPAKeD9C1/Vba9eey8Q+I7W9CTPukhk+z3QcMTyQScgn6dq+zyTFSqyg rWsfPZhRUISd9z43r64+fCiyGFAgoAKV4x3EuVBVK26H8WzCkAUAeifDrbInxDsjz9q8MXSAZwSU ntpeO2QIj17Zrz8bC06c+z/4B24N80Jx7nndd6k7pnG4pXTCq0WrQrq/unpnwaso7/4m+EYpVysd wbj8YkaQfqorzs0k4YSTj1OrCJqvdn6RStgV8Qj12zOlfg1qkZNmXM/Wt0mYzaZj3D9e9axiuphO XL0LOmN52i+MrXrm2hucf9cpQM/h5lZ1larTa03OjDtyoVIX1djzDU4o7u3uLWbd5UyGNtp2nBGD g9uK9GEtrnne9HRnzhf/AAX8X3F0x8IaReatpQ+9cqEjW1I6iSRiEA7hienXmvTjmlGH7urozWnh J19aS0Lckmm6EIW8XfEI395bqFXR/CqrOSQMAS3TAIOwO0P7E0WlXf7uGncv2GHo/HP3uxUu/ipr OpSw6R4V0238NWEzhZJtOcveyoBk7rpsMCQDwgQdjkUnl8Y/vKkrsHi4xVsOrHG+INPa6ZJ7aFPN UkFEAUsDznJ5JB7kknPU10UZ23dkcvtJTd29RtjaXSeCvF8U9rLGq3VhcAyIV+758fGQP+e1FSd6 8Dpgr0JnCEYrqOXYjIxQUXdHGNZ0sntcRn8mBrKsr02a0n+8OG8aBl1W5jb74uZmI9y+awWx2Ula 5zUI6CrsW3axpxKTj+dDRkzSjTgCmZM0I4zwcUEtl2OInAxQJGjFb98VLZaNKC3yc4rNs0SN6ysj zkdccVjOVjaKOjtrAnGFrBzNlE6G10wkD5aydQ3jA6a00rO35awlUNYQOmtNHyR8tYSqm8YHUWmi 8D5a55VTpjA6i00UcfJWDqGsaZ0troo4+SsZVDeNM6C10UDHy1jKZtGkb1vowx92snUNo0zbg0fp 8tZOoaKka0OkAAfLUOoaKkaUWkjj5azdQtUzQj0sf3ahzLUC6ml9PlqHItQLkenD+7+lS5hyFpNP GB8tTzlqmTrp4/uilzFezJhYDg4FHMPlJBYjsP0qeYOUkFkOuKXMHKSfYh/do5g5RfsPsaOYrlD7 EP7oo5gsJ9jH900cwWD7EP7tHMFhhsge1PnJ5SM2I9P0o5g5SM2Az0FPmDlIXsB/dH1p8wnEgbTx /dqlMXKVn04c/L+lPnJ5Sq+mjH3KpTJ5ChJpfX5f0qlMhwKEulZHK1amZuBmTaQMfdrRTIcDJn0b J+7WiqEOkYtxoo5+WtVUM3TMG50Xr8lbRq6GMqJz1zoq8/LVxqGMqJzN5oo+b5PxrojUMZQOXvNF +98tdMahhKmcre6PjPy8VvCqc8oHLXmk9cLW8Khzyictd6Y3zfLXRCRzyic3daeRn5a6FIxlE565 syCeMVrFmDRjTWpBPH4VqmZNGZJDnOBzWiZm0UnjIOK0RmQMnfrj1pgRGP1GTTM2MwKoLizwHnit 2cNM567iODxUM76SOVvIeuRWTO+mzk7yPBPFZs74M5u5TGfSs2ddNmU5ZGDqcMpyD7jkVmdEfeVm fot4dnF/8F9enU4J1vRrk/7ptb9Tj3zIKmom8bRl5S/Q+b5bUay9Dja9ToebeyCgBrHCsfQE5pS+ Fij8SPR/iinleI9Lt8YFtoWjwBe6hbGAAN7gDmuDLY2oJd2/zZ246VqrXoedV6PurRnJ7zegUO0t gu1ui7pup6lo93Hf6RqFzZX0ZylxaytE6kdwykGsalKlUVpoqNWdN3izu/8AhZV5qhA8a+HtK8TA 4DXV7Ebe9IH/AE9QlXY+8vmD2rk/s9Q1w8uX+v62OlY7n0rRuP8AsXwp1zmy1zWfC94xP7jWIBqN quegE8AEn5wjHrUqeMo6Tjz/AIfh/wAEvkwtXWL5fxO+1b4Y+JpPhb4Wg8MNp/iO2k1a+vZJ9BvI 5sqiRRg7CQ+RuIK4yOMjmuSjjaUsVP23utWOytgqscLH2OqZ4BqOn6ho9x9k1jT7qwu+R5F9C8L8 eisATXtQq060dHoePKjVpSV1qVav0Jem4UCCgAoYz78+AngPSfD/AIV0zxQ0Ky6/q8Ime5bkwxMc rGuRwMAFiOp74AA+PzXFzlU9ktkezhKUYL3T6GjfpXhu6ulsdkZK+50lu+3w7et/z0vIo/yVz/Su ZtRrRR3QbVCfyKCtVSXvXM76FhWqZW6FKRMrVny32NEyYNz6UikyQNz6VNirkgOamwxwb8aLDuVr /wC2vYXqabLFFqTQuIJZ1LIkhBClgOSAdpNOnyqoubYUudxvE/Oj4oeFPiP4d8Da7efEaVru/vfE NnKuoJOJ4nX7PdjCkcIASAEwMZHrX3GAxWHq1aao6WueBiqNaNGbn1Pmnn5iASApYkDOAMZJ9AM9 a+kckt2eJyt9Bad7iCgAoAu6bpep6xdx2Gkafc3t6+NsFrEZG56EgA4HuaznWp0Feqy6dKdX4Yno V38FfinYabJqtz4Lv1tI08xwAGdFAySygk8DrxXDHN8JUlyqZ0PA10rpHlwZSSAQSOo9PrXoqSls zjaaeo6qGeifC75/E95Z9Rd6Jq8ZGMg7bCeUAjvzGMe+K83Mm40HPzX4tI7MBrXUe9ziNJ0vUdc1 Gz0fSLOW71S6YLDbQLudz349AOSTwK66mIjRpXZzRoyqVGkfR2m/sueLZoIJtV8Q6VZSOgLQJ5kz xE9mYLtP4E141TPoRTjGNzvWW3im5Hrfw7+BkHgDxAPEL+IzqE6QvCkItBGFLYy24sTkAMMY715u MzaWLgqfLY6KeGVGV1I9vlevMRbZmyv15rVIybMqVwWCjlycADkk+gFaLljuzNxk37qLSeFvEN2n nDTJYLfqZ7wi3QD1Jcjj6Ck8TRWhp9UrzRf0DStFtLrVbW/8RQXM11p9zE1rpSGc7QBKcSHCZHl8 DNYV6k5RUow26+p04WhSilCc9Wee3PiLRLAEaJ4ZgMvOLrWX+1v9RHgRD6FX+tdtPD1KsV7Sfy2O CWIo0Lxpx97ucL4g8S63rYCapqk88KcJAW2Rxj0VBhQPYAV3UMPTh9mzOWrjKtf4nqfNPirwmy3O q6tbyW9vaL86wYILnAJKgDAyT0Pf6169DEJLkaMklLd6mdomgyWqx6jeBRM65jh7xg9Gb0JHQfnW k60vhiTK1MuXZ6isl2ZlfqMtyreGvHMWckWtvLtPYC6hXd+HmAfjWe+Igd1GV6E/keYkZr07GL2I yM1IrmpoEfma5pKYzmdTzz056fhWVWX7tm9FXqHm3i2VZ9Zd1bO5d7H/AGiSTWdtDspPcyIVBIFO 9hy6GrEnSmzJs1YY+lIhmlFGTjA4pshmpBbnjipbGkbNvbHjj86ybNUjdtbIsRxWLZtGJ1Nhp59K wnI6IROttNLJA+WuaUjpUDrbLSSdvy1zuqdEIHW2Wjn5fkrnlVN4QOss9GHy/L+lc8qp0RpnV2mj dPkzWEqp0RpnUWmj9PkrmdQ3jTOitdI4HyCsZVDdUzet9J6YSsZTNFSNiHS+22s3UNFTNWHTcAVm 5mqgaUen47Vm5lqBdSwHHFTzF8pbSxHoalyK5S0tmPShyKsTraA9qhsfKTLailcfISrajpilzD5R 4tgO3FHMFh4t89qXMUkOFufTFK4WH/ZxRzDsHkN7VXMKweRRzBYPIqbhYPs4ouFhptx6U+YLDfs3 tRzBYYbYdhTuKxGbYdhRzCsRm1Hai4cpEbQdarmJ5SB7MdxTUhWKr2I54qlK5DiVJLADtTUhOBSk 0/8A2a0UiHAzZdNBPAq1MiUDMn0vqdtaKRnyGLc6V1+WtYyIdMwbnSOvy+narjU1MXTObu9HyT8n NbxqGEqZzF3o3ByldMahhKByV9o3B+XP4V0QqnNKmchfaQeTsrpp1DmlTOOvtJI3fLXXCZzygche aWRnK1upHPKByd7p5APHrXTCZyyic3cWZGflNbqRhKJhXFqRnjpWyZlJGRJDwQRWqMGUnix2qkIr Mgx/WrRmyLYaYjTngGDxWpzQOevIevFJnVSZyN9D97jmszugzj72Lk8Vmzups5a6jwTxUNHXBmJM nUCosdEWfenwiuJdQ+BHi4SbiIE064G7kYjuzb59sGbGffHesZSU8RRT8zycVDkhW+Rk16spOWp4 TjswoWwEUv8Aq5f90/yo6MlfEj074uKV8daijAhhbWgIPUEW8eQa4cv/AIK+Z25h/GPNq7mca6BQ MKACgAoGej+L2a08K/CWCJ2SaPTrq9V42KspluWBKkYIJ8ntXnYZRnXquSvsd+Im44ekovuQad8V PiDp1stj/wAJLcXumjH+hasqXsLY4GVlDA8VcsvoVHdx1Ihja9PaRZPjTwpqRB8Q/DHR2cnm50CW bSpOeuEQmEZ94zUfU8TT/hVLL7/+CNYrDz/iwuxPsXwl1L/j31zxPoMpGQl/ZwanED6GWNoWA9xE aXtMZRsnFT7vb8NfzDlw1XaXL+Ih+H1lejOgfETwpqBP3Yri9fTHY9gVukjGfYE+xNP69Ugr16bi vv8AyuL6pGfwTuX7P4HfFTUbm3t7Dwhd3UEriM31lsubaLPVmljYoABzyee1RUzfCQ0lKzZSyzEv WMdD9AvD+g/8IroWkaAkdwINOtkgV5lKltowScgdTur5LEV/aybR6ChKOjjY34pAehBrnna2pomj pw23w3FzjzL8n/vmMj+tcu9Q7pNrD77mcrmqsYOTvuWVak0aJv1J1bjpU8vmaL7iYNz6Vk7jTJQ3 pQo3LTHhufSpsx3XcerdeaVirruO3+9NxbGpIuXVlZan4avrPUbOG6s5bmNXguEV0cbH4KkEGs1U qUqsWmdCUZU3c850D4ZeAPC0+p3Gg+FLC0k1BRHOBHuDIP4ArZCjPJAAFd9XMMRWiouZxU8PSpSc ox0Z4V8Yf2f/AAU/hnxF4o8K6VLp+vWcJultrJz5M4U5YGI5AOCxyuOle1lmcV/aKlPY8/GZfRdN 1acdT8/eor7eCbV07nzbuugtTqnqhWT3P0M/ZS0yGz+Hl/qywqt1qGoSq8oX5mVAFAz1x7dK+I4h rSliPZrofRZXHlpc7PpkuepOK8CN1qenJcrueV+KPhB8O/FWnx2F94ctrbyiTFc6eogliJOThgOc nkggg16OGzKtRekjlq0KNToefWX7MnwwtLSS3uo9Uvrhm3C6uLwo6DnAURhVxz3BNds8+xfSRzLA 0F9kveE/2a/BGmeL9O1LT9X1qIYnhEDzROo82GSI4YpnpIcZPXFLE55VlR5Zbm2FwVOOITStudb4 I+Hnhj4f2Dad4etGe4di017cYkuJiRjlgBgAcBQAPbJNc1fH1cW1Ko9CKdFRuoo9Ai0nV7wf6Npl 1JnusR/wrkdWEfiZqqEpfCriSaBexHF7dWNmOn+k3SBh/wAABLfpQsRTTslcHhZr4tDOls9AgGbn XnmbPMen2rMD/wACkKY+oBrSM6s3dQt8/wDhyJUsPH7dyjLqPhy1J+y6FNdMOj6hdEjPrtjC/kSa 0jTrSl8dvkYurQp7Qv8AMzpvGGrQq0emi102I8EafbpESPQsAWP4mtlhKd7z1Mp4+olanocRqV9d 3zmW9upriTrmeQuQfbJOPwrsp06cfgRwVK1Wr8bH+E5MeKdJQ9ZvNgx6+ZC8ePx3YoxcU6DXp+Zr gJWrr5nnF4drOndcjH0rtgvduefPRs5e7fhq3SM2zlr1gc5wfrzWqQrnKXrda1RJzF2eorZAVtPk 3aZ8Qoz0TSIePc6hZn+WKm1q8Pmd1BWoT+R55XodTGWxHUdRp6G34Z+TWYJ+1vHLP9NqE5rGuvca NaD/AHiZ4zqDebqFwRyAwUH6DFLodtLRMnhTpSIvqa8KZxVmcjXgj7UCNi2h6ZFQBu21tyOOlZtl xR0VpZZIGKwlI1ijqrLTsleOBXPKR0RidppumZ/h9K5ZzOqEDuLDSsgHbXLKZ1xgdpYaQcKNtcs6 p1U6Z2Vjo/3fl71yzqnTCmdbZ6QOPk/GueVQ6I0zqbTSRwNtYSqHRGmdFbaWOPlrBzNlA3INNA7d KzczZQNiHTxgfJms3I0UDShsQOMVk5FqBejswMfLUORaiW1tR6Z9qXMPlLC2wHao5i7E6244+Wk5 DsSiCp5gsSiDNHMNKw8RCjmKsOEQo5gsO8sUk/5R2S3FEftinZy3BJLzF2D0ppPpqKUl6HD+IPiR 4C8LyfZ9a8U2EN6TtFpG/nTsfRYowXJ/Cuqjl9aq7xh+hwYjM8PQ92c9fIxH+Jqtb/b4vDd7Z6OO up+IZI9LhI6gqJSX5HqgraOATvBvX7zmeacy5oxuu9zR034gWmtoP7B0q91RiP8AX2MTC2z7Tyqi sPdc1m8FOD5akrG8cxVaNqaLlx420nTJ0s9aurO21JuF0+2uDdXJz0xFGpb9Kn6nKb93X8Cvr8Ke k9zM134n+GvDVst/4lurbQ9PYZE2vXcVm0gzj5IyS7fTGfahYVvS4nmEY6yjoYlh8XovEm3/AIQX wR4i12FiMagbQ2FkQTjIluNhYe6oaTwnstZysXHGRrfwo3PSdKn1+6jV9Y0a1sWI5jivTOR9f3aj 9a55xX2ZXOqLmvjVjZ2e9SXYaY+Dgc+9AWMO+l12Dmz0a2ulHYXpjb8jHj9a1ioS3lY56k6lP4Y3 Odn8a2WnKf8AhINJ1DSCAP3t3AXgz/11i3qB7nFdCwkp/wAN3Ob68o/xFYePEzywC/stL/tTSSD/ AKXotyl105+7lSfoMn2oWFtpKWo1jeZXtoc5J8RIrq6e00OwttRvU+/pv20Wt6PpBOiE/nj3rdYJ x+N2X3nNLMlflhT5n9xjXvxe0CyuEstStJtG1FjhbbxGHsN5/wBmUo0Te2HrSnlk2uaDvEwlnEIv las+xsL4/wBBjijm1eG60y3cArdzx+bbNnus8RZAPckVEsDNP3DeOY01rPT8Tq7WWw1S3S6067gu rVxlZraQSKfoVJFc0qc4aSVjrjVpz+BiSWQOePwpJ21voU4Jasy5tP5OV+lWqko7EuLWzMmfTg2e M1cZ3+IylDl1Zg3WlgknbWsZmUqaZzl1pS4Py10xqGEqZyt9pIwfkreNQwlTOQvtIGD8ma6o1Dln TOK1DSB83yV006pzTpHEX+lAbhtrqp1TknTOJv8ATMZ44rqjI5ZQOOvdPxnIrqhI5ZxOUu7PGeK6 YyOaUTn7i3xnjpWyZhJGTLEefatUzJme6YzxWiMxnlD2piub9xAMHitLnPA568tuvFS2dFM5C+gH IxUnZTZxl9CMnis2d0GcjeRdahnXA5+dKR0xZ9yfsvaZea/8JfjkLe4hkh0bTDLc2rPiRIvMiuI5 FUgAqJLZgcEkGReMc15eIrKliqN+rdvuJxGH9pSm0ZdfQc3upnyLvewuTTWwEdx/qJ/9w/yoezGv iR6j8YgV+JXijIIzKjD3BjQg/iK4cv8A4K+Z2Zh/GPNa7jjXQKBBQAUAIehoew1uejfEgeU3w/ss /wDHp4Xso8dcbpbiXr/21rz8Ilzzkur/AOAdeMXKoRPOq9G7itzjdn0ClG3XcTu9ie0tLq+uYLOy t5J7uZgkcUSlmdj0CqMkmpnKMLubsUouXwo+qtL/AGddGMdlJq2v3kk4CtcQW6oqE4+ZVYjOM8A9 e9eBVzOSuoqx1RppdT6H8L6BovhC0jsfDNjHp0KgBnthtkkIycu4wzHJPJP0xXkV5yxDvI66dSUf hPQrbxPr0O0LrF06joJn84Dv0YEVwywtJa2OyONrLeRpJ4mu5cfa7HTbn1860UE/iuKxeGi9tDoW Nb+LU6CTVNNbQNMa40CDbJczYWCZ4gpAQZGCc/e6Vyxpz9rL3jtnWpfV4e5uUVuPDcn3rLUYT/0y nRgP++lJqnGore8Yxq0n9ksLH4ff7upX0P8Av2yyfyYVDlV6I0tRf27Ey2WmN/qtei9vOt5E/lmk 51OxXsqb+2TLpkZ5j1rTX/4HIp/HcgH61Ptpv4kV7KH2WSDSLg/cu7CT0xdxrz6fMRUupDqV7Cf2 Ry6NqTDKi2b3S7gb9QxqVVpsr6tU7Eg0XVu9oSPUOhH4HNV7Smw+r1Owo0TWT/zDrj/vg1CqRXUf 1aouhqppGrDRp4/7Pn8w3MbAbDnAVwT+tZyqwdRG8aNRU3oZn9iaz/0DZ/8Avg1r7am1ruc7w9Rs Q6LqpBBsyB6Myj8wT/OnGoo+9cHh6jXK1oeG6x+y58N9Xu7m+m8PiymuHLsLLVI4EBPUqpbAyecC vUp5/iKHwzv8jjnlEavQ8b8V/saPuE/gzxfYwgsM2mr3KOEBIB2yR5JwNx5Bz0BFetQ4obX7xHFP IbPSVj6f8B/D/T/AXhLR/C0XiPT5xZIQ9wBKDM5JJbaFIGSemc4rwMXjZ4qu6nJuelSwlKlTUOc6 w2ukr/rdcJx/zxtC382Fct6l2lE0dOlLeZC3/CPJw0+ozf8AXNY4s/nmq/ePZWF+5h5kDXuhR/6v R55sdPPuiv57QKtU6n8xDrUl9i5d0bWbca1pEcGi2ESvdRKXZWkZQWAJDE8HBPOKitRkqTk3c1w2 Kh7VNRsYlz4l1pGkjjuUtwGI228MaYI46gZ/WuinQhJJWOOtjK6m0noc9eanf3eReX1xOD2mlZh+ RJFdEKMY7aHJOvOfxM5+9u4bK2uLqXcIYUMjeWpY4AycKBknA6CuqEU9LHNKT3TPBPDHx20PxN4j udFls2sbSQhbG6mcH7Qc4ww6KTwQB9K9WrlbpQ5rnHGvzbnsE0lcUYpLUc2mZU0nWtIrl3Rm2jGu JOuK6Ek+hk/Id4buRD4r8MS4yi6lbbh6qZVBH4jIrHFxcqMoo1wkrVkcVrAMF7ew5DbJXXK9OCRX bR1pI56+krHIXUnBrdI52cveP71qhHL3j9RVoDmbls5FbIDP0STzNJ+I8n97TIjj0/4mFnVNfv4H oU9MPM4muxbmBHUtWkT0On8Orb29l4n1e+WQWVtp8kW6PjdJLhFTd2zk/gDXNiZe+onXh4e65HhE WZHaRurZP4k5quh0vQ14E6UJGbNmBOlUyGbltDnHFSxHQ21uGwSPwrFsEdLZ2eccVlKRvFHW2NiS V+WuacjeETt9O07JUVyTkdkIHe6XpYPRfSuSczrhA77TtKG0fKK45zO2FM7ew0oYXK1yTqHTTpnZ WWlgbflrmlUOqnTOptdMHHyiueUmdEYo6K204DGFrCUmbRSNuGxII+Wsm2apI1IbID+GobZokjRj tQOoqLs0VkW0twO1RdlK3cspAOmKTuPQnEI64qSkSCMdxStJ9Bcy7jwntSaa3KTi9mP2e36UDsh2 xfaizC6YbfakVYXy/agLFa+vbHS7Se/1K8htbKEFpJ53CIgHckkAVpGlUrS5ILUxq1qdGPPVlZHy 74v/AGoNIhvRoPw30O58Sa3K/lxyqjLCW6DaAC8n4AD3r6PC8OzjH2mLlyo+VxfE8FJ08HHmZ5v4 nufGVxbLqfx3+Jcvh/TpgHi8I+GyBdTr2DBSdoPQ7iR6kGvRo06K9zAUrv8Ame34nk4mviZ+/j6t l/Kv+Aanw+0HxVrkXmfCzwZp/gTwo+d/ijV4xdajdpjlkLgnnrnp7mscXUo0navP2k+y0X4fqbYL D1qvvUI+zh3ev5mhLqXw08Oa4ljoenal8UvieSQLm8l+1pA4PJ3NmOMA/wBwHHqKyVLEVoXn+7pf ibKth8PP2dGPtKnfp/kc/wDE74s23g5Fj+M3xBlh1ecD7P8ADvwCx+0vnO1Z5wdwBOAeQD2zUUqU Jf7vC/8Aef8AkXVrSjpiZ2/ur/NDfBfhj4+fEi1DaTpdh8F/h1c/MIrOEXGt30ZyQXkcZjJB+82D 7VzYivh6LvN+0l93/AOvCYTFVtIr2cfvPofwL+z18MPAlyNXg0Z9Z8VHDSeIfEcp1G9kb+8JZc7D /ugV5lfMJ1tHse3h8so0PeSvI9u2j2rjvzbncopbaDcCpd18JQbRQAbB6UAN2+1O9t0CVuo3ywc5 5B6impS+y7EyhGXQ4HWfhr4a1Kd9RsI59F1s8jU9FlNrKT6sF+ST6OprspY6cFyz1icNbLqVX3oa S7nmPizRvFFhamDx34Ws/H3hWLkahYwCHU7MDnd5YIDkD+KIofavSw9WlN3oy5Jdt0zyMTRrUvdr x54d9jkbSw1TVNFuLr4W+K7Xxp4YUYufB3i3E0sIA5RZHAdSOgEmR6Guu8YT5cVHkl/Mtjz3SlUh fCS5o/yvR/eeY6Vp/hq+1a4tPA2var8MfiCrkS+HNTkY2Vw/dQGyOewI78A16LqThDmqx9rT7rR/ cebGEKkuWjL2VTs9fxKN54i1bwRrS2nxK8J3fh7V3J8vxN4Qb7OLjH8TQg+VKO54B9RVRw1HFQvh p3X8r/z3M5Yutg58uLjZ/wA3/APb9B+IXieGwGqwy2XjbwomN2o6OBDe2wx/y2tz3A64Arya+Apq Vn7ku2/4nvYfM60YKV+ePc9W8O+K/DXi+DzdE1BJJQMvbSDZLH/vKeePUcV5WIwlWg7vY9vDYzD4 xe47M25bQc/LWPNdG/LrZmTPY5B+X8qqMjNwMK408EH5a2UjKUDnbrTVYHK5reMzJxOUvdLHPy4r eM2c04HFajpYO75a7adU5Z0jhdQ0r7/yV1U6pyTpHB6jpYAYbeldUKhxTgcHqOnYyNldkJnJOJxN 9ZY3fLXVCRySicld2pBbjFdcGc0kc/cQbT0xjrWqZzyRkyxdeK2Riyn5Z9Ksg66eHjpVtnPHcwLy AYPFQdUWchfwfKeKDqps4m/g+Y8UmdlNnG3sOC3y1DOyDOZuI85qGzoTPqf9izxCmj/HDTNKuIY7 ix1y1uLGa1uCfs8qGNt4lXqQU8xeOQXryM2p82H037/M7KDfOux63438KWWlLZeJfDLSz+CNWd1t mk+aTTp1/wBbZzkdJUPQn76YYdTXpZfivbQVKrpNHy2Ow3s3z0tYnn/I6c16EbvRdDgkriSH91J/ un+VO901Ia91pxPTvi5keOb7II/0OyPPcG2iwfxriy/+CduYO9Y82ya7e5wJ7Bk0DF3e1AmG72oG Ix4J9qUvhY4r3kej/FM/8VJpaDhE0PSlUdlBtImIH1JY/jXBl2tJX7v8zsxy/enndej0OG2o0nAO OT2Hqe1ROSje5UY3PvjwNoWm6P4d0GODT4o7pbVGeV4gspZhk7mwDnJI5r5rE1HVqO5snynoMUlc jRaZfjk6Vi0apl5JO1ZtGqZdjk6Vm0aJnU3b48P+HgT8xmuzj2JiAP6GuKnH97U+R6NV/wCz0vmZ iyVbiYJllZOlJo1Uiwr+lZtFKROslS0aKRKH9aXKUpvuSB/Wp5UUpvuSB/WlYbm+47f7/rU8upSm 77mvFJnQ70Hol3B+qTZ/kKxmv3kV6nRTk3Snr2MrfW3Kjm5n3DfRyoOdkZf0quVBzPuNL+tPlRDk yNnppC5iFpPeqSFzEDSVViGyu0lXYzcibTZ/L1TTZARlbiM5PThgeamrDmhYqhK1RMpasRFqOoRA EBZnAB6jDEVtSV0mZ4h2qNGK8natkjlbM+Z1YMrjKkEEHoQeoraOmpk30Pz/APin4Bl8Ca3HNZzN JpF8zy20gUqYCGz5ZI4yM8Edq+qwGJVelZnBWhyO6PU/hT8WDfJB4Z8TXIF4i7bW+lbHnAcBGJ/i 9D3+tceNwHsoqpHZjhU5lqe7TSYyK813iwkzFuJck1uldGbdinY3CxatpcrNhY7qJifQBwSaVRXj YdF2qIzPGLNF4k8QxMMOt7OCB6hzWmF96CYY3+JY8+upM5rqRynM3knJFaJAcxdv97NaNWE3c4zW rqSCJPKIDO23PcDBPH5V0U43NIxF0Bivh3x9L1LWVvESemDeQMR9SYx+GaVVfvYHZS1pTOMJzXUt jntZlmxsbrU7u3sLGLzLqc4Rc4HTJLMeAAASSegqJVFB3LhBzkkbnjHULTT/AALNpWmS77OW+EIn Awbp0XMsgHXGXiCjsB6k1yKLdTne53xf2VseIQJ0rcbZuW8fTjNBm2blvFuxigzbsdHaw/dHrUNg dRZ24OOOKwkzSKOwsLMkAYrnlI6Yo7jTbDO35a5KkjrhE9C0vTslfkrjqT0O2ED0TStLHHy/pXBU qnZTgd/p2mDj5a45VDuhA7ey00AL8v6VzymdUIHWWen4x8v6VyykdMYnxZ+2l8VvFHw7g8D6D4M1 +50rVb15ru4ms3CuYkAVVJIPBLE/hXsZRhKeIblUV7Hz2fY6phYwhSlZnwUP2kPjqvT4n62P+2w/ wr3nl+FtrE+ahmuMktJXJl/aX+PSEFfilrgI6fvgf0Ipf2dg1q4r7y3meOfups9v8LfHr4z23wZ+ JfjvWPiLq097Je2OhaO8si5hnYmed1G3qIYwM+kn0rz6mCoVMRGEI6ano0sxxkcPOpOVtrHjI/ai /aBH/NVdb/7+p/8AE13LKsLonE8x5zjXrzgP2pP2gx0+K2uZ/wCuif8AxNP+yMIrpwKedYxu/tCe 3/ae/aLu7iC1tvinr0lxM4jjRZEyzEgAD5epJrOWWYLkd4FwzjHSaUZn3L8dv2w9e+FNhpXwo8FX aar4/wBMsYLfXPE+ogTCO6EY8xUUYDS5yWYjAPGCQceJgMmWKm6tRe50R9BmGezwtNUqb9/qz8/9 Z+NXx38WGfVb/wCIHiqeFCS8tpdTQxR98YjIUAV78cDgqOllc+clmGMrapto6b4c/tV/Gr4d6tZ3 kHjO/wBX0uNwZ9K1qdrqK4TIyuWJZSR0IIIrPFZThsTB2jbzNcFnWIw01zSuj9Zfjt8dDpP7MEnx U8IXsthqXiC1tE0uVSPMt5ZyCwBIIyiiTt1SvkcFgObG+wqbI+2zDMnDA/WIOzZ+WPhH9ov9pLxX 4q8OeGLL4ra2brVb6CzjAMZO53C5+52zX1VfLMHSoubgfGYXN8bWrRXtOp/QFbQtBbwQPM8rxoFa WT70hAAJOO56mvzypZvlifqFOT5bs86+JPxQ8P8Aw304TX7G51ecE2unREb5SO7HnaoPVj+GTXo5 fllTHT5bWj3PKzLNqeX0rp+92PilYfib+0Vr7x3d4bfQLZ90uMpaWKHn7ufnkx0yST6gV9fL6pkl FJK83+J8O3jM9re87Q/I2NS8WeGvhpG/hD4N2Au/EUv7i68USxiWaVzwVgGCOvAIGPQHrUQw1bHf 7RjnaH8prVrUsv8A3GCV59zuPCvwp8PeBbCT4m/Gy9+262586Owum84hyMgFST5kp/u9B36ZHFiM xq4uX1TBK0Tvw2XUcHH61mDuzMm1v4gftA6hd6dp0x8N/DSzJ+1TBtoEYGSJGGN5wM7AQgHJ9TTo 4fJ4qUvfqsj22IzqbjT9yitz5/8AEfxqurrW0+Av7H2imbVbpjBf+MVAaW4xw7pIRhIxyTKeB/AB wSOlKa+tY92S2iJVYx/2bLlr1Z9bfAT9lLwj8JfL8UeIpf8AhJfihcHzbnXb/MogkPLCANkg56uf nPqOleHj80qYj3KekT6PLcop4dc9b3pdz6wryb33PbslsFIYUAJgUAGBQAYFABgUAJj/AGf1oATB oANo9qd2hNJ7niXj/wCEMOt3beLfBV62g+PYQWS9tTsS7I/gmUcHP97H1yK9fA5o4R9lXXNA8PH5 R7SX1ihLln+Z4w2oeHvitJJ4B+LekronxGsyYbbVo0Cea/YZPHPBAJwexBr2VGpgl7bCPmpPdHgy lTzCX1bFx5Kq2ZzD654k+G92/wAOvi7pn/CQ+CZxiCeUeY6R9BJC55OO6k5HYjv0xpU8XH6xg3yz 6o5JVZ4KX1THR5qfcwPEXw91j4dvbfEj4Ua9PdeE5sOLi3bc9spP3JV6MueDkcdCAea3oY2njP8A ZcYrSMcRgKmBf1rBSvD8juPCeueHPilNCH8vw58TIxmO4tSY4dQYDkgDkMe46/UcVy4rDzwGtuel +R24LE0sxWr5Kq/E9d0LxrrGj3h8P+OrYpcIQq34XgjsWA4IP94fiK8ethKdZOth3p2PZw+YSw0v Y4la9z1cxxzRrJGyvG4DK6nIIPQgivJ1j8R7d4zjzRM6a1HI28+tXF8wpLnjoYlzYgqePxrZSMHA 5y808EH5K3jIxlA5C/07Jb5eldUJnNOJxGoaZ97KfSuinM5JwPP9R0373y13U5nFUgee6ppv3ht/ Cu6nM4qsDz3UrAjdxXZCRw1I2OHv7TG7HFdkJHJUicld245rpTOWSMCeLGa2TOdqxRKHJ4NUTY7O aLtjkVpY5EYV3FkHiixvFnJX0Iw1I6abOJ1CDluKTOymzib6H73FS0dkGcrdRdeKlo6Ys0PBHiaT wN438JeMYoxIdG1GC9aMkgOqOGYHHOCAQa58RS9rSZ10H71j9DfEWtW3gf4k+O9FvbMan4C1y7F3 daarYE9vKPOimhP8EqCUlHHTkHKsQeOjS+tUIVaWk431/roePXmsHiZU6nws4jxp4QTw49lq2jak NX8E6oSdN1qJdokIALQzLz5c6Zw6H6jIINd2Gxar+5U92ot1/X9fM48Rhnh/3kNYPZnDk5BGeort k/dZxRV5JM9L+KMnma/olzg7bnw7o04B7BrCA4z3wTjNcOVu9D5v82dePX777jzkEY616Hc42rWH UxBQJhQMRj8pPtSl8LHF+8j0f4pH/iptPH/UD0n/ANI4q4cu/gr1f5s7Mc7VTzkuACTwB1Nei3aJ w31Ppz4P+D7W30z/AISDVtLU6jPITavcLkxxDABVTwCSCQ2M46YBOfFxtZzlZGjfKfQUUnSvNl78 rom/MaEUlYtXNEy/HJ71m0apl9JOnNZNGqZcjk6VDRomdVfP/wASPw1zyTcnHsXQA/pXJTX7yZ6N V/7PS+ZlpJ71djnTLKyVDRomWVk96ho0TJlepaKUiYP61Ni0yUSe+akpMeJPelYdx3mU2tRuWpsQ v/xItR/6+7b/ANAnrmqL97D5/oddF3oz+Rk7/auixy3DzB6iixNxhkzRYbYwyelMhsiMmaqwNkLS VVjNyIGk96aRLkV2k61qkQ5EKz+XLHJjOxg2PXBzTtdWFGVpIteJW8vX9ejznbeTDPriQis8G+al FmmNfLXaOZkkrsSOBsoSycmtUjJs4zxb4d0vxbpE+i6qpMDkMsiY3xMDwykg4PauihUdCSlEh6rU +CvFWhP4X8QajobXKzvaOAJ0G3cCAwJHOCAVzz1r6rD1FiqSbOR76Hu3ww+JUupiDw1rkrPfgEW1 y3WVQM7WOeSB0Pf615uLwihqUmeuzzdfmrgWmhnJmYsg+12p/wCmqfzFOS3Kp/GM8dyf8Vd4p+b/ AJiFx/6Malgf4KNMZ/FZ5xdSdea7UjkOau5OTzWiA5fULiOGN5ZXCRjkk1rFczCKPNtQvjeTb+RE Puqe3r0rshHlNlodBpbeX4K8Xyn+O70+3H4/aH/9pdf8awqP97A6qfu0pnKW1vcX11BZWcDzXc7B I4oxuZ2PQAVtJ2iZRXPI6a/urbw7Z3OiabOk+qTjZqF/EQyqO8ER7gH77jqeBx1wjF1PeeyNm/Ze 6t2cR48l8iPw1oYODa2YuJl9JJiX59whQH6U4fE5PqbR0SS6HG26citAZvW8YwPU0GbOhtIs4wKz bEdTZwZAwOtZSZaR2FhbD5eOtc8mbQR3enWn3ePSuWcjqhE9D0uxB28Vw1ZnbTiek6Vp+SvFcVWZ 6FOB6PpWncDiuCpM7qcEd7p9gAB8tcc5nbGB2VpZAAfLXLKZ0RgdJa2gGOKxctToUT8Sf20PFg8T fHbxDZwyFrPQYYtLQZyN6LvkwPUO7A/SvuMlo8lDm7n51n1f2uLlDoip+zP8Yvhp8H7zxTqXjvwZ deILvUI4oLVYYLeZLdFJZyRIRgk7enYVWZYSti0vZStYnKsdQwfMqsb3Ps/w/wDti/AfxHrmjeHt N+B10+o6ndRWcCnT7DDPI4QZwc4yRXhVcpxVKDqynoj6DD5zha8/ZqlqfdXiH4QfDHxZp9ppOv8A gbR7vS7aZriK0a2VI0lIClgqgDJAxk18/HGV6M1aep9K8vo1Ics46H5g/t5+CvhZ8N7XwD4b8C+C tL0fWL95726nsotrmBAEVScngszH/gFfVZDicRW551ZXWh8dxLhqGGUYUY2Z8+/sh/DbTPih8btA 0XXtOjvvDtlDNqF9bTLuSRETCqw7gyNGK9POcTPDYdyi9TysiwaxmJjGSuj9lj+zd8ENIB1XRfhR oC6zY/6RaMtvys6fMhGTjIYLXxMczxEqii56H388pwlOEnGGq2P55PEFzqF5rut3ertK2rT3c0ly Zs7zKXJctnnOSc5r9Ew/Kqa5Wfl2Ic51XddT7r+AX7a+nfDDwRp3w38X/Du31Hw7aq8Yu9LKRyyo xJPnRMCkhOSCcjI65rwsdks69T29OdmfQZZndHC0/Y1YXR7l8KfhN+wz8bbie38I2t/Hr5DTSaLf ahcW1wozklELEMBn+AkAdcV52LxOZYKPvvQ9XB4XKsxl7i944L9viTRPAPhH4P8AwS8KpJBoempL fC2eUyFUBMcW4sSSctNya6uH4yxNSdee5y8SuGGp08LTe1zwn9hrwcfFn7QPh+7mhL2nh+3n1WQ4 4VkASPP/AG0kU/hXfn1f2eEcIvVnmcN0FVxkZS2R+2/j/wAZ2ngbw7c6xOokuz+6trYnBmlIOAe+ B1J9K+KwGDlia3J06s/QMxxscHSu9+h8I6L4d8RfFvxqftt08t3dOZbq7cZFvEDzgdAAOAPpX29a tTynD2ifB0sPVzbFc02eofFPxNYeFdLT4V+BF+y6dbLt1G5iOHmcjlCw5JPVz+HQEV5uXYeWKn9a xHyPQzLEwwq+qYb5s3Pg74D0jwboM/xR8WxKrpCZLNJACYY+gcKerueF9vrWOaYyeLqLCUdup05T gI4Si8ZiNex57LH4k+PPjyKK4kkg0mIlgg+ZLG3B5IHQyH5RnufYV2/ucnw91rI4Je2zrE8v2F+B 8/ftd/G82s9v+zR8HVeLToHS01aWwJMl7cMQBaqRyckrvPcnb0BBzy7COd8di+pebYtQSwGD0726 n3B+y/8As+aT8CvA8EdxbxS+O9VjSXVr8AMVYjIgQ9kTOOPvHJ9MfP5tmE8bUtF+6j6TJ8rjgqV7 e8z6bry2oxVj27tK8UFIAoAKACgAoAKACgAoAKADA9KAEwKd03ZEyjzbnhXxs+GMHjHR21zTLcDx NpyF0aMYNxEOSh9SOq+/HevayjMZYefsamsWeFnWWRrwVen8SPLvBesWPxW8NyfDjxs+7W4EL6bq cnMhKjgEnksB19R15Ga9XFUpZfXWJofC90ePhK0MzpvCV9JLZnEeCfEGr/CjxPqHhnX4Wl0GSUwX 9k43Lg8CRQeDkHPuPwrrxVOnmNJV6XxI4sFWnlmIeHqq8BnxW+GUXhHUbPxL4YYnw1fsJbeWFj/o zkbgFYc4PVT+Haqy3HLFQdCt8SDNcB9Tqe3ofCz2LwH4ig+KHh+TRdbaNfGGmx7o7lhg3CDgMfXn AYfjXk42hLA1eeHwPoeng6tPMqKhL411E8PeOT4Y1KTQdcVorRJDHIr8m3bOMj27n8xSxGDjiYc8 AwePeCq+wrHvOyKaNZY2V43UMGU5BB5BBHrXgyThLkPqItVFeGxQltxg8de1NSJaMO6tPvAD6it4 yMnE5i8sgc8fjXRTmYTgcdf2AwxC10wkckoHA6lp/wB44/Su2nM4qsDznVbD73FdtKRw1IHm2q2O C3Fd1OR59WJ55qVpgscV3wkcVWJw99bctxXXFnHJHMXMIGeK6InNJGZ5R/yK1MztZY/arOJGLdRc Gg1icrewcNxQdMWcXf2/Xig6oM4fULfG7ig7IyORvIeuRWbOqLOcniB3AjIPUGk1pbudFOXLZn2/ qOqN4s+G3wi8clzJdPpZ8P6hIzBmN3YN5QLEd2gaB+ecEVwYCXsqs6HY5M6p8zhV/mJvB/je88Lm +sLizi1XwnqW1dS0K7YiK7UHhgw5jmXqki4IPqMg9OJwvtX7RO0lszzKOIVL3HrHqjY1/wAFW50q Xxf4GvJtW8HIwFyJADd6K5PEd2ijgHoswGx/Y5QZ0ca9aFdWl0fc2r4RWVai7x7dib4hSedZ/DW+ HS48NWi5BJB8lpbc9feHtVYKVpTh2M8bG8Y1Eebbl9a9BJLY4Hd6scD3FVcQ7d7UXAXd70ABPynP pSl8LKj8SPSvimT/AMJNppx8raHpJU+o+xxDI/EMK4svX7hLzf5nVmK5qt/Qp/DWzsL7xhpqaisT QRB5VjmIxJIBlAVPB55xWuKcvZuxywla7PsaOQ55JJ7k968VmDkzRik6c1m0NSZoRSVk0apl+OSs 2jRMvRydKho1Rcjk4rJo0TOs1J/+JP4X94Zv/RhrkpR/eTPRrP8A2el8zJST1rW2hzplpZKzaNEy wsnvUOJopE6ye9Q0WpEwk9alofMSiTNTYq48SetFh8w7f7UuXUblobML/wDEg1M5/wCXy2/9Fz1y 1Y/voej/AEO2jL/Z5/IyPMrpscVxvmf7VFh3EMmKdg5iMyYqrEuVyIye9NRIciFpPeqSJciFpPWq SJbKzyVaRDZVeSrtuQpe8aXi2QL4i10k8tdSMfqWJP6mssFG1GKNsfL9+/kcpJLXYkcDZnySdea0 SM2zPlkrS3YzcrHi3xI+Hmk+JLO81WytRB4gijZ1ktkGbogZCyAfeOBgHqK9HCYt0dCNJHzF4H1a 30XxZo19f7Ut45SkjOD+6yCCx4JyCc9K9jEL29NsUEfXTX9rOE8m5ifeu5Qjhsj1GDXi8ko6NGUl cbYSK+r6SjAFWuoVIPQguARWdR2psvDv30jN8aTtJ4m8Ru75dr2cknuS5q8LG1OI8W71Wzz66l61 1rQ572Ocu5OTzVpibPPvFF3EsCW+4GZ3DbfQDua6qMJP3maU1F7nC7zXTJrfc1s0ejaPo2o6v4I+ zabCrtd6y5klkYJHCkFupLyOSAqj7TyTj8a8+rWXtVdbHdTpN03Z7mZd6zp3h+1n0nwvOZ7yZTFe a7gqZVPBjgU8pEehJ+dvYcVrGEqsk5vTsZupGldQWvc4hWHQflXU9EcusmcRd3DXd7POWLDdgEnJ wOB1rNndDRF+2Q8cUgbOhtU6ZFBB0tnH9zismB19jF04rGTNEdvp1vnacVx1GdEEeiaZag7OK5ak jthE9L0my+7gV59WR30onpuk2I+XivPqyPQpRPR9LsgQOK4akjupwO5sbPgfLXJOR2RgdTa2oGOK 5pTtc6FC6SLuo3ltomk6nrF6QtpYW8lzKx4ARELMc/RaKV6k4xQ601TpSn2P5qvFOuXPibxLr/iK 9kLXOp3k13IWOTl3Lnn8a/S6EY0aUYn5Jiakq1Zu3U/Q/wCF/wDwT+tvHfw/8JeMdZ+IF7peoaxZ JetYR6csghR+UG4yAnKFSeB1r5zFcQTw1SVOELo+owfDUcVSjVlUse9/C79gnw/8OPH/AIY8dP8A EG81U6Ncfao7CXTkiWVwpCksHJGCQenUV52Lz6tiaLo8lkz1MFw5SwVeNVVL2P0CxivnVapo+h9V FOKuz8E/24fGR8W/tAeIrSKYvZ6BBDpUa5yAUG+TH/A5Gr9AyKgqWGXmfmPEdd1sU03oj6i/4Jre Ddlp8RvH88RBlkh0m3cjso82XB9y0WfpXlcTV5XhTXQ9vhKguWdSW/Q/Qf4hfFv4efCmHTJ/H3iW DSItRZ0tjMjt5pUAnAUE8Ajr6185hsHWxb/drY+pxeOoYNXqvRnwx4y+G37In7T3jN4/BHjsaZ8S NTV5mfSInCXhUFmeSGRQpbAJJUgnqc179DEZjl1O1aN4o+ZxGFyzM6n7qVpM+Qfj7+xz4x+BmgN4 wk8R6brPhUXCW7TRA288TOSF3RMSCDj+Fj9MV7WXZzDGVPZKNmeBmmRyy9e0Uro8H+DL67H8Wvhu /hmSVNdOtWi27Qkg5MqgjjsQSD7ZzxXbmHs3Qkqmx5+XSqRxEZU9z2P9tTxn/wAJh+0D4vWKXfZa IItJi5yMxLl8f8DaTNcuSUVRwyfc7c+ryrYpvsfYv/BNjwb9m8PfEHx7PEwkvbmLTLdyP4IlLvg+ 7SKD/uV4fE1d88aceh7/AApRtCdRrRntnxp1ibX/ABZLYI5NhpY8iNO284Ln65wPwroyakqWH55b sxzrEutiORdD0jwRYQ/Dv4Y6l4oaNRrF/H5ikjnniJenTJyfrXBi6jx2NjReyPSwNJYHAvEPeR4J 4S8My+K/FmnWN0WkFzMZbhzySoJZyT7gNXtYyusLQbXQ+fwuGeLxSj0Z6/8AHbWmll0zwfYnZZWy LNNGnAJxhFwOwHOPcV5WUUrN131PZz2vdxw0ehzviHxHD+z/APs8eJ/iAqovia/hAsy45M8vyQDB 6gAmQj0BqKrlmeMjRb0RVO2VZe6y+KR8DfsG+Az4/wDjZf8AjbXVa7i8NwtqLSz5YyXsrFY3YnqQ fMfJ7gGvWz2t9WwqoRe543DmGeLxftpK7R+39fCn6NsFHyHfzCgL+YUBfzCgL+YUBfzCgL+YUBfz CgL+YUBfzCgL+YUBfzCj5BfzCmnZ3E1zKzPh/wCIfh+fwf4+nvdJJgVpFvrZkGNhJyQPYMDx6V9n gK8cXhlCe58FmFGWBxvPHY7D4raXbeKfDnhz4g2UKrNLGsF2FHQnOM/Rgw/KuXLajw9aeGnt0OrN KSr0o4qnuzY+GDQ+MfBWt+AdYO8wJm3duSiE5UjP91/0IFY5inhMRHEU+pvlcljcPPDVOh4do51L wV4ogvEUpeafcFJEGRvAJDKfYjcK9itbGULPZnh0JSwGKTXRnpX7QOnwwWeh+PNOx9lvAsM7KOGy uY2PuRuB/CuDJai55Yaa2PSz+FNRp4qGz3NP4AfERdftbvwjfTh7yyTzrVmPLRZwy++CRj2PtWWe 4D2M/bQWjOnh7M1XvRk9UfRkkfBr5xM+naMyeHPbmtEzNxMC6thySPwraMjKUTlL6zHPFdUJHLOB w+o2QO7iuqEzkqQPONWsgN3Fd1OZw1IHmer2X3uPWu+lI8+rE8y1S127uK76cjgqxPPtQg+98td0 GcNSJx13HwflrqizknExyvJ4rW5hY7aWOtjguZNzFwTQaxZzd5BnOBQbxZx9/b/e460HTFnEajbd eKDphI4y+t/vcUmdkGcvcwjnmo8ze+lz1b4YeLr2LStW+Hk+xtKu7n+17YFMvFdpHscKR0DxKufX ylrldL2dVVl1HjX7Shy9ju1mruTe72PntOhv+HvE+ueFdVh1nw9qUtlqMalC8eGWVDwY5EIKyIRw UYEEdqxrUIYmPJU6GtKtOg+aPzPobX7Hw58UfAXw81nTbjSvC3imJ9Q0mPR5SYNOvXjnF04jnZiL eQm/BCP8nz4DDFeHQqVMFi60HrHR367W2+XqexXhTxWGptO0tdD581nR9Z8O6lc6Nr2l3WnarBgS Wl5GY3TIyDg9QRyCMgjkEivfoYinXivZO54tTDzpNqojM3fWuixiOEmKVkA7d9aYAX4OaUtmSt0e l/E9j/afhNxgpJ4b05lIPDAIykj8QR+FceXvRo7cctIs43QLVdR1zSLF5JESe4RGeE4dQTyVPY4H BrprSTg0ccY81mfcNttijSJGYogCgu244HTJPU+9eI1qcjlqakUlZNFqSNCOSsmi0y/HJUNGiZeS WoaNVIuRy9OahxLUjrtUk/4k3hXnrDP/AOjDXHSX72Z6Nd/7PS+ZjrLWtjmTLKy1LRSkWVmrNo0U idZalxKjIlEveoaNOYlEvvS5SrkiynpU8o1IcJT/APqo5dQ5tDagl/4p7Uz6Xtr/AOgXFctVfvoe j/Q7aMv9nn8jG8yunlOS4hlxRyiuNMuaqwnIYZff8qdieYiaX3p2E5ELS07EtkDy1aiS5FZpatRM 3IqvLVW3JUveNTxhJjxLrXoZ2I9wcEH8QazwatRVzbHP98/kcjJL15rrSOFsz5ZevNaJGbZnTTVr GNjN6mZNKOc8j0NaQtcnm5T4N8aaauheKNa0xeIo5i0Yxj5G+Yfo1e/QmqkEUmZWh63PoOq2erWn MkDZZM4EiHhkJHYgsD+fWqqUYzi7Ex1PsLwLrNn4l1bwjd2e54LnULaMoR8wJmQFSBnnmvCxkfZ0 5NmtCP75Gd4lumuNb1mZmBZ7qVsr0OWJ4rSgrUzGu/fbOJupetdNjnbON17VotNt2lkYeaciOMnB Y/4DPNbQhcuEbnjtxeS3M0lxO+6Vzlif5D0ArtSSjbodEU0+WK1O1tPB62FpDrPje9fRtLlUSQWY TdfX6nkGKE42KR0kfA9A9crxOvJR1Z1ww3s/erM2fGXiFH8G+C9F0azOlaDdLc3zadFKzmUidoke ZjzI5EWc4AGRgdKww1O9abk9UbYmdqUFHZnlPme9dyXLK6R58td2U7+68i0lcH5yNq/U8UzSCuzm LdOBUHXsjetU6YoM7nR2idKkR1FlHytZsEdnp8X3eK55s2id9pkGdvFcVVnXTR6XpNvkpxXDVkeh Tieo6Ra/dOK8+tI9ClE9Q0q0+7xXn1ZHoUonomm22FHFcNSR2QR2lnb4VeK5ps7Io6G3hxjjFYTl oawVtTwT9rHXNU0H4F+MIdE0+9u9W1hE0uGOxheVx5pIc4UEgBA+TXflUIzxMVI83OXKnhJcvU/C j/hX/jz/AKEnXv8AwWz/APxNferF0lG3Mj81eFrqT91nSR6b8aYY44YbDxrHEihUSOK8UKAMAAAY AA6CsXPCy1k1c3jSxtO3Jex7T+zz4R+Kvij41fD3Stej8XQaINQS7u3vDdxxmKEGUglsDB2AYPXN cGY1cPTwsnG1z1Mqo46rioxnex+8upXqaZpuoalKrNFaQPOyoCxIVSxAUZJJxwBXwVOPPNebP0ar Plp3XRH81fi3RPiB4q8UeIvE114P14z6rez3jFtPmyu9y2PudgcV+lUK1KlSUItaH5NiqOIr1nKU XufuV+yD4Hm8BfAPwTp95ayW+qagj6ndRTIUdXmYkBlIBBCeWMEdq+GzjEPEYqVtj9FyLDSw+Fje Opyv7Z3wN1z4z/DzT5fCcQn8V+Hrh7u3siQpvImXbJGpJADfKpGepGO9a5NjoYKtyy2Zjn+Xzx1G 8d1sfh28Hi/4feIIZpYNV8P+JNPl3RuyyWs8Dg4ypIBB+lfeOVHFQ3VmfnHssThJ6J3R3F/4g+OH xtuLDTL/AFHxT4vljbFvbEzXSIx4yFAKg+5/OuaKwuBu4pI63LF49qE7s/R39l79lS/+DlvqHxn+ Kdqn/CS6ZYz3GnaJFiZrICMlpHK5BlK7gFGcZPfgfO5nm0MVJYelsz6bKcllg1LEVd7aH5f6/oXj vxDres6/e+E9aa71K6lu5WNjMSXkcuedvqa+mpV6VOlGEWtD5Svh8RUq3knqz95/2U/BUngD4C+A tKu7V4NRubU6jdRSqVdZJiZMMCAQQCo59K+CzSu8TjJNbH6Pk9D6pg1Te9jyi/snvtVvJmJLz3Ds SfUsT/WvoYTUKVvI+Tq/vMRd9z3f4rxeR4T0PSoRiEyIuB6IhwPzNePlvvV5VJHv5unDDxitmcp8 GtLVfEN9dso3Q2pCn0JYD+VdObVXOCh3OPIYL2sm90cf4qtn1nxlq0jEnzrwxKfQAhB+gWunDP2W F5Oxx4r9/i3J9zwH/gpF4hbT/DHww8D2zlLee4nvZIweGESLGnHt5jVPDtJVKk5vc24nqclKFJHl H7Efx0+E/wAG/D/jpPHutyWGrapeQGFYrSSYvEiHnKggfMx4Ndme4HEY2pH2UdEcfD2Y4bA8zqSs 2fcX/DcX7OH/AEOVz/4L7j/4mvn/AOwcZ/KfTf6x4P8AmD/huL9nD/ocrn/wX3H/AMTR/YOM/lD/ AFjwf8wf8Nxfs4f9Dlc/+C+4/wDiaP7Bxn8of6x4P+YP+G4v2cP+hyuf/Bfcf/E0f2DjP5Q/1jwf 8wf8Nxfs4f8AQ5XP/gvuP/iaP7Bxn8of6x4P+YP+G4v2cP8Aocrn/wAF9x/8TR/YOM/lD/WPB/zB /wANxfs4f9Dlc/8AgvuP/iaP7Bxn8of6x4P+YP8AhuL9nD/ocrn/AMF9x/8AE0f2DjP5Q/1jwf8A MH/DcX7OH/Q5XP8A4L7j/wCJo/sHGfyh/rHg/wCYP+G4v2cP+hyuf/Bfcf8AxNH9g4z+UP8AWPB/ zB/w3F+zh/0OVz/4L7j/AOJo/sHGfyh/rHg/5g/4bi/Zw/6HK5/8F9x/8TR/YOM/lD/WPB/zB/w3 F+zh/wBDlc/+C+4/+Jo/sHGfyh/rHg/5g/4bj/Zw/wChzuf/AAW3H/xNJ5FjFryjXEWDbtzHYfFY WXiDTvCPiXTn8yzvbfzIpCpUtE6q6Eg4IyDnBroym9OUk+hw55arGM49R3hG1OpfDXxTo0o3CAvJ GD2OA4/UZqsVO2KjU7k4Je1wM6XVHK/C7fpvi+xIJCTo8Le4IyP1UV1Zj+8o6bo48pm6OJSfUPih oiQ+L76aNMLcokxA9SME/iVoyyu50Un0HnFONPENxJvHdrPrP7OeswpBJPd2CBoo4kLuSkoICqAS eD27VGCnDD5qpSejNscni8lahHVbHxR8J9Z8VeE/iF4W1mXw/q6Wi3SxXH+hygGJ/kbPy9ADn8K+ vzaNDEYSUVJXPi8nqYnC4yEnF2P1wdAc1+WPRtH7AnzJMpTQ56fnVJgY9zAxzxk1qmZNHNXtvyeO tbwZhNHF6hbfe49a6oM5akTzrVrXdu+Wu6mzgqRPMNXtsb+K9ClI8+tE8u1a3+9gV30pHnVYnmup Q43cV6FNnBURw17HgtXZFnJURzzINzfWtjnsd5JHXQeZczJ48g0FIwrqHIOBQbxOVvrfO/ig6Is4 q/tuvFB0xZxV9b4B4oOqLOSu7fGeKhI6EzLtrmfS9QtNQtjtntpFkU4zyDnBB4IPoamcbm26sfQ1 zKkpj1C3H+g3aiWF87gQwBwT3IyQfcHFFKZ4tSl7OTZEJfetL2Zi1eNj1GxkGo/CDxDDjdJouv2d 2BjOIrmGaKVs9sPDbD8a4KqccVD+9f8Ar8zuglLDO32RNE+Jt5Dptr4b8X6ZF4n8JwArDY38hS4s ATk/ZLoAvFzzsIeM/wBzPNVVwacnVw/uzIpYySSp1/eiaz+AtI8UL9q+FfiH+1JyCz+GtW2Wmpw+ ojBPl3AHYo2fbPFKOLqUnbEK3mVLCUqutB38jzK7gvNOvLnT9RtJ7TULdiktrdRtFJEw6hlIBB9i K74Tp1VeEjhnSqUnaaIfNA71tqlrsZvTfcUSdc1N1shxd/I9M+JEokg+GN1yBP4StGx2Urc3cZAP f7in8a87BytVqQ7P9Lnbi1anBnFaJDeXus6Ta6cm+/kuEES5x8wIOST0Axk13VmowZyQWtz7ihlO AWYFj129Ce5H414rRwTeppRP0NQ0EXY0I5elQ0WmXo5PeoaLTLySjioaNEy5HL71m0aJnX6rJ/xJ fCfPWCf/ANGGuOkv3sz0MQ/3FL5mMstayjoc3NoWVl96mxSZYWUVNjRMnWX3qGi1ImEvepcSuYk8 0DvU8pXMSCX3/KjlHzD/ADfcVHLoVzaG3BJ/xTuqHPS+tR/45c1zVI/v6fo/0O2jL/Z5/IxfO966 rM4+YQy4osHMNMvvTsS2RmUetNRFzETS+9NRJuQtL71XKS5EDSgjrVKJDZVaWqSJbKsko55qmtyY v3jX8ZS48S6wn/POXyyfdVCk/jtrPB60kzfHv98/kcdJNXZY4GzPll681diGzOmn681okQ2Zc03B rRIls4LxR4Y0TxLbzR39jCbpkIS7VQsqHBAO4DJA9Dke1dFOXJJDjU5dD4u1O0utJv7vTb2PZc27 lGyMA4PBHsRyK9qE1UiU11PoH9mi/MnjjTtPZ1CxajZ36LnBJSTLH1wAoJrx84gpUGu524JKU1rq jqNRnDXFywOcyMfzJNKi/cR5tRyUrHEa9rVno9q93eSYXoqA8ufQf1NdFOCkxQhzuyOSsfAfi7xY Ytf154NA8PzDdFf6yxhDRDkmCHG+UAHqBgnvmnLGUqL5Yay7Hp0sC7c0tI9zR1fXPCvgW0tIPAmk m51wMQ3ifW4xJNnrm3tiTHFjszB3HXg9M4Rr15OVV2j2NFWpwX7la9/+AePX2p3moXNzqGo3k11e ysXluLiRpHkPcliSSfrXeoxgrwVkjk5qkpc0nqdh47b7LfaDo+MHTNJs4JBn/lqYw8n/AI+7Vhhn zw9p3OnErlkqZxHmV02uzktq2YOqzmWeODPyoMn6n/61JnVSjYIE6cVJctTetU6ZoM5HSWidDms2 SjqrFOlZyHE7XTo+VrmmdUD0PS48lc1x1GdlNHp+kQ/crzqjPQpI9V0eEYXivPrM9Gkj0/Sofu8V 59RnoUkeh6dEMDiuGbO2COutY+FrmkzqijdhTpWd21qaWSeqI9Yi1p9OmTw/PZw6qceXJfxtJEBn ncqkE8dMGnQai71CcRGrONqZxy2Xxg/6DXhP/wAALj/47XZ7XDdmef8AV8Vf4l9w8Wfxh/6DXhP/ AMALj/47R7XDdmP6vif5l9w/7H8Yf+g74T/8ALj/AOO1Lq4V/Zf3gqOLWql+Av2L4w/9B3wp/wCA Fx/8dpe0wv8AK/vH7PGP7f4B9i+MH/Qd8J/+AFx/8dp+1w38r+8n2GK/mX3B9i+MP/Qd8Kf+AFx/ 8dpe0wr+y/vKVPGLaf4B9i+MP/Qd8Kf+AFx/8dqfaYT+UFSxn85m3nh74m6iQ1/c+Crlh0NxpUzk fTMhrRYnDLa/3mUsLipfaX3E1ronxUsV2WWo+DLdP7sGmToPyEgodfDPo/vHDC4qP2l9xa+x/GE/ 8xzwn9fsFx/8dqefCb8po6eM25/wPJfi98Rvi78JNC07Xp4fDOq2tzc/ZXWG1uIjESpYEkyHOdpF erlWDw2ZzdOLaa8zxM4xmMyuCk4pnH/Bb9pPxj8SfH1h4T13Q9JtLC6hnbzbUSB9yIWAG5iOceld ubcP0svwzrRld/8ABOPJeJMRmOJ9hUhZM2L2WG01K6iaPDwzspB9Qx/wrOC5qSt2M5e7Xae9z2P4 mPFN4e0S+ADQlwc9sMmR/KvJy9fvZxPdzZ+0w0GtjA+FN5B/bd7AuA0tsSB64YGt8zVkmcmRyTnJ dWchqksNj4qvUlUBor4kknsHzn8q6qceehp1OOs/Z4p37jf2h/2WdI/aG1Xwzq+peMbzR/7JtpLd Iba1SYSh2DFiWYYI24rzcBms8u5oxge9mWTQzRQk5WPnb/h2j4V/6Kpq3/gui/8Ai69BcT1OX4Px PLXCNNL+J+Af8O0fC3/RU9V/8F0X/wAXR/rNU/k/EP8AVGH/AD8/AP8Ah2j4W/6Knqv/AILov/i6 P9Zqn8n4h/qjD/n5+Af8O0fC3/RU9V/8F0X/AMXR/rNU/k/EP9UYf8/PwD/h2j4W/wCip6r/AOC6 L/4uj/Wap/J+If6ow/5+fgH/AA7R8Lf9FT1X/wAF0X/xdH+s1T+T8Q/1Rh/z8/AP+HaPhb/oqeq/ +C6L/wCLo/1mqfyfiH+qMP8An5+Af8O0fC3/AEVPVf8AwXRf/F0f6zVP5PxD/VGH/Pz8A/4do+Fv +ip6r/4Lov8A4uj/AFmqfyfiH+qMP+fn4B/w7R8Lf9FT1X/wXRf/ABdH+s1T+T8Q/wBUYf8APz8A /wCHaPhb/oqeq/8Agui/+Lo/1mqfyfiH+qMP+fn4B/w7R8Lf9FT1X/wXRf8AxdH+s1T+T8Q/1Rh/ z8/AP+HaPhX/AKKnqv8A4Lov/i6P9Zqn8n4h/qjD/n5+An/DtDwr/wBFU1b/AMF0X/xdOPE8vh9n r6ilwlGMeZVLteR+XPiPwzHpXj/XPBmlXL3qWerzaZbzsgVrjZMYlbaCQCcA4Br6qNbnoKq9HZnx 86MoYjkjrqf0EeO7WHQvC3gvQpCGaygSAc9o40TI/KvicB+8qzkj7rN1yUqUH2LHw/aMeGPFN1jE IVlJ7HEZJ/nRjn++hEWW+5RqPocR4Ikim8U6Osa/MJS3HoASa7McuWlc8/LfexSZ0HxSuIF8QQIw BdbZc/iSRWGWJuD7M6c7ajWt1O++GeG8Mh1GEadyPwwP51wZj7tV2PWyXXDpM78rxXnqcmtz1/Zw jd8q+4hb1oGQOKaEyhMgq0jJoxLuEHPHWtUzGSOO1G1BDYFddORy1Inner2p+Y4rtpyOOrE8s1m3 xvyK9Ckzz6yPKtYi+9xXo0WedVR5fqkYG7ivQgzzqiOAv05YV2RZxTRgFeTW1zGx3UieldJ4xnzR jrig0Rj3EXBqzRM5q8hznig2jI4+/t/vcdKDohI4y/tjzxxQdUZHHXluOeKGrHTGVzl7qA5PFQ3c 6Is9I8D6k+oaXceHZGxPaZnt/wDbQkZUnnoTx0xnFYyXIzHFxuro3Fl961vdHnuNmesfDJ/7Ts/i T4WzufVfDlzLCgON01o6XiAe5Nuyj13471w4r3PZ1X9l/nodWHjz81JdTzFZgwBDZBGQa9KM7xOC UVGViRZirq6sVdSGVlOCpHQgjkH6UmvadNCF7jvfU9TtPivqV3awaV460qz8XaREojj/ALWLLeWy DoIL1CJYwM8KS6eqGuKWAUZc1B8j/rodkcY5LlrLnX3Fn/hG/h94pO7wZ4z/ALH1FumieMmSAEnH EV8gEL8ngyCInsDURxGJw+lWN4/zL/L/AIcf1elW1py97t/wTlfE3gvxf4MkUeJ/D17YQvjZdSR7 oJQehWZcoQe2DXbQxVCropHNUw1Wm7zidJ43kE3g/wCEF6DkNpN1aZB4zFdOTx1z+95/SufCtSxN W3kdGJ1o07+Z03w18G6jDe6Z4pu57UWZjdooAxeRty4VuAVGCeQTkelVWquSsebOfs0z6Hil6Vxt XOK9zSim6c1LQXsX45feoaKTL0cvTmoaNEy9HL05/Cs2iky5HL0qGjRM7HVpMaH4QPYwT/8Ao01x Ul+9mejiX+4pfMxEl966XHQ5L6FlZfes2ikywsvFS0aJkyyj1pNFcxOJfeoaKUrEglHc0rD5iQSY qbFcw4S+9K2g+bQ3YJP+Ka1Y5/5f7T/0XcVyVF/tFP0f6HdRl/s8/kYfm+9ddjiuN873osFxDKOx p2FzERl9/wAqfKK5E0vvTSJ5iFpfeqSJciB5apIlsqvL1zVJENlV5fem47ji/eNjxrJt8VeIB3F0 4x6EdaywKvRizbHv98/kcZJN712pHBcoSzdeatIm5mTSjrVpENmZNMOeatIm5jzzYzzVqPMJu+p5 R4v8BaX4nvDqMt3cW19sWPfEFZcAnllOCTjgfMK6add0jWFXm0Kfwy+GPiHT/iPpF94d8/VEsra/ nK28RWVHWznMS4BIJMmwDnqc4rnzDHQWHlzeR62WU3XxCXa522q6donhaxXUPiF4vsNLm2gtpNiw v792IBKCJGCoc7v9Y6CsoYirV0pU7/gc88FFTftp2R46fiJaX+sLH8P/AArb2V8qkrrviAi+uoEU El402+VB6jYjvnGHJrreEk1+9lddjaNenh1+5jbzGyy30slzdapql1qWqXLeZcX185eSZuwJJJAG TgZ9+taRhThHlUThxGJlVektDyrxRd+ZqjRhyViQLjsCeT/MV1UrxSIgm1Zsq6BYnWtd0XSACRe3 UULD/YLAMfwXJp16jhBtnVRj7R8ttTR8Y6uNZ8WeI9TVsxz3kuw+qA7VwPTAFZ4ePJT5C8RLnnzn NSTCON5HbgDP/wBatr6mcY3aOfj3Su0jcs3J/GpOpKyNy3TpiqRlfU3rZOlSTI6O0Xpj1rNkJ3Oq sVGV471nIuJ2umjlffpXJM6oHomlL9yuOqdtJnqWkL9yvOqHoUWeq6OvC8+ledWPSpI9Q0pfu/hX BVPQpHoGnrwOPSuGZ2QOttlyorlkdUTZhGQKzd2bptbl9elRy2+MfM5E46ilZF6Dh0FFkJi0AFAB QAUAFNO4tEFDC6CkNtIKdwtc82+LngxfHfgHXtAVA14UE9r/ANdUO5QPrgj8a9HKsW8HioVVseRn WB+u4WcVufnP8ON/gvx54d16WNkSyugJhjBCHKuCPYM1foGYSWNwkox6o/N8spywOLjOp0Z9RfFS 0bR/FM1zHzY6kouoXXkNkYbBHvz+Ir53LZe0peze6PpM1p+yr+1W0tj0TRbseOvhXd2ELb9V0xdu zuSnKfmvH1zXnVYfU8cmtmenQl9cwLh1R454K8ULonijSryZ9sHmeVLnsjcEn6ZzXq43DqvQaPFw Fd4fEKR2XxjsJNJ8Rx6pGP8AQ9SQOHHTeoAYfiMGuXK5e0puk90ducU/ZV41Vsz6C8Fa1H4g8L6P qSMC7QhJPZ1+Vs/UjNfP4ylLD1pRZ9Pl9ZYihGS1OqrlSsrnc3zK1gp/MNO4UfMNO4UfMNO4UfMN O4UfMNO4UfMNO4UfMNO4UfMNO4UfMNO4UfMNO4UfMNO4UBp3OQ8f+LrHwF4J8U+M9SdVtNHspbpg 3AdlUlV+pbAHua3w1H6xWhBLU5MbiI4ehKrfY/DL9knwHe/Fn9oHQ9S1CIz6fpVy2v6jKwJBZH3o CfUzMvHpmvu83rrCYRQW7PzvKMPLF43ne1z9S/jD4mjuvFA06CQGLT4hE2Om8/M35DArxssoclLn fU9nO8R7asoLodfdS/8ACH/CFRcfLqOq4AQ8HMnPT2QVyxj9Yxtux2S/2HL+V7yOf+C1nJqOu3mr OD9msYSA3be/AH4ANXRm0uWCpdWc+R0+eXtv5Th/HniePWPFerXUEm63STyYyOhVBtyPqQxrswWH 9lQS6nn5hiHXxEpn1V4I0yTSfCujWky7bgxCSQejMckH6ZxXy+Oq89Zn2WXUfZYeJ1Tdq43okeg9 UyGrJZBIMU0IpTdfwqkyGY9z0/OtUrmLOYvsHdmuimc8zhtUjDBuPWuumzjqI8u1u3GHOPWvRos8 6sjx7W4cbq9Oizy6x5Rqy4LcV6FM8+oeeagvLV2ROKaOYb7zfWugxPQmXPFdjPEKkielSUlYzJog R0qy4mFcw9eKDaLOVvbYHORQbRZx9/be1B0wZxt9a/e4oOmMjk7u25PHeg6IyKWl38uhavZ6pCm/ yHzJFnAlQ8MpODjILAHHBweorKpBOJtpKNujPWNWt4YvKv7CXzdOuQHjkHcMMgkc4yOozwcjqKyg 7x13PMkrTdKW503wu8TL4Z+Ifg7Wp8G0iv4o51bkNE58twR6bXOaxxkXOk4m+Gl7OpFmL4n0aTwp 4m8Q+F5j8+k3s1mHPO9EcqrZ91Cn8a3w9X2sFNEYmHLUcOxkCf3roucrgh4n460yXCw/ze3Wi6Ss 9RKLe+h2Phj4h+MvB8bW/h3xFdW2nuCJNPZhNayg9Q0Dgoc9yBn3rnqYahWd3E2p4ivR+BnumteM PA/in4V+BtR8Z+BhbTQapqViLzwfMunfZ3cRSljbsrxNu25IwDxwRkmvLpYerQxNR0Z6aaHq1a9L EYemqsdddTT+FHh/w9fX+oQeD/ida3VkIfN/sbxDbHTLhHLAAhyzwYBPJ80E+g5xWJxdWnFe1p28 1r/wfwPMr4SnOD9nPml9x7bf+FfE+jRJcajot1HaN925jTzYX9xIuVI+hNZ08XSm7Rldnl1MFWpK 8omZFMOhPI/St782xzKM/txNCOXpk/jScQ9C9HL0rN83Rlarcuxy9KTVy1JsuRy/rUOMl0LV+52m qy58N+DpB94Ldx59hIhH/oTVw0l+/mejiHbD0fmYCS4rpa1ONS3LKzHjmoKUiwsvvU2LuTrKaXKN MlWb3qXErmJRN6mpcSrkgm9TU8o+Yd51DjoNS2N+3mP/AAi+rnPTULP/ANF3VcVWP+00/R/oehh3 /stX5GD5x9a7bHDzDTN70WDmGmU+tPlJbIzL707C5iJpvenYTkQtMfWqUSWyu03qaqxPMVZJvf8A CqSFcgVmmliiVsM7BQT0yTgUPSLYoPmmkaPjO4VvFnihlztbUbkjPp5rGsMup2w0UzfMJKVZu5yE k3vXekurOLXqZ8s3XmqUU9iG0Zk02OrY+tXp3F8WjLFjoHiHWyy6Rot7dgfeaCFiqj1LYwB7k1jP E0qXxOx0U8HVqfAiWfwpa2B3eI/FulWBHW2s5P7QnHttiJQH2d0rP6456UIX89vzNvqcYfxp8v4m Tcax4D0oFdN8PXmsXQPF1rk/lxegIt4iPyd3FVGjia2s5W8v+D/wwOrh6OkI8z7l7QvHniO/tfGI e+Sz0iz0O5dNP0yJbWAO7RRAbUAJ4djyT0rKvhKcZQja9zrw2NqunKTeiPkXU/AukXup3GoySyIk h3G3gARc45OQM8nJOK92EpJLlPL9td3mtSzZ6PpmjiX+z7fy2dQrOWLFgCCASfcA03K4nO65SrfX KwxTSscKilifYAk9PYUJXFTjd8p4fdXj3dzPcvw0rFsenoPwFdCVlY7Yx6nd/DuT7Bf634pJ+XQd NnuoyennuPKiH4vIBXLiZcy9n3OvDLlk6nY4RDhQMk4GM+tb3srGDXMUr6bcVgQ8D5m/oKpFU1Yd bp0qymb1vHUmTZu26cD6UiWzoLVemBUsSdzp7LHydetYyNEdnp/VT6VyTR0wPQ9KI+SuKqdsD1LS GHyV59U9GkeqaO3C8eledVPRpM9Q0lvu1wVT0KR6Bp7cDn0rhmd0DrbVjgVzM6omzCeB3rJotF9f SpZaJx1FSUOHQUALQAUAFABQAUAFABQAUAFPpoJ+8/I+Tfi58LltdSm8T6TbA6fdtuuYkH+plJ5b A7E8+xr6nK8z5oexmz43OsqcZ+2p7FrTrU/EHwOPCd04XxTo6mTT5ZDjz0AxsJPtwf8AgJ7Gpm3g sR7SPwvcKSjj8L7F/HHY8n+H/jy6+H/ilv7QilSydjb31swIZADjOD3U8/mO9enjcJHHUbw36Hm5 fjZYHEctTbqjo/i94UXRbyLxZoWJ/C2rkSrLD8yQuwyRkdAeo/EdqxyzFe0j9XrfEjozXC+yaxNH 4JHe+ENWsvi74DuPCGoXCJ4p0xA1tLIeXAGEf1Ix8rfnXDiaVTLcWq1vce56GEq08zwvsJP30Y/w d8YXHhPxLf8AgDxMrWrTzbYhNwIpxxjPTDjbg9zj1q81w0cTT+s0NTPKcVPB1/q1XRH1xXytraLc +xdt0FABQAUAFABQAUAFABQAUAFABQ/d0QpPl23CiyaBq2rPyl/b4+Of9r3Nn8BfBkzXVyZ45dZN ply8uQYrUBcknJDMPXaOua+tyLAci+tVNEfFcQ5j7drCUNe57l8Cfh5ZfsrfBmXVfEMMR+I/iLbN cwnBZH2nyoAfSMMS5HGSfascRUlnWM5YfBE6MJSp5LhOefxvoSfCzwvffEDxJNrOq730e1m+0Xdx J0nkPzBAfc8n0H1Fd2Y1lg6Hsqe72PPy7C/Xa7xFTRIf8VPG0njjxZa6B4eVrixtH+zW0cPIuJSc FlA7ZAA9hmllmG+rUniK2jHmeMeOrLD0tkeheJdXtPg/4Bt/C1pcK/i3VELTPGeY9wwzk+gHyr69 a4qFOeaYp1ZL3Infia0MowioQfvy3PN/g74RuPGGvpqF1E39hac4kmds4lkHIjHrzyfb6ivQzbEr CUeSD1f4Hn5PgnjKnNNe6tz7j7Y7V8S3d3PvUuVWQ1u1IZG3WrJZWkPOKBFGY1aEzDuj71rE55o5 e+fls10xRzzZxeoSZz+NdMEcc2eeavgh69CkcNRHkeuqPmr0qDPMqo8e1gDLfjXp09Tyqh5pqIwW FdsdjkqHNFhk1oYHojg+tdx4dyuy54pFXKksY7UykZNxECScVRomc7eW4OcCg1TOUvbQEHig3jI4 ++tPvYFB0RZx95ack4/Cg6Ys5i7tuvFJxaVzojJrRHr3wb0oeN7+f4eS6naW2pXEby6VHfP5SX0o wTaiQkCN3xlCeM5HG7NcGMq+wj7VLQJ4VYlKUfiRzWu6VqWgarqWhavZzWWpWkjQzW86lHiYEggg 4IIop1lVipdzJwcbXPTvi3IdXuPBnxBiBMXivRYJp3xx9ttx9muRxx9+IEd8HPesMFPklKh2OnGU 07Ve55KJz616Ckea4DxOfWtOYjkZILg8c04u26Imr9R4uMd6tyvsQ6dloesWM32/4H+I4gMyaP4n tLzd3VJ7eSIj6FlBrz5S5cUubdnfTV8LJr7Ji/D7xfb+GNc+03ob7BcRmGVkGSnIIbHcAjn2rrrR U1tex5so3g4n2X4T8ZX0drDq3hfWryztrnLK9tK8XmjpyoIBB9CPqK8uphaVZWqo5FWq4Z+7Kx6B D49u7rC69o2j6wvQvdWawy/hJFt59yDXJPA8mtKTX4/mbrMZ1NKy5vwNCO/+H19/r9J1jSZSOtjd JdRA9yRIA2PYGpdPEw1UuYfPhKmnLyfiW49B0C7I/snxxYEk8Ratby2bfTcA4z7kgfSk8TXh8VL8 R/VaM/hq3+RbHgrxM2DY2cGox5wG027huS2PRFYuPxUUnj6Cvd2+TD+z8TL4PzMu6sNU0ptupaXe WbcDbdwPEc+mGArWnWp1leMtDGph6tLSojpdQlL+D/CMgOdlzfxE+mfIKj/0I1x0X/tVTXSy/U7s RGX1ajp3OfWb3rta1PO2uWVmqXEdyws1TymikTLN70rDTJhN0yKkrmJBN6UrFXHiakxqQ/zT7Ura DUjobeb/AIpXWD/1ELIf+QrquGrH/aaXo/0PQw8v9lq/I57zq7rHn8whn460WDmGGb3pqIuYjM3p TsK5E03vT5SeZkLT+9UohzFd5vehInmKsk/Wq0C0nsjR8O21zqev6PbW1tJOXuoVZY0LAKXAJbAO BjqaxxVVU6bbkdGEpSqVUkjY1vwp4ovNY1a8n002cE11LJ52qTRWfBYkEiRlJyD2BrGhi8PCklzf cr/kdOJwNedRtL8TAk8PaVaHOreNNLiK9Y9PSW9cY9gFX8mNarESnpCncweEow/iVLFKS7+H9i3y W+t6vIOvnSR2UR+gUM4/OqUMVU/u/iLnwlPZc/4GfJ47Nkc6B4a0XTGHSb7P9rmB9d0pYH/vireC 5v40nL8PyJ/tCFP+BDl/E47W/FOv64uzWNbvLuHORDLKfKU+0Ywo/ACuqnhqUNYIwqYutW/iSOPm m9/wroUFHoc7k5aX0MeeYc81pa+4rWOi0qX7L4F8fX5OHuZLGwjPrl3kcfkq1x1nzYimu1zvw6cc NVv1seUXE3UZrujG1zgTbjdmNPL71Vi0vtHmnjTVTFFHp0T/ADzDdIOuFBBA9skVaO7Dwv7x5yH9 atSurnTy20PR5XGjfDe0gDFb3xLfm4Zc/wDLpbAquR6NM7Y97euKL56l+x2OHJC3cz7DRbO20G68 TeIZJYdPZGi0+2jIWXUJ+Rlc5xEh5d8cn5RznGjqNyIVKyODiVnJkblicmu1L3TFqzNm3j6cVRm2 b0EXSgxbNqBOBUEt2Nu2GAMGpYJnQ2Zxj2rGRsjr9ObBFc0joizvtLk+7XFVR2QZ6fpEv3efSvPq o9Gkz1PR5j8tedWR6NJnqGkzZ21wVEehSZ6Dp0vC1xTR3QZ2FrJwOa5pI6UzchfpWTNkaSMayZaL C+lSUSA9qAHUAFABQAUAFABQAUAFABQlZ3B/DZEc0EVxFJBPGskLgqyOMhgeoINEJyU+aBE6cake WWx4L4t8H6l4Zn/t7w3E8lpEfMKRAmW2I5yAOSP8mvew2Kjioeyr6M+YxuXTwcvbYY8w8T6Novxa h+2aXLb6b8Q4lw0MjBItUAHABPAfjjP0PHI9LD1qmXS196n+R52Jp08yXOlaqvxPPfBHxLuvA01/ 8PfiRpM8vhiZjFcWdyh8yyJPLKDyV74H1HPXuxeBji7YrBu0t/U4cJmMsGvq2NV4P8Cx4n8I678O b2x+Ifw81M6n4SJE1vqFqfMMCnqkwHUEcEkY7HBpUcVDMI/VcWrSKr0J4KaxOEd4M9QL+E/2h9Dj vtLuYtI+JFhGN0RbG/HTOOWQnow5Xv7+byVclqNTXNSZ6cZ0c7hzJ8tVHZfDn4o39nfR/D34mxSa b4ut8R293c4EeoqOAQ3QuexBwfrxXFjsuhV/2jC6we67HoZdmdSnP6tjFaS28z6FrwmrH0aaewUh hQAUAFABQAUAFABQAUAFNJP3kJOy94+DP2nv2uLbwSbj4Z/CVxrHxQvT9meexXz10tm4AUKD5k5z wgzg8nng+9lmUyrP22I0ifMZrnSivq+G1keZfAr4CaN8C7Nfjd8eJxc/ES6LT6dokziaW2lfJLtk ndOc5LZwmeueno1q88fL6nhF7i6nmYXC0csg8Vi3eb2R6bpOj+N/j/4lfxFqpfTvCcLFRO2dkMQO THEDjcx7t0zyewreVWjk9L2VPWbMKVLE51W9tPSmjc8efEiyt7W3+EXwetHnB/0ee6scs0pPDKhH JJP33/AcVhhMBJt47HP5G+Mx6S+oYJadyCzk8OfAPTP7S1uSDVfifdxfuNPjcMmnqR1Yjp7nqeg4 ya1n7bOZ8sFy0l+JnTnQyWneetV/gcL4M8H+NPjT4huNd1KeaPS5Zd11qsg4wP4IgeCQOABwO/v1 4rGYfK6Cp0/iObBYHEZzV9rU2Pvvw/4f0vwxpVpoujWwhsbddoHUsT1YnuSeSa+HxGIqVqjqydz9 Aw1Clh6SpwRs1znQMPU0AROcfjVkFZ2oEzNmbrVohswbuTBb2roiYyZyV/Jw2O2a6II5ps4fUJfv c+tdkFocc2cFqs3ytXZSRx1NjybXZ/vV6VFHmVWeQaxJnfXp0dTy62h5pqUmSxruSOKZzxfk81pY xPSyueorrPEImj44oAquvNA0Z8sfXirNEYtzDnPH5UGiZzl5b8Hig2TOTvbXIPFWbxkcjfWhyeKD eMjlLy1xnipaOiMjAZZ7aaO5t3MdxEwdHHVSDkHnj86iUFLRnTCVj6ztdZ8PfHHw/pth4wvoNK8a 28YtbDxZccpuUAC11FgCzR4GUnOXUcNkD5Pn6tGpgarlT1j2/r+v16IzhNqnW0XRmBceGfENr8Pv HHw58T6ZLaeKvBd0niSzgchhLp8+y3uniYErJFu+ySqUJBDyN2NQsTBV4VYPSW50yw8pUXB/Z2PB BL716/O3qtjynTsPEvaqVS+xm6dhwlFacxk6Y4S9qpMTpnrvw3kGoeFPjN4d5Lz6DHqkSDnc9ncx tge+JWP4GuHFO1WnPsdeGhfDzh3PJfNFeipXkefKGp7l8M/iXYaJaR+H9cJitVcmC7UEhdxyUYdQ ASSG9OOwzjVjd3OXEYbnXP2PqCC4V1R0YFWAKkdCCMgj61jJHluPKaMc3TmswL0cwOKlody9FOV5 Xg+o4rPkUt0Wpyj8LOp0/wAX+JdPQR2PiHUYIsY2RXThSMYwVzgj6iuargqFXWSudVPHYimrKR6C /jLVrjwXaX17Dp19LFqrQN9ssYX4aHcOQoYE+XyQcn8K8/6lCOI0dr+bPV/tCrPDLn1sc+vifSZi PtngzS2J/is5biAn85GX8hXSsJVjJ2rfgji+t0JNc9K/zLC6n4LmP7zQNUtSevkaikw/ANGuPzNR 7DEx3qX+X/BL9thJaezt8ydf+EHl+7qOuW5PUTWkLgfismT+VTfEp25L/P8A4A+XBy+3YmGn+FZP 9T4zEeei3Gmzg/QlQQPem54hb0/xK9jhXtW/AkGiaY4/ceMtIb0EvmQ/XOV4qXWqLeA/q1HpUJB4 dZv9V4m8PPnoP7QCsfwKjH40fWl1TD6ontMkHhfUG/1WpaPKe4j1BDj3OcUniY9vwYfUanRj/wDh FNW/5+dM/wDA+L/Gj6zTv1+5j+pTX/DnQW3hfV28L6vAklhJK2oWjjZexHgRXQPJIAPIwM88+lcV bEU/rVN+T/Q78PhJ/Vqq9DBPhLW1/wBa1jET0El9EM/TDGuz63T/AKTOB4Cohh8LagvEupaPEewk 1BAT9MZp/Wof0g+p1F1GHw9GufN8VeHl9kvS598gLQsTJ7RuH1aK3kRnSdCT/X+NLFf+uNrPN/Ja r21fpS/EPY0FvV/AiaDwZF/rfEeoXHqLXTwvHt5jCm6mJe1O3zF7PDLap+BA174IhHy2OuXZH/PW aG3z9cB8UezxUlvb8f8AITqYaG8eYgfxF4fhB+yeDLUnsb+9mn/PYY80nhq0lb2v3L/O4PF4WO1K 3zKr+Nr6LH2HTNGs8dDDp0UhH0aUO35HNV9RjKzqNt+rX5EPMJr+Foa3hbxl4n1Lxd4ZhuvEF+1o l9FI0CzMsZVG3kFAQuCFOeOlYYzA0FQk4rVnTgcdXnWSbPLLq7aWSR5JGdmJJLEsSSeuTXrQhCMF ZHk1K8+Z80jLknHrWiSWxk5XM+Wcc81VhGbNOPWqsBlzz9eauKAyJp+TzVMDInm6/NQkB0uqyix+ Gfh233APq2rXV6Qp5KwRpEMj0y5Irlj7+Ia/lPSqe5hof3jym4lxmu9djga1uc3qeoQWNvNd3LkR RjJxyT2AHue1N6G1Gm6kvZo8L1C/fUb65vZBjzDlV/ugcAd+3Wo5j240FSXKtibS7C91jUtP0jTo /N1C+nS2gj6bndgqgnsMnk9hWdWryQ5uxtCj7SaR7Z4i0/RI78eINbd5PBOkRJpeiWCPsm1wQZUs vdIWk8yR5MdXIXJ6ccJt6R3Z1VKS+OWyPIfEniHUPFOqvqF95KAKIora3XZDbRqMLHEvZQOAPxPN enhaXs1qcFWaZTt4unFdO7OeTNqCKmYtm3AnA4oMmzWhXpSZLdzVt+BUME7G3bNgismaRZ1FjJyv Nc80dMGdxps2MVx1UdkGek6VcYKc1wVYnfTken6RdfdGa8+tE9ClI9P0m6xt5rz6sT0acj0TTbn5 RzXFUidkGdraXGQOa5JxOyLOit5cjrWUkbJmtHJwOaxaNUy4rVNhonVqRY7JpDuOyKBC0AFABQAU AFABQAUAFABQ5cr11YrKSseR+NPhDoniZn1DTJTpOt53C4tx8jt1BZQRznuCDXrYTM5UVaeqPGxe UU8Q70/dkeB+NNI1q1s00r4v+Ep9X0eEbLfxTo/zXNoCeCWAG4DrhwPxr2sJWpylz4OpaXWL2Pns dhpRXJi6fMukuxwHhq08e+Amudb+E+u23jLwbJ813pEYJkCEciW1J3g44ymffjiu6tPC4v3MVHkn 0f8Awf69DzaMcRgvew8uen1X/Di2sfw+8fanHq3gHXH8AfE6F939j6g5igllHURvgbSfTH/AaU3i cJB08RH2lN9ev3FQWFxk/aUJ+zqroem3vjaC7tYfBf7SPg57CUHbbeJreMtA7cAMsqZ8sn1Bwe4F ecsLZurl8790/wDgnqfW+ZeyzGFu0l/wD0rRLjx54Is7ebSrr/hP/h+VBgmtZUbUbWPHABztuAB6 EPXn1oYfE6VFyT/BnqYedfCrmg+eH5HqXhrxx4X8WrINF1NHvIuJrGcGG5gPcSQsA4I9xivMxGDq 4Z+8vQ9ahj6OJ0jKz6nW1zWk9ztuugUW8xXCnogulsFILSlsFNrsF29wpJ32C1goV+o00zz/AOIP xT8AfC3SX1jx14ms9LtgpKRSvulnIGcRxDLOfYCumhhKtd2pxOLE46lhdakj4f8AEnxS/aA/aWW5 0b4PaFceBfhXJlLrxnrpNtLcRZwTGRkgEdkyfVgK9yjhcPgNavvT7Hz2JxmLx/u0fdp9x/wv8EfD z4PzSWHwc8PXHxF+LEmUufFdzEDa2TH721ydqDJ5wcnu56V11HUxKvi58lPscVNww0uXCQ9pU/m2 sehah4J0DQLxPG37RHjWPVPEMuGg8P2jFweQRGsYwzAE4wAE9SetKGMqSXscBDlXcJ4SlT/f5jO8 ui/4YTxRr/jfxzpKpePb/DT4RxgIJNRIhubyMYwqxLhsEdEAA9zVYejRw87x/e1fy+exGIxNfF07 fwqP5/qcNoXiuWBJvCv7Ong2+u72UeXdeLb6EGeQHglSwCxLnkZI+gNdlSin++zKdl0ijho1Zr9z llO7/m/4c9U8Bfswn7UviD4o6q2p6pK3mvp8MjMhYnJ82U4Ln1AwPc15uN4hi4+xwa5Y9z2MBwzK cvb46V32Pri0s7TT7WCysbaK3s4UCRwQqFRAOgUDAAr5epUdR3Z9fTpRpq0UTn6fjUJtGo2gCInF AiByMdatRJKUz4/i/GqRLMq4kzznrWsUZyZzl5L15rZI55M5C/m+9zXVFHNORw2ozhd2TXZTicdW R5trN4AH5rupRPPqzPI9buyd3NelRiefVkeV6tcA7vmr0qUTzqsjz2+kyW5rrgjiqMwC/Jrexjc9 bKmtjxhu30oArumaBopSp14oKM2aLOaspMxLm3yDxQaJnN3drknig2jI5W9tOTxVm8ZHJXtp14oN 4yOZurXOeKDpjIZpGq3OhXMjxnNpNhZ4mGQwByCPQjJwfcjoTWFWlz3k90U17WEoy3PqjwZ8WbDw e+iW/jrRn8S/DxFntvIEgW60q3uomimFrNkHyXSRg8DnYTgjY+CPm8wwXuupR+J/oellGNkl7Ct0 PLfi38FvEnwo1CeVrm31zwY7p9k8S6Wxlt5ElRZYhNgAxSmN422OBnPBI5p4HMFWS5tH2OvF4H2b ujxoSDrXp+05nrocMqaS1HB+3FUpmLpD9/v+tUpmbpHrPwPul/4Wb4c0qXmDXludDdc4DNdwPBED 9JniP4Vy46VqLn2OjB071eTueWSxvazS20gIkhcxsDxyCQf1FdlOpeKZwypWkM39q05roXs76M+x vhN4hk1jwhaLcz+Zd2MjWjlsk4GCm4knJKkdKy3Z4mNockuc9Wjm96Rwl6Ob3/ClYC8k3oaloLcp bjl96m0Bqz6Hd2Eol8BeII85NtqdpPjrjKyR59uuM151aNsRTd+56VFuWGn5HMrN0zXdbU89blhZ vepaYadidZvfFKz7lc3kTLN6Gk49yrroTCb1qHCHUrmfQkE3rS5Ij52L5q+1HJEOefccJFPYUcmp ftH3OltWX/hDtc4BA1Ow4/7ZXlcFaP8AtlL0l+h34eT+q1te36nNb0zjaPwFd3Kjz3MPNA6ACnyi 5/MaZuPvU+VdA55dSIzDpmnZ9BcyImn96OXzE5N7ldpvenyi9Cu83vVNfyheP2iq83vTUV9oV19l HSeB5iviWOfPy21lfTk+my1lK/8Aj20Vx498tH3e6/M7cttGvr5nByTgjk9a7Y35VocU5Jt6FCSf rzWiVyLmfLNyeaqwjOlm96ZZlTTdTnNWkBkzT9eaQkZFxNgMSelVsmyoq7Oq+I0ospPCXh4HB0rR bbzQP+es4NwSfqkkY/CuPB+9zVf5v0PRxuihS/l/U8pnl4OTwO9dy0sziSu7HinivxCNSnNlayZs ojyw6SMP6CueVQ+gwmE9lG73OSQlmVVBLkhVUDJYk4AAHUk9qhztqzuVJs+jfCnhv/hU+kXHxO8X W9rNr0B+xaX4ZnYlxPPG2JbkA5QLGWYR53kEE4GK4KtZ4mfso7M640Vh488t+h4lr3iHVfEeozar q90Z76UBQcBViQcBEUYCqBwABgV6mFoqOnY4MTVclbsULeLpx+dejc82TNu3i4FO1jObNmCLpTZk 2a0KcVLMmzRjWhslu5dj46VIJ2NSBvunNZM0TOhtJMEZPWsZI6Is67T58FWzXLUR1wZ6Dpl0AVOa 4qkTtpyPSdJvfu81wVYnfSkenaTej5TmuCrE9CEj0bTL0YHNcNWJ3U5Hc2N4MA7q5JxOyMjqbW5y BzXNJG8WbsM+QBmsWjeLNOOXp7VDRdy2j571DLTJQ3PpUjuSBs0DH7vagBcigBaACgAoAKACgAoA KNOoPl+yFFluDae4hAYFWAKnjB5BBpptbaCcYOPLa55br/wb8Da5eDVYLCXR9cUkrqeiStaSqfU7 cA/iDXpUc0rUo8jd12PIr5Lh68uaKtLueb+KPgrrerR+VrI0PxnZquFk1iE6fqSADot5CCGP++ld tDNYwd6b5PxX3P8AQ8zE5JUmrS9/8DnbDwf448MW7aZpOo6vb6Qww2geMbNNa09gedq3EJLoPTI/ Ct54uhiHzON5fzJ2f3f8E5Y4DEUVyp8q7b/iWtK8HavoM/8AaOi+HtY8J3UvL3Pg67TUtMuCOpay lAZQfQID71nVxFOokpzU/K1mvmbUcJXou8I8i77/AIHdS6be+JFjk8VeFtO1y4g4j1jRvM06/hAH BMUhDKf9yQj2rl51Rb5Zcvlud8aTrfHC/nsdHptp4o0/CaL4nuLmIdNO8VWrFx7LcIA34kPXNOVG a9+Nn3R0041ofDO/kdKniPWrU7NZ8I3kWCQZtOkW8jOO4xtfH1QVjKhTlrCdzqWJqrSpTsbdjren ag3lwSSLN3imieNv++SAaxlQcTaFeM9jWrPY397oRTzxW0TzzyBIkGWY9AKFHm3FJ2+PQ831X4mR Qs0Hhvwl4h8RXmdqrp1n5UOf9qeYogHvmuqNFP4mcdTEuH8NXPNNZT9obxkGgXVNF+H2ivnKaTE2 uaow7jzCEgjJHQgPj1NdVL6pR29/8DiqyxmJVl7i+85TRP2bvDWkakfEtz4fbxB4tZgzeJ/iLetq Uu7JJKWqfIMdQCUxW/15NcsZWXZf5nLHLpJ8043ff/gHf6j4ETWjH/wlA17xeYsGPT22aZpkeBwP KBUEDH8Rc/WlDF+yf7t8l/mwngJVN/f/AAGXlr4xFouj6SG0TR1G1NM8FaeGlxgcG7nCRoexKoD7 1UalK/NU9592/wBCZUa6j7Ol7vl/wTB0f4T+MILmS90LStD8M3spzJrusSvr2rMe7BmxGhPsTita mY0tFUlzpdFov8zCOU1py5oR5PPc6iw/Z48HTaguteN9Q1XxdrXXz9buC0Y6cLCuFA46YIrGed1e X2eHXJHsdlPh6g5e0xT539x7hp+nadpNrFY6ZYwWlnGMJBbRrGij2AAFeRUrVJyvKVz2qGHpUlan GyLmRWdk/Q21b20E3e1GkR3Gk9zQ3cQwt+FAEDNVklWSTiqTuS2Zs8mKtIhsxLqYAnnnvWsUZSZz V5OOeeldEUc8mcbqF0Buya6YI5KjPO9Wvsbua7qcTiqs8t1m85f5q9GlE86rI8q1a5LbsH8a9ClE 4Krueb6lISWrupnBVZxV6xOa64HJMxDvya1Mj2wr74/GrPIIyv41VwISvHSgCB0BHSgChNF1oLTM meLIPFWWmYdzDkHihI0TOau7bORirNoyOXvLTrxVG0ZHLXdnyeKDojI5y5tevyVL1ZtGVxYdSki0 rUdMupXe2MX+joRuCNuBIHcA5Y+2K4cZS5lodNCK9opHuHhzx14kk+G8firw3fK/iPwdGmka/pF3 GLi21zQpHJtnuYGysghlZ4iSMoJEII4r5OUIqryy+R9RGUnT5o/PzObPhrwP8Tibn4cTw+G/GUhz J4K1a6AtrtzzjTrqQgZJ6QTEHoEdzhK6FXqYd8tXVdzndGFdc0Pi7HkOqadqug6jd6PrenXVhq1q 5jns72JoZYWBwQysAQfqK7qeIVRc0djmlQcNHuUllPrW0anNuYOFty9purXmjajp2s6e4XUNPuYr uBj0EsTh0J+hC0qjU4OARhyTU0ei/GixtdM+KHjH+zl26Rf3I1SyHB/0W6RbmHkcH93MnSs8HV5q Sb3LxVFRqtLY8x8z3rsUzidJydzvPAfji68H6mjPJK+izMTc2sePmOMBgD3HHfkce9HMc2Jwnt1Y +xdG13TtbsodQ0y6jntZADuQ8qfQjqCO4NapqR8xiKEqE7TOgjm96bjY5766F1JqkouRz+9TYDvv DU/neFviDaZ/5drS4UehjnBJ/I4rgxS/2ik/U9HDO+FrR72OVWb3rsauef8AaRYWb8amw7k6z/7V FguTLNSsMlE3vSsO5IJ+etKwXHif3qbD5h/n+4otqOT0Oos5S3gvxDj+DUrBj9PLuwf1YVw1ov63 Sfk/0PSw7X1Sr8jl/P8AcV32PNuMaf0/WiwXGGb3p2C5EZ/f86LBciaf3osK5XafNUkFyu8/vRYV yrJP1p2C51HhCfyk8ZX27/j20OfB/wBp5YYwPxDt+VcWLu5wh/M/y1PRwekJz7Hn0k/vXel7p5z2 ZQkn681pYRnyz9ec0WAz5pzjrTUQMuef0NUkXEyZp+DzRsBa8OaZJ4j8TaDoUThWvruKAu2MIGYA sSeAAMkn0rLET9lTlLsdOFp89SNPuZnjXXo/EPirxFrUI22t5eSyQJ/chyREvPogUfhRhKfsaXLL Vl4mq6lbm6HhnjTxMkMMulWc7C8YgSFOiKRkgn1PHSprVVy8i3PUyvBcz9rVOP8AC/hHX/F09xDo 1qhtrZRJd391IILayQnG+aZiEjH1OT0AJ4rgniIUo66s+hhQc1dbHo2najo3ha+tNB+GaHxB48vZ UtV8TTQFUhlchQmnwMMgknHnyDeeoCVjNzqx97SPYuNlpHcxfiJrMMt/ZeFtN1BrzStCDxvely/9 oXzkG6uSxyW3ONqseqRqf4jXRg6fOznxVSyscPBExOTXv0oezPFqy5jat4enFWc8mbUEI44oMmzW ij9qDNs0I1xxQQy2vagRZXrUAXIW6VDVy0a9vJ056VlJG0WdLZT8jn8q55o6IM7bT7rG3muScTsh I9A0y9xt+auGpE7qUz0jStQGVy1cNWB3U5no2l6gOPmrhqRO6nM77Tr8ED5645wOynM7GzvRgfNX PKPLGx1wn0OltrsHHPFc842R0QlzaM2orgHHNYuOt0aczvboaUcw9aiVrXW5om+UtpID3qUtBN8z J1cetSlZlyk0rEu73oauVzDw3PpU2sO9x2TRvoD7i7vajbULdBcihOzDuxaErSFrdhTtpqgemrYU k1JW2Hq5W3Ci100LZXTuFN80UkC5XpIKVkF7BRogd2FFkFrhTWgWS3CgbXMFP5k/CFGmzDZ6IKT0 0sHXV6BReUtRxjFO4Um29bBGzvFsKdkO7CnewuW4UrIdrBSFdhTSstQty7BQmG/QTIospK5S0VmJ u9qV/euhWtohMmgPhELCgV7jC34UWT94LtERcYqvQOnMQtKBTiubQhyS1RTkmA71SV9BSutShLOA DzVpENmRcXQOfmxWqRk5HO3d6oz83StoRMJTOSvtRXDfNXRCBzTmcLqOpL82JK7adM5ak0eeapqI O75q7qdM8+pM851S6Rt3PXrXbTRxVGefakytu+ftXZFHFM4e+i3FsV2wkccjlLq2Y54roUznkmZB s3yeK15jG7PZmQ1qeSRFPSgkiKcZqgIGT1oAqyR0DRQlhyOlBSMme34PHFUmamFc2obIqrlxZzl3 aDk4qjRM5m7s/vcVRtGRzV1Z9eKdjoUjnLm0HPAqeVTNoSag5Frwb4nn+Hfiuy8RCx+36LIklnqm lM21NQsZhsngY84ypyrfwOiN1UV83m+BajzQPostxsZv2dQrfEbwingnxG1hZXhv/DGoQJqGi6rt 2rqNhLkxSYPRhho3X+GSN1P3a8uhWjON5bo9GrScJXgdRpHxc+3aZZ+GPilon/CX+GLZBFbXEs3k 6rpaAAAWt5gsVA6Qyh0HQbBRKm0+ei7MSkpaTV0W7r4VQeILWXWPhD4jTxbYKC8mhPH9n1uyHUhr TJE4A6vbl/XaBVRxbjpVVmRPCqetJ3PHWZkeSORGSRCVdGGCpBwQwPIIPBFdaqc0HY5ZUmpq56/8 RH/tnwd8IvGSks02lS6BdN1/0iwkCoCe3+iXFmAP9g4rnw87SlHob16V4xkeR+Z/tV2qocvItkOE nrT9oT7Hl1Or8L+Ntb8Iy3EmkyxmOfb5sMylkbBzkAEYJG4Z9KtVuU5MRgYYnSaPsLwd4z0/xdpa X9kdk6YWe2PJgcgnBPcHDEHuK66VTnPksdgZYOb7HapOa0scJcSf/aosSegeBZvPl8WWHU3WhXaq Onzrscflhq4MYtYy7HpYHW8O5ySXGQCDwRXXHVHDJbllZ6LEk6z+9FgJhPz1pWAlWf3qbFXJPPos Fx4nxRYLjvP9xStqJvQ6zTZ/+KL8VHPS9sP5XFcVZf7VT9H+h6VB/wCyVfkcn5/uK7rHnXGG47g0 WC5G1xRYLkZuO4NFguQtcds00hldrjrTsBXe475osBVe49adgOr0Wf7P4J8fXpODNJYWSep3PI7f kI1rirv/AGilH1PRwytg6r9DzuS4x3rvtZ2PN3bKMlxnvTGZ8tx74oAzpbirKsZk0/HWga3Muafr TavIpLS51/ghzp1l408XsCF0nTWtbd+n+l3YMCAH1ERuZB7xiuHGe/OFH+b9D0sElGEq/wDL+p4l qt7q011a6F4Y0q61XxRe5+zWFlC0z4HViqgnA7k8dyQKvE4inh42ubZbl08bV5vso5V/C/g3wRI1 18S9ZOs+IwSx8JeHblWKOecXl8NyRjPVIt7+4ORXjTrVK2tNWXc+yjQhSjrsjlfE3xB1rxRb2+lG K10vwxauXtfD+kIYbSAnjewJLSSY6yOS/oQOKunTUHzbvqZznfRbHUeH93gTwm/jSbCeKdfSWy0G I/ftrYgpcXuOxIJijPu7DoDTvLEz5I/MmS9kuZ7nA21uQBnqa+iw+HVJHgYiu5s3LeDGOMV1/EcU nY2oIM4pGUma8MXtQZXNGOPpQTctKhoETgdBSuQSJ2osWSq2OaTQ7l+GTkc/WspI0izctZ8Y5rCS N4s6myusY5rmlE6oyO006+wVOa5KkDrpzPQNL1DBUZrkqwO2lM9D0vUxxk1wVKZ3U6p32namvHzV xypnZTqnb2WpD5ea5KlO7OtVNLnDfGr4s6x8J/Ap8Y6NocGqvBeRQz29xK0QSJwwLggEkhgg/E1e Ewv1iTizLHYz6rSVRGP8Yf2mYvhj8PvBHjPSdHt9Tu/EflPDaSzmNViMQkZtwBJxuUDjvTw2Xe2n KL+yYYvNvYU4VI9Tf+LH7RsngHwh8N/EPhbRLfWtR8ZXEEVlaT3BiXZJGGDZAJJBeMdO9Z4fLnVq Si9om+JzVUowlDdn1VBdN5KNOVSQKC+DwDjnk9hXkuk1KyPaVZKCkxmm+ItG1V5otM1eyvJYTiRL W4SUx84+YAkj8aKlGUVdoKdeFR2ua02oWtpEZru4ighBA3zOFAJ4AySBzWUablojWVRR1Ytrq2nX dxdWlpf2011bECeGKVWeEkZAYAkjI6ZodJppMSrpptO585fs5/HDxH8Yb74p2uv6Vp9mnhnV/wCz 7Y2PmAypmQZfcTz8g6Yr0MxwMMLGnKL3PMyvMJ4qdSMl8J9I6hrOlaRCtxq2pWllAzbRLdzLCpJ6 AFiBmvPjTqSdoxuerUq046ylY+cJPjprx/ae074LW+n6bJ4VutGGpjUV3tOzFGYbWB2FSV9Pxr0v qFsJ7Z7njrMb476unofUe4e1ePZt3Pd5luYHivxTongrw7rHivxJfJZ6HpkDT3Fw/ICDsAOSScAA ckkAVrh6NStNUYrVmNevCjTdWo9EfBtr+1h8fPiO95rXwT+AkmpeCreUxx6hqkhV7oA4O0BkXPsp fHQ81739l4SiuWvUtI+b/tnF4puWFp+6j3j4AftEXHxhu/EXhnxF4E1Twx430AA39ncRu0AycALI yghjnIRhkjkEjJrhx2XLCNVISvFnp5bmcsXenUhyyIo/jh4jf9qW4+Bh0vTx4bTSRqAvh5n2jeYg +M524ycdOlCwMVgPrKepCzGX9ovCW90+mrm6trOCW5u544LaNdzyzMFVAO7MSAB9a8uEJTdkexOc Y6sz4Nf0K5toby21qwltJn8uOeO5jZJH/uqwJBPsDWjoy7Gca8O6NSSWOKN5ZZFSJFLM7kKFAGSS TwABURg2aTkoK7KWnatpWrwtcaTqdpewKxUyWkyyqpHUEqSAfanOnKO6IhUjU2dxNR1fSdIjSbVt VtLKFztV7udIQxPYFiAT7UoU5S2Q51o093Yvo6SIksbq8bgMrKQQwPIII6g0pRa3KhNVNUOpfZ03 KTaduh8PfFj9p34iab8UtW+E/wAF/hrH4n1zQ7YXeqS3MhXapVWKxoGUnAdRnJJJwAa97C5VSdD2 2InZM+axucVY1vY4eN2fRXwX+I+pfFPwDpXjDWPCF/4av7hnjk0+/UjJU4LxkgExk5wSAeDx3PmY zDrDz5Kbuj18FiZYml7SorM82+Hvx81Dxj8evif8Jrqx0uHRvDcSPaX8E5aW7YlMggnBxuPA6Yrr r5cqWEhVi9WceHzR18ZOi1ZI+mLm6trOCW6u7iOC2iXLyzOFRB6sSQAPrXlwhKTsj2J1Ix1ZQg1/ Qrq3gurbWbGW1nYpFNFcRskjDqFIJBPPQVboyXQhV4PZov3N3bWcLXF5cRQQLgGWZ1VRnpkkgVCg 27IuclBXbKR1zRhfRaYdXsRqUqh47T7QnmupGQQuckEc5ArT2ErXsZrE09ro0sms7Nmqd9Wch4k8 X6bpGl+I2stT0+fX9OsLi6TTmnUyEpGzgFAd2CRzxW9DDyk1dbnLWxkKSdmeU/sy/F7XPjX8MIfG /iHT7Ky1F764tfJsA4j2oVwfmJOTu55rozLCRwlb2cWc2WY6eYUPaNHt+o65o+kGAarq1nZGY4jF 3OkRkPou4jJ+lcdOlVl8MbndOtSpSXPKxKmoWUtxJaR3kL3aKGaBZAXUHGCyg5AOfSlKjKO6HGtG psytd6zpVkLj7ZqdrB5EfmyiaZU8tM43HJGBk9TxVQoylsiZ14wdmyWO8guIo57eVJIJAGSWNgyu DyCrDIIPqKl02m4lRqaJx2PIPiv8UrfwZ8O/Hfirw1d6ZqWuaBZNciyacSBWBAxIqtuA59q9HDYN 1K8INHm4vHQo0ZuD1F+D3j7UfiL8MPB/jbV7a3t9S1e1+0TQWuRGh3EYXcScYXuanF4f6viXBFYL FPEYeM2dWfEWkTXs2mw6raSalECXtI50aVAO7KDkfiKzVCUU5WNXiISbjcgub4AHn8KpQByOcu9Q GDzW6gYSmcnfal975u1dFOmcs5nF3+pgF/mrqp0zmlM4TUdTHzfNXZCkck6hwGpan15rthSOGczh NQ1HO7JrshTOOdU468vgSea6owOWVQ5ye7BJ5rdQMXUM6S5DVViHNEBmGTyPzqieaJ6s0ftXQeGR GP2xVXAjMeO1FwsQNH6fgaYiu0ftVDKkkXWgDOli68UxpmRcW+c8VSVjRMwrq1ODxTRaZzt1adcC rTNE7HOXNn14NM2TOburNsnig2Ujn7qzDBkZQVIIIPelOmppqR0UpqLR2/hK1i8deHj8G9Wnji1g TSXngzU7lgohvWAMunSMSAsVyANhPAlRT/Gc/GZpgp4Cp7aGsWfW5fjo42n7KfxI+fJ0ubO5uLO9 t5be9t5Gimt51KvE6khkZTyCCGBFc8KsWlbqdXspIfb3s9rPFc208kNzEwaOWJiroRyCCCCCPaqb T0IUXHWO57NB8YbfxFHDY/FzwtB4sgGFGuwyCx1qEAYGLwKRcADGFuEkPGAyDmsXB0/epuzNVPmf LUVz1vw74C8OfEX4W+OPCPwp8Zpr+tWV1b+JNM8NaxANO1WExKYbtACxhkUwy7y6SEEwLnBrB13Q qKdRWRqqSq03GG58r61pGt+GdTl0TxHpF9pWrxZ32WowPBIAOMhWAJHowyD2NelCrGeqdzglSlDS 1mZwl9/yrT2i6E8jekhwmHTNPmb3IcG1ob3h7xTq/hi9/tDSLsxSEBZEPzJKoOcFTwRnp3HaqVZw 2Ma+EhiIcs0e3Wv7QbqqC78NAsPvNBccE+wK/wBa61jEeBU4cb+GZ0Fr+0JoDEC60PUIh3KNGwH6 g1osbE5Xw7WW0z3P4MfGPwPrfj/w5piak8FxqPn2YguoihZpYJEChuhO4rjmuXG4inUov5fmXgsm xVHEKTV1qWrbWNMlQ+RqlpKqEoXSdMZBwR146V6EJwlBanh18JXpTalE0P7StF+/e26+oaZB/M1f Mu5j7GfYU63paff1WyXHXNzGP61PMu5aoT7DH8TaDCMza7p6DGfmuo+g/GjngluUsNP4UjVttRtr uJJ7W4hngbkSQuHVvxBIpRkpGUoSpO1ValkT89afKS2odB4n9+lP5BfyHfaPfNTbYH8J2Gmzf8UR 4sP/AE+6f/K4rhrr/aqXz/Q9HD/7rV+Rx3n+5rvPOGmfFAEZnx3oAia47Zp2Aha470WArtcd6LAV 3n96diyq9x3zTA6+ef7J8MbYdJNS12R+3McUCqPfh2NcMfexMv7p6Evcwy/vHnEk/vXd0uee97FC SfrzVpp7g1bcoSz9eadorYta7Iz5Z/ShpLYOWX2TMmn5pq/VlJX33NDQ/DHiXxW8i+HtGubyJCfM uVAWCHHUvMxCLj3NYVcTCk01LQ6qODr1VaC1O28e6n8PPg94D8PeGfGmrXGr+KdQlbXJtC8NyIY7 hXUJbCS8IISMIsh+VHOZG4rw5Y2pWqynT26P8z6ehlcIUY05PX7R8ceJPjN4o1q2v9J0WGz8MeG7 s/vtM0BWiN0B0FzcEmafHYO5QdlHSsHFT9+pue5SprDQ9nS2PK1cDmtYzbVpbEuOlz0TwJ4asNXf UfEXiaSWDwPoYSXUZouHuXbPlWkJOAZpipA9BuY4C1M6jVqcd2SoRXvPYs63rWpeLtbufEGqxRwy ShYreygGIrG3QbY4YlPRFUKB68k8k17+W4JUNam7PEx+MdR2hsLb2/QYr1jyXK5swW+3HFBm5GvD CSOlQZNmjHHQRctqlBFyTaKBD+QaAF6e+agBwPegpE8T4GKlmiZpQzYI5/Gs5I1TN21uSMVhJG8W dTZXpBHNc84HTGR2un6hgj5q5J0zrhM7rTdUxj5q4qkDspTR3enarwDurjlT1OynUO4sNV4X5q5p 0ryOylUtYyvihp6+Lvhl410DG6S506UxDqfMQb1x75VaWFXs6xni17XDzR8A+B4rj4/3XgD4fXkc /wBi8IeHL2N3UkBp8uIiOegJgH4GvbmoYNyn3sfNUoyx7VH+W5vfCLX7z4l+P/2ePAV/BJt8Dtct ciTkMI5DKh/AJGlYYmMaFGrVXWx0YSpLFYilSf2bn1v+154s8QTj4Y/DLSdbl0bSvGOpi01HUo2K kRBo0ClgRxmTJGecAHjNeRldCMuavLdbI9zOq9S0KMXypnlXxv8Agt4e/Zq8O+Gfir8J/Eerab4n 07UYLeSO5u/NXUAwJO5QB/d5XGCCeOK68NiPrs5UasdO5yYzCf2dGFWlLX13PfP2w9Zn1b9mB9Wd DBc3cumXJRSQY2d0YgHrwTivPy2moYxR9T0s3qSqYK6dm7Hr37OHww8LfDjwHpeo6KtxLrXiOytL 7VL+7nM0lzKYg2dxJwAXOAK5MxrOpXUX0Z15bhVhqLlfdHhX7DkgXWf2hz6+Jf8A2aeuzOopxpJH DkEv3la5xEHgqy/ae/ag+LOjfE3V9QPhfwWPs2naHazmEMocJu4yQCQWJAyS6jOBWzm8vwkJUlq+ ph7CWY46cas7JdCt8N/htpXwm/bf03whoWs3d/osWhSz2yX03nS2SPGxEBPoCCRwOHH1qsTiHXy3 maszLCYVYXN1GLuj9TQ/rXyaXvWZ9spO+h8Y/t7x6nL+z3qh08SG3j1Oye9EeceQHI5x23mKvZyN qOKXO+54HEKnPDO23U+gvgpe+Gbv4TfD2Xwi9ufD40m2WEW+NqERgOpA6MHDBs85zmuTHxqKvJz3 uehls6DwsfZ2sd9Zaho1zfapb6fdWcupWzot7HbujSxMVBUSgEkErjGe3SuSaqpJy0idkKlJycY2 uj4NgI/4eIXp/wCpZH/oha9/V5Qk/wCtT5rbOXbb/gFD9qYaj8Tvj98H/gFqOu3Wk+BdTgN/e/Zn 2G9fMmEyeCQIsKDkAvnBOKeVxjhsLPFct5IWbylicXDCOVoni/7Rv7P/AIO+CPin4KXPgTWNSi0r Vdegjm0W9vGmUSJJGfPQHBGQcHI9MeldeX4t4ulUVSOq62ODMsDHAVKTpz0fQ+8v2qfA3jj4i/Bf xD4a+H1ww1x5IpntEl8o38CEl4AxIGTwQCcHGD1rxMtrUqOI56qPoc2o1a+F5ae+h80fsWn4X6R4 18U6BY6B4n8JfFFNPSO+8Ma1dvJbMqEb5oQQCSSQSHBIB+U4Jr0c59pOCktY9zy8idOjVcGrT7XK P7Zfw48T3nxF0H4ka/4W1bxj8IrPTTbXWk6NdtBNpcgLFpgFBPOVbOCPkw2BiqyevTVJ0oO0umhO fUKs6yrSV4LfU+tf2Y77wBefBrwqPhtquqX3hqASRB9akL3UMocl45OcAgngLxjGOK8fM1NVmqis z3MonCeHj7LVHvtefduOx6l2kkfC/wC0T8Ctd1fxifjL8DPESaf8ZtEgSW80qCZd2owgELlcnDlV ZQGGyQDHUZr6DL8alT+r4le4z5jNsC3W+sYZ+/HdHsH7NnxtHx2+Hkms6jpwsPEmnTtp2q2keQgm Cg7kzyAwbODypyOcZPHmWCeErKz06HfleOjj6Li1Zrc+MvgL8HfBFj+2H8U9Lt4L0WngwpfaUGui xWVtgJkOMuP3jYB9q9jHYycsuprqzwcvwkIZlUXY7z9p6K/+Kv7RPwk+AWq69daV4Cv7dr+7W2k8 s3sgErbcngnEW1cg4Lk4zXPlqWHws8Vy3l0OnNXLFYunhnK0WeN/tAfALwh8EfH3wJm8C6rqUWk6 rrsSS6JeXbTLHIkkOZkyQRkEA5HYc9q68DjHjKVRVI6rrY4cwwMcDVpKnLR+Z9c/t2OR+zn4nIYg i9suQcH/AF615WTOKxi5lpqe1n758FeLs9D4k+LfwH0L4a/s+/Dn4z6Hr+st8Rnewnn1OW8ZgfNj LqqKeUCEKFIPQc+3tUMX9ZxE6M7cvoeBisDHD4WGIhJ8x+iXxp8feIfCH7OXiHxto0zjxGujQPHd KMmKWUIpkA7Eb2I968LCUKc8ZyS2ufTYvESp5e6ietkfHXgb9kzwJ4h+AMPxTvvFmsD4iano8utH XY74qlvIY2cxsO4AyrknJO7kdK9epj6lHFqil7q8jwqeVwq4L6zKXvanuH7Ajhf2fbUE5/4nF7/N K4M9tPF272PS4dk4YO66XPAPhR8MdF/ar+I3xk8afF3V9SuTo+ptp1hotrcmEWcQZwp4yQAFAAGA TuJzXfiKzwFKFKitzzMNh1mtepUxD28zc/Zj8Jw/D79q34xeD7PW7rVbHTNLEUF1eSmSXYWgZUc5 wSgYIfp0HSpzGo62EhKSszXKaaw+PnSjK6RQ+J/gLRfij+26ng/xLPd/8I5caDFNd21rO0JuRHCW VGKnOC4Un6U8NN4bL3OC1M8VRWJzX2cnoz3D9r3xXqfwz+Ag03wVLJpy3M9toq3FsxVrW2KNkAjk ZWMLkc8+tcWV0o18TzVNj084qywuF9lT08z5x+JH7Knw/wDBPwI1PxpoXiPVE8WWumJd3Gotdnyd SDhS8ZjGBtbdhcH0zmvVw+PlVxap209DxMTllOlhnV5tT6f/AGe3u5/2bvAtlYXn2W+l0eSOC5Ay YZCXCvj2JU15uN5frbm1oevlrawC5X3PgbwB4c8PfDD4laDp/wAbNF8R6L4xj1R57bxXa37m01Qk 4USsBkKScllbJzhwATXt1ZfWKT9lqvQ+ew0Pq1VfWdJN73P1GutSXBwa+d5Hc+udXTQ5e91MAH8a 3hA55VTjb/VRlua6YUzmnUOIv9V+981dkKZyTqHDahqn3ua66cDjnM4XUNR6/NXZTgcU5nGXt9kt 81dUInNOZy91d5JJauhROWUjFluDzg1somLkUmuTVqJDkM+0n1FPkQuY+g2i71NzziFovaqAhaP2 oAgMY6U7hYgaP2qiStJFkUAUpIfSquBnSwDnincaMi4txycVRaZh3NsCDxVlqRz1zajninc1TOcu bPr8tM2izAubNeeKpNte6Xe7sYF1YrIpVgQMgggkEEHIKkYIIPII6VFWlTrQcJ6pnRRrSoTU47o7 Dxzok3xW8PX3j3ToWk+JehWok8SW0YG7WrNAFGpIo6zIABcKByMTAf63HwuYYGeWz0+B7H2uBx0c dHT4z5gWfIBDZB5B7c1ze093Tc7dL6kom9apVej2IcFPVHffDHxnbeB/Hfh3xHqMfm6JFKbfU7fG RNYyqYrhSO/7tmIHqBWVVKrBrqaU24z8j03xL488ffC/xFr/AMMdcvrXxX4Q0u6K22meKrddStpr Y4aGWJpMvHuiKEPG4PoazpRVRb2ZcnJfFsYn2z4GeKlJns9e8Bau4+/ZMdb0wtx1jkZbmIE5yRJO fRa0hUq0npqZqnTn5Dm+CXivU45Lr4f6rofjmyRS7f8ACK3omuY1AyTJZSBLmMY/vxirjjH9vQiW FjKX7tnk2pWWpaLdvYazp9zYXyEgwXsLQuCOCNrAGt411L4dTN0pc1rFTzT71p7RkezF840e0kLl a2Oo8D+IR4Z8b+C/EjsFi0rWLK+cnONkU6OwOOcFQwPtWdepzQszSCaakzS+JWly+F/iN488PfPG bDV7uEpypGJW7Z9DTo1k6Sd9zOrh4+0OLN1Kc7ppD9WJ/rWvtn3M/q8F0GGYnqSfqc0e2fcfsILo NaRe6g/UUlUm+o/Y3+yj0n4YeO5PBvifT57u8mTQJmMd3EpZkVWBAfaM5Kk5GK0p4lwepw4/L6eL g4uPvH2BdfF74e2nkeZ4qs3MoBHkEy7c/wB7AOPxr1liKbW58SsmxMrvlN9PHfhCS3juo/E+mtA5 RVcXC8liABjOckmrVak+pzPAYmLacDqPObAPY8g9j9K20drHLKLjGzR2WlzD/hBPGB9L7Tv5XFcN df7VS+f6HoYf/davyOLaf3rtsecMM/HWiwDGn9P1p2AiM/HWgCFpz60AQNOfWgCs8/vTSLKrz+9P YDs/F8/2Twp8NNJ6N9huNQYdM+fOdpPrxHgVw4f3q9R97HoYvTDUl2ueaST+9eg1Z2PO3dyjLcBQ WZgAO5OBQ9d9ClGS6XNXSPC3irxI+NC8PaherjPmQQMUUdcliAAMc9a56mJo0viZ2U8LiKvwI1Jv BmlaSX/4TDxxpOnSJ1sdLb+1Lrd/dKxHy0I7iSRDWDxc56UYX89v6+VzoWChT1rz5X95Qk8VeBNC G3w54MOqXyn5dR8VS+cM9itpGREP92Qy/WhUK9XWc7eX/B/4Y09th6X8OF33Mr/hJvEvxE1rS9H8 Sa9INABMtxApEFpZ2kSGSZxEgCKqRIxOBxipxHs8FRc4r3jpwMa2Z11Cb90+KfiJ42n+IHjfxH4v lV44b+5JtYH629soCQxgcAYjVQQABnNfP03KPvH2/IoLlijjxJ71o5u9xcvK/ePS/h98PNT8d3F5 L9qj0zw7YQtcX2t3anyLKJcbnbkZxkAKOSSAOTWqi3qjmnVjCXLHc63X9Ws9Ui0vQfD9pNZeCdHL /wBn2k/+tuZWwJLu5wSDM+Bx0RAqDha9rLMtdJ+2rbnjZhj+deyp7GfBbdOP1r3G4yVmeI6jeiNe C3zjimZNmtDBx0oIbNGOLA6VBDZcVMDpQS3clC8+tBNxaBjSO9ACZNQAlOxY4Eg1LC5bjk5FJo0T NGCcZAzWTRqpG7a3JBHzVjJG0ZHT2d8QVy1c8onTGR2NhqHP365JwOqnUO0sNTAAIeuaVM6oVDtL HVcFfnrjnStqdcKh2FnqiuuxjlWG0g9weCK5nTafMjoU7px7nnnwc+Emj/CrVvEmsWOsSX0+rEKq yQCL7NGGLbAQxzkkc8dOlXiq061l2MMFgo4aTn3Nz4dfBTQvAvxM8TfEex1eSabVRP5WnmAKtp5s gdtrBiSMjA4HFRicXKrSVGxthsBHDV3iUen/ABS+HHhr4w+Gl8PeIHlglgk8+z1C3x5tpKBjcueC COCp6/UA1w0KssLO8dup34vDQx1Llk9TyXSP2WpNQ1rQL74mfFrXPGWjaK4e00i+jMUQIxgMxlck cLnABI4ziumpmMY6UY8rOGllEuaMqs+ZR6H0L8Yfh1a/GHwDeeA5tZbSYJ5oJRdQQCcp5bBgApZR g4x1rz8NXeGq+0PVx2FWNpcux6j4XtF8PeHtC0BLkzpptnDaCcqFMgRAoYqCQCducZrlqSVSq5rq dlKDo0lSep5j8E/g5bfB278eXVv4kk1Q+J9Q/tBklthD9mOXO0EMd33+vHTpW+MxTxSjFx+E5cBg fqkpyUr8xyPxL/Zlt/GHj4fFDwH8QdT8DeNZoxHd3umQ+ct2AAuSodCCQADyQcDIzzWmFzFUKXsq seZGGKylV8R7WjPlbK3ww/ZVi+HXxStfipd/EzVvEGum3ljvP7UtwXupZFKmQybyQAMYQg4x1p4v M/b0PYRjZBg8nlhcQq06l2fZCzjNeNKOmh7ujumZ2u6TpHifRtT8Pa9YxXujahC1vc2k4ykqMMEH +hHIPIq6NSdGSlF2aIr0Y4ik6dRaM+Ibb9i7xB4WudSh+Ff7Q3ifwn4cu3LnSooHnCZ/2lnjBIHG 7bn3r2f7YpySVanzSPn3kdSF4UKvKn0PcPgR+zr4b+B7a3qsOvalr/i7WQBf6zqLlTMoO4AR7iBz ySST74rhx2Pli9GuVdEell+WQwb5lK8nuaKfA62T9oCb48/8JNKbmTTRp/8AY32UbABGE3+buz2z jb+NL67/ALN9XcbAsvX1z60pakHx4/Z98PfHGDQryXWrzQPF+iP5mna/p67pIASCVYblJGVBGGBB 5B60sHmEsHeNrxfQMxytZg1OL5ZLqeG3v7E2qeIda8N+JvG3x38QeIPEWkXcU8dzf2QaPyUcOIlj MxKElclgxz6Zr0P7ajCm6dOlZM895BUnUU6lW7R9S/GL4by/FjwVceEbfxhqvhud5orhNR0lsOGQ 5UMAQWXODgMOQDnivKwuJ9hU53G6PYxeDeLpqkp2a6nlvwi/Zrm+Hvj3Ufid4y+JOpeNvG09mLCG /v7cW4gh4BG3zHLHAABJ4GeMmurF5msRQ9lCPKjiwGUPC1/bTlzMl+Lv7Pnif4ieMU8Z+FfjZ4h8 IXb2H9nT2drGbmB4SSSFQSJtznJznnkYpYPMYYSlyTp8xWPyyeLq89Opy+R6T8FfhLoXwT8CWPgj Q7ya9SOV7i4vrkBXuZnILOVGQBgKAuTgDqTzXPjcVLG1Pay08jrwGDjgKfs4O7PWd30ri1vZHbq1 ufGHxD/ZHufEXxC174jfDv4va14H1jXUKanHZQtcrcEgBiGE0ZUHAO0kgHkYr28Pm3s6ao1Yc3Ls fP4nJZ1antqVTlvv1Pafgb8GPD3wL8Gnwpol7Pf3NxO13faldKFe7mIAztBIUAKAFyfXJJNcWOxk sZP2ktOx6OXYCOAp8kXdvcyfBfwPtvB3xj+Ivxfj8Sy3c/iuJYn0trUItrgociQMS33PQdauvjfb 4eNG1rGeHy5YfEzxKd+Yo/Hf9nrQPjaug6kdbu/D3jPQ5N1hr2nrukhBIO1l3KSAQCCGBB6Hk1WB zB4ROLV4voLMctWPs4u0l1PEJ/2KtV1rxF4W8XeM/jtr3iHxJo15FcLcX9kGRoo3V1iVDMTHkg5Y E5z0zXas6jGm6dOlZM8z+wKkqkatWrdo+lvjh8LYPjR8PdS8ATa3JpMd3NBMb2OATlfLcPjaWUHO Mda87CYt4Oo6jVz2cdg446iqS0OP+JnwDtfiL8G/D3wgm8UzWMGli0H9praCVpfITaMxlwBnrweP etqOO9hiHW5dDlxGWLEYVYdzs/Q9bvfCujat4LfwLrsK3+iT2A064SQbftEYQISQM4JxkYPBrlVX lqe1hud0sLGrQ9hJ6I+Lof2KdTsdN1DwfY/H3xRb/DO6d2PhuKAKAGJIVpPN2kZwSPLAPfnmvY/t mMmp+z95dTwY5FV5XSVX3D6M+Bnwpt/gh4Dj8DW2vyavEl3Ndfa5bcQHL4+XaHbpjrmvPxuLeLq8 7R6mX4P6hR9lzcyPFvGH7KjXXj7WviB8MfinrHgPUtZy2o2+mQedHcOxJZlAkTGTyQcgHJGK7qWZ pQUK0OaxwV8ok5uph6nKmafwX/ZrsPgx438QeNbbxzqOt3GrWZtpo9RgHmFyyO0jShiWJZWOCO/U 1GMzF4qmqfJYrA5WsFN1VO7Onm+D1sfjwnxx/wCEjlFyun/2f/Y/2YbMbCm7zd2e+cbfxqFin9WV BxNngUsT9Zctex1/xG8I+HviX4S1bwb4nhaXSr5QC0ZCvC4OVdSQcEEAj9eKyw1SWHnzw3RriqFH GwcJ9T44uv2RtXvPD/8AwiGtfHXxDe+ErZT9i0lrbbFbsPuFlMpDgdlAHtivajmtNS51TtI8CWTS cPZ+107H0P4Q8Jx+Cfhzpfw9g1u4ljsbJ7NdShUQS/Nu+dQCQpG7I5PIrhqVVVq+0X3HpUaPs8Oq B8xRfsyyPeaHb+K/ivrWv+E9IuTdWuiXcOArE5wZDI3BPXCjPOMZr01j/wB3aELM8dZW3NOpO6XQ +l7zVQAfnrhULu56jqWVjkr7VuuH4rqhTMJVTi77VfvfOeldMKZyTqHF32qfe+bvXZCGhyTqHF32 pdfmrppwOWczkL2/J3fNXXTgc0pnL3V4SSM9a3jE5pSMGe5684NbKJhKRnvP15rRIzZWMpPfirSJ E8ynyk3PqswjHSuVOxyWIWh7YqrhYrtD7UE2IGh9se9VcZXaHr60wKrRe1O5Nis8PtTuBRlgB7Zp pgZk9t7VQ0Y89r1z+VWaIxLi068YqrjRgXNn1wKZqmc/dWXX5apM0UzBuLPGcLVXRomR6TqWr+Gd XsNe0G9ks9YspPMguY8EqcEEMpyCCCQQQQQSCMGssRh6eLhyy+E6MPip4aXPTdmO8XfC/SfiSl34 r+E2nJZeLdhn1XwBDwJXALPcaUvWSM4Ja25dOdm9eB8Lj8tr4Gbe8O59tgMxpYyCT0l1R8stJJFI 8MyMkqEqyOMFSDggg8givPUk9j03C+wedTU7bicX11PdvEMp+IHwl8PeMo18zxN4HEXh3W2LEvNp 7E/2dcsDyQmJLVjnjy4M8vWMZ8lS3R7Grhzq54es5rqU+VnPy3dh6XDRywzxuyXERDxyoSrRsOhU jBBHqDTlJSGo8p65pfx5+J1hbJp2o+IU8RaOoCnTvFtrHq0RA6AtMC4A6YDisnST6lqq49C6vjv4 Sa8f+Kq+EJ0u4Y/NfeB9Vksjz/dtpxLCMewpWqr7Qc0JfZsL/wAIt8HdZAbw98Xr7R52/wCXTxjo cioh97q0aQkfSAU1WqR6XD2UZbSsMm+B/jC/WWPwzrHhLxPEUIH9geIbR5WB44tZninOfaOmsVT1 uT7Cd1odp+0V4H8eWPjRPFmseDNasotd0nTdUuZbiwmVY7mS0iNyjMVxlZhKDz796jD14clrmlej LnbPmx5Wj4kQof8AaGP511e0j0MLIQT56NT9p2FyC+f7mjmDksHn+5o5kFhPOo9oxcsew1pVPzYG fXFP2j7i9nDsfVH7PWp6zfX2vSahqt5PZwWkcUUNxIzKMv1Gc9MEcV6uXVZSqWex8fxLQp06adLc +2tJnH/CA+Mznpf6b/K5rsrq+KpfM+ew0r4OtfyOGNxjvXdy+Z52/Qabng80ajsRm54PNHKK67kL XGe/WnZ9gsiFrn1NF49GCUyE3G7heT6DmpuujNFB9S/YaNr+sPs0rQ9QvXzjbaW0kpz6YUH1rOeI hQXvM2p4Wdf3kjeb4aeO1QG90ZNKBwM63dwadtycDImdW69gCfauZ5jhnHnvf0Tf5HUsrr8y0Ox+ JHhvw/b+JlsdV+IejWcOk2FppwtbOG4vp4zHEpcFQqx8SO4GJPfjNcmDxFXk9pGle/W/n956GOwl Bz9m6lrHnj3Pwp04f6vxNr04zy7w6bA3plFEj8+z11r63Xa+x+JxcuFoL+f8Cm3xJi0458LeCfD2 juOlzJAb+dfpLOW/lVfU5z/iy5vwBYxUv4Ubfich4g8ceLPEqmLX/EmoXtv/AM+0kxWAfSJcIPwW t4YWnT+GJjUxtatuzjJJsDA4A7Ct17phq9WUJZevNPzZTfREXxGu/wDhCfhBLc+cI/EfjlzZW8RG Hh0lGzPIO486VFiB7pHKOj185m1VValk7KJ9lw7SVODklrL8D40EgHOfxrzFP3btH0sklK/Vn0R8 If2e/FPxKs7nxbrF5B4Y+F+nqZb3xRq3yIyA4ZbdD800meBtGM4GcnFJVJOShBXb2MqnLGDlN2R3 njDxZo9zpFp4A8A6fPYfDrT5BIpu8G61aZcgXFyVAGeSUjHCA9ySa+vy/LXRj7SvufIY3He0k1T2 7nAw2vI4617B5jkakNtyOKDNyNSG36cVJDZoRw47VNiS4sWKRBMExQAu33oAYRmgBhHY0ARnjrQB H/nFKwCg4ouWKGIOakC3HKTjnpUNGsWakFwQRuPNZtGkWbVtd4I5rFo2UjprK/x3xiuecTojI6iy 1HGPmrnlA6YzOss9VwF+aueVI6YzOtstW+6N361zSpHTGodXZ6xjb81c0qJ0RrHV2mr9PmrCVE6I 1jp7XVycfNXNKkdEap0Ntqq8fNWMqRsqpu22qD+9+tYumbKobEGpDH3qzdM1VS5qQ6iDj5qycS1M 0o9QGPvfrWbgaKZcS+B/iqeQrmLiXg9alxLUiwt4OOaXKVzFhbsdc5qHEpSJftQpcocxKLkdjSsV dDxcDsafKLmHfafelYdx/wBoHrQFxfPpNBcXz/cUrFXDz/cUWC4ef7inyhcTz6OULiC4x3pkjTcY 70ANNwPWjlC5GbkdzTsFyM3QyafKTzETXQ9adhcxC14P71PlFzFZ7weppqJLkVHvhjrVKInJFOTU AM/NV8hm5mbLqOP4vyrRUzN1LGdNqQ5+atFTIdQx59UHPzVoqZlKoYVxqo5+at40jF1Dn7rVsbvm rSNIylWObu9Xwp+aumNIwlVOTvdZ65b9a6IUTklVOTvdXPPz10QpHPKqchfarktlq6Y0jmnUORvN SJz81dUaRzSmcrd3+f4q6YROecjnLm7zkZrdI53Iw57jk89a0SMpSMuSUnPNbJGNyozkk+lWZjNx oATc3rQB9mGL2riOciaH2p3AhaDPancViu8HtTBorPAcZxTuFiq8HfFVcRVaHNVcRUkgPpTTJKMt ufSqGjMmtuDxVXGZE1r14qykzDuLP72BTuVcwrmzyTxVItGDcWR5GKtGimYU9mRnK1SaLUktWZJi ntpo7i3keKeJw6SxsVZGByCGBBBBGQR0pThCquWSujWnVnB80HY2/Ed34R+JEZHxQ024tvEpAWPx 3oMIa7OAADqFrkLdgAcyKUn7kua+PzXIalO9TCbdj67LM8jK0K/3ngHjT4VeK/BlgPEUbWuv+BJX Cw+K9Ac3NkSeiTHAa3l9Y5ghz0z1r5hzSfJJWkfTpe0XNDVEHws8d2HgvxQJfEFpJe+CtXt5NJ1/ Tozg3VhNgSbTziRCFlQ9pIkPaoqrmjZboqDsrMofETwbe/DrxdqXhe7ukvbWPZcafqsIxFqljKN9 vcx4JGHjIJGeDuB5Wrp1PaRFKHLqcWJx61pzmdh3nU+ZhZDvPo5vMXLEUTe9PmDliL5w7803P5A0 7LU+i9Q8d+NNF+Enwd8R+EPGGuaJNp0mq+G530bUp7Mnyp0vYi3lsucrqLKCeoix0UVzKKc3Fs2n fli+Y5eP9oT4rldmo+JLXWYz94eIdG0/VC3XrJcQu4PJ5DA+9aezpLZEc8u4/wD4XSLtidc+Evw4 1TdnLyaRcWj5OeVNvcRqDz/dI9qOW2zDm8hp+IvwxuhjU/gPp2SME6R4ivLHqOSNyy45HHXHTnrS tU/mHem/sinxP8B7jmT4W+KbAkA4tPFC3IB7gGSBcj360Wq/zBam/sh/aX7PMjbn0T4jQBjykN5p 8oj9dpYAnHbIFJymhqMGT2Uf7N91e2dpJqXxVt455kia4lg0fbEGIBdsSdBnJq4Sm2jOooKLZ9+a XpXwU0hbZdLTxpBbw2wt4o44rDAjByOd2SSeST1PPWvqsNRr04+6fmmOxVOvUkqjPSrC6+GcfgHx RJGfF72h1bTY5RIlksjMYr1lCkMQFOxiT1yFxxmuevLEvE0Yt9JfoGGWGWFquO2hxf2/4W/8+Piz /v8AWtejbEdzz74TsN/tf4ZLyvhvxBIR0V9SiUN9SEJH4UcmIf2/wDnwi+wNPiT4dR/6v4eX8x65 n8QOoB7DaITkfiKPq+Jb/i/gP6xhF/y5/EiPjTwtF/x6/DXS8joby+uZvrnBTPt6UfVa7/5eB9aw v/Pn8SI/EdoeLDwT4QtO26PT5JiOc5PmzMCfwojgp7Tnf+vIPrkF8EbFdvit41QbbTUbKxQdBp+l WVsQfXckQc/iaccvw61d382H9o118LX3HP6n4+8Zaqhj1PxfrV1CRjyrjUJmQD2UtgDnoBWlPBUK L9yO5lUxlWonGTJPh9p0Ou+OPDWnXJVbJrpJrpzyEgjzJKx9gisajG+5h5OK1NMCpTxEYtnK65rs uv6zrOvXGRPqV3NeOp/hMjlyPwzgVtQpKjSVNLYwxE5VqsptmFLccV0PmWqM1FbMpvP71PvMpJlK Sf3p3tuVqilJN707psLNLQ6TwV4cj8Vay8eo3LWnhnTojfavqH/PraIRuwf77nCIO7uK5cZXVNcq 3ex2YPD+0d/s9TzD4sReJ/jX41hg8I+F5JZ4Yx5cELCK20XT0AjhSWZiI4kAUfMxGSOMk4PgZlyY eMIbvufX5M6uIlOVuWJ6N8P/AIH/AA+8CWB8Y+O9UtfEL2cnltdeU7aRDOBkw2qEq+ozg8EYSBT9 8noeXDYSrXkoRPRxOOhh07a26lX4kfFHXviLNbWDGSy8JWBAstIVwQMDCvKVAUuBwAoCIOEAGSfr 8BlcMFrJXkfKY3MpYh2b0POIrX/Zr1JI81u2ppxW3tSM2zSig4Hy1Jm2Xo7f1FTcVy2sWKTYiUR9 qADb7UAIRmpAjIzVAQkYoAioAiJx9KAGnqagsMmqaAerEHpUlpl2OU5HNQ0NMvRTkdWz6Vm0aJmz a3eO/wCNZSibxkbtvfYxzWDgbRmb9tqWCMtWUqZtGZ01nqmNvzVzypG8ah01pq/T5qwlTNo1Tp7T WOR81YSpnTGqdPa6z0O6uaVE3jVOjtdZH96sZUTpjVOhttY6fNWLomsaxuW+sD+9WLpG8apswauO PmrJ0zRVDWi1UEferN0y1UNGPUxwN3WodMtVDQj1McfNWcoGimXU1IetJwKUy4mog9/1qHAtTLKa gPX9aXIPnJ1vx/eqXApTJlvh/eFLlHzEgvl9f1pOJSkSfbR/k0uQfOOF6ueuPxpcgcw/7YP71HKH MH20e9HKHMJ9sHqaOUOYa16PX9aOUOYb9tH+TT5Bc4w3qjv+tHIg5yNr4Y6inyk85Cb8f3vwp8gc 5A2oD1q+QjnK7agvr+tCgHOVX1Ic/NVKBPOUZdSHr+tWqZnKoUJdUH96rVMl1DOm1Uc/NVqmQ6hk zasOPmq40jJ1TIuNXBz81bKkZuqYdxrC8/NmtVSMpVTAudZJz81bxpGEqxzd3rPX5q2jSMJVTm7v WOD81dEaRzyrHL3mrZBG6uiFMwlVOXu9Uzn5q2hT1OeVQ5i61IEk7q6Y0znlM525viSfmNbxgYSk YNxd5Jwa2jExlIx5bgknJrVRMXIz5Zc1okZtlQvntWiRFxhPc0hBQQFAH295XXj8a8+5nYQwg/h0 ouVYiaHnpVXHYheDpx+dFxcpXeH2p3CxWeDrx9aaYmipJbYBOOKpMmxUeD2/GquKxSlt/ammRYoy W/bGatMLGbNbdsVaYzHntM54qkx3Ma4svaqTKTMO5ss5wK0RSZhXFiRninc0UjCuLI5JxVJmikYt xZMM8VduiKjPuZVnJ4k8M382t+CfEF1oWtyIY5ZbUgxXiHrHcwkFJYyOCHUgjggivEzLJKGN1jpM 9zL86r4LR6xOS1u8+GXiW4W0+IvheTwB4nkOB4m8H2puNJuz/fm07IaIk9TbHHpCK+CxmAxWBn+8 2PucHjqGNh7j16nqWk/Bvxh8Svh1b+CLKTTfFlzoXmzeDPF/he4F9DcIcyTaRdAAS25Y5kh81ABJ uQkbxXnuvyS2O/2UXGz36HxHIZIZZYJo3inhYxyRSKVaNwSGUqcEEEEEHkGumM+fU55RcNBPN96p yk9BWtqL5vuKLiHeb7mmpBYXzfeq5gauz2jwvIdd+CPxU0PzCbjw9qGl+JoE6kRFnsJwo9D9st3b 2gB6A1jKVqnMauPMjxjzW9a19oZWF80+tHtAsHmn3quYXKHmUcwcoeafejmDlDzT70cwuU+gvhZ8 ZP7BSPQPFU8j6SCBb3rEsbUYxsbuY/THT6dPby3NfZP2dTY+Vzrh763evh9GfdWiapZ6j8KfFF7Y XcVzavr2kFZYXDAg2+pHqK9OrOnXxtDkelpf+2nyUKNWhhaymrPTQ4v7Qa9W7vZnkNO12NNx3Bp8 vLqinGLaaGG44oAiNx3BoCxC0/8AtUFEDT9eaBkDTe9P4RbO/U9B8ISf2R4U+IPixzscWqaHZluN 093kS7T7W0dwD/10X1rzcV+8qwpdHq/l/wAGx6eEh7KjOs91seVvOOua9HY896ld5uOtAJFN5ge9 WrdTSz6FN5vek2tkOMHbU3PC3hDxZ471D+y/B/h+81W7DYf7LGSkXcmSQ4RAACTkjgE1zVsXRw0b 1HY6aGErYhqNNXPVvGGvfCj4d+H9F+HWnX97498SXsyTXOgeEg6JreogEJE9yFLtDFkhUhQ5O5yy cY8CtiqnP7eouVdOv4eZ9PhsDCcVQp+936HIXt3deHwsnxTfTrnXIn8yz+FnhZ/I0nRXwMSahLGx MswAwV3vL6unBE4LLa2Nn7aeifU78ZjqWBp/V6O66HmniDXtd8Xagmoa5diV4kENvbxRrDBZxDpF DEoCRoOyge5ycmvssPg6WEgowWp8liMVOu+aTM+GzPpXS2crZox2nTioJbNGO06cVLYnIurbdeKm 5DZYWDHakFyUQkdqLiAxn0/KoAYUPcUAQstBRC3rQBCwOKAIG60AQkZqwIycVBYhPagA3etAD1cj oaB3J45jUl3L0N0R0P4Vm4lqRpRXZGOazcTVSNWC+I6molA0UjdttRPHzGsXA2jM3rfU8Y5rGVI1 jM6C21UjA3VjKkbxqHRW2r7cfPWMqRsqp0FtrHT5qwlSN41TfttZ/wBv9aydI1VU3rfWenz/AK1i 6Rsqpt22s9Mv1rGVI1jWNmDWcD7/AOtZOibKqasWsA4+f9azdItVTTi1jgDf9ah0TVVTQj1ccfPW bpFqqX49XH9/9ah0i/aFxNWH96pdMpVC0mqj+9+tS6ZSqFhdVBP3qnkH7QmXVB3ajkK9oS/2mOzV Psx+0H/2n/tfrR7MftR39p/7Q/Oj2Qvajv7TH/PT9aPZB7Ub/af+0Pzo9kHtRDqY67v1o9kHtRh1 MZ+9R7MPaEbaoO7U/Zh7QgbVB/ep+yI9oV21Uf3v1qlTE6pWfVRz81PkJdQqPqw5+f8AWqVMn2hS k1cc/P8ArVqkS6pnS6wOfn/WtFSM3VMyXWBj7/45q1RM3WMufWRjJf8AWtVSIdYxp9ZA/j/WtFSM nVMa41nr8/X3rVUjJ1TCuNZ6/P8ArWsaJjKsc/c6x1+cfnW8aRhKqc/c6ufm+eto0zGVU5651Xr8 361vGBhKqc/c6mTnDVsqZlKoc/c6jnPzVsoGMpmFcXpJPzVqoGLmZU112zWyiYykZUs5Oea0SM2y k0vXmqSsZsrs+Ty34VSFIZuNUiRAcmgBQf171RAvy0Afdxj4+XvXkXEh4jGORgii5okJ5IxyOtFw IjDyQB0ouOxC9uOMCquTYrvAADxTTE0Vng4PFVcVik9uT26+1UmKxVa2J/h571SkQ0VnsmOV2/jV KRLRSk09sHK1SkKxnTad1zVcwjKuNOUfwn2q1IDGuNPU5+WtFIsw7iwUZyKpMaZg3NiuScVaZojB ubEc/LVLXcfNb0MWex6/LVXjLRGkZSXoc/qOi2t/byWt7apNbvwyOMj8PQ+9Z1sPDE0+Woro3oYm eGmpU3ZnlB8IeLPBGrp4o+GXiLUdL1aEh0exunt50IOQFkUjcAeQG/WvkMw4caTlR1XY+wy/iSMn yVtH3PcrDxd4K/aE0g6X48+F1pd/HzT0dru60a4Oj6r4tiUZaeGQK0Mt+gBLxTRP5w5Qhwc/GVqF XCy5bH11GtDExumeBP8ADPwT4mlkX4bfFGwOoAlf+Ec8dqug36uMAxrMzNaSEHIA85HJH+qGcB88 oq5PJzOxwHi/wB478AzCDxl4S1TSMjckt5bMsUi9mWTBRgexBwacal9xchxomyAQcj1FaXuS1Yd5 n0ppgke0fAXU7FfiDF4X1aVY9E8ZWF34Zu5HOBELuIxRyfVJTGwx3ArKppC5pTdzyG+tb/S7290r U4DBqdjNJa3MB6xyoxR1P0YMKuM00ZtFfzPrVqQWDzPrSuFhfMouFg8yi4WDzKdwsHmUua0tNhcq k7n0R8OvF+q+Efgp8QtU02dgI/GfhlZYCcpJGbPXSykHpnavI7gVrRxc8NiI1E9EceMy+njMNKM1 qfSGieIbDxDpdprGmS77O5XK56qRwVI9QeDX6DhcRHFxuj8nxeCngKzp1NjTafjqK6VvZnGorm0G NP70DsRtP/tUDIWnoKsQvP70BYrSXAVWYnAAJ/Cpl+A1G6S6npfxAceGtD8H/D5flvrKE6rqwBHF 9dBWEbY7xwrAhHYhvWvPwf76rOq9nt8j0sX+6hCgt1ueSNN716B51iJDNcTLb28by3DnCxRKWZvo oBJqXJLdmkYN7I72L4YeJYbaLUfFNxp/hbSpF3JceI7j7O8oPIMduA08mf8AYQ++K46mOi/3dNXl /XyO6GAnFe0qaJ9TU0W08ArqVro3hTw/qXjrxPKSEk1Qf2fp8ZA5fyFYu6DqXlkQYHzJjIrmr1q1 P95WnyL7zsoYanUkqdGHO++x2njDxh4zt/Dv/CLWfiu08N+HtQgKXniGK08gXdvkA22h6XHsMsOR h7qQpHIekgXGfBhOpjq/Lhad/X/gn1CwtLBUb4qpZdjwqx1q08LwXtn8PNPm0iS8QxXniG6mE+r6 gh6o9yABFEcf6qEImOpc8n6fCZGv4mKfM+x4eJznlj7PCrlgc3DYhQFVcD0H6178YxguW1jwZVJy nds0orPp8tF1F2Rnre5oQ2f+zUNhcvR2v+zU3IbLi249KlsROsIx0pJgPEYWlcVwKD1pDGFB60AQ snbigCBkPpQUV2X2oArsB6UAV2UNQBCy980FkBU9KAIjkfSgAoAbu9qAHBvSgolRyM5NJoEy0k3A 5qGaoux3BGOaTRVzShu8Hg/hWbiWpGrFfEY+as3A0UjXg1A5A3VjKBqpm1BqZBHNZumaqqbVvqpz 96snSNY1Tbt9WYc7qylSNVVNqDWOnzfrWMqRsqptW+s+rcfWspUTSNU2Ida4HzVk6JsqpqRa10+b 9azdItVTVi1oHHzfrUOkaqqaUWtf7X61k6RoqpoR60P71S6RarF6PWv9r9ah0SlWLaa1z96pdEpV S0mtDj56n2RXtiwusj+9R7JDVUlXWR/eqPZMr2pKNZH96l7IftR41kdn/Wj2Qe1Hf20P7360eyD2 o3+2R/fP50eyD2o06yMffo9kHtSM6yP72afshe1IW1kf3qaoh7UrvrYzndVeyI9sVn1rg/N+tUqJ LrFSTWv9qn7In2xSk1kc/N196tUiXWKMmtdfmq1SIdYzJda6/NWipGbrGXPrXH3q0VIzdYy59a4P zVoqJm6xjT6z2381oqRm6xj3Gs5JG6tVSMnVMWfVzz81aqkYyqmLPqp5+atVTMnVMS41Nmzlq2jT MnUMSfUSQfmrVQMnUMia/Jz81aqJk5GVPdnpnitFEzcjOkuMjrVqJncoyTZHWtErGcmU2kJq7E3I y3rzRYBmTQQA6igmQufQVYh69aAH0Afe+BleMdq8cXUm8tSCcYPSlc6Ogoi4wAfpRoK4fZ2LY2/n RzILjvsMjEEISOhwP61POFh50qQjnAyO/wD9ajmDluM/swAfM2PoO340+clorPZW6EqxBPbn/CrU ibFCWKBPmVOPp/jVJkNXKMqKeUQnH6/lVpisUZI2fOxapSJsUZLOd85Qj9KpSCxnTadIeHOKpSIs Zc+lYB3H8cY/nWqkUZE2ljn5M5quYdzGuNLGThRgdavmC5g3OmgZ4A9qtSGncw7jThz8v5VakWnc xZtNPOE/SqTHcyJtObn5KtO5SlY5jV/CthqbQTXMDJe27iW3vbZzDPbupyHjkUhlIIBBB4PSuDF5 fh8UuWcT0cHmmIwLXIy34q8D6H8X4XfxPqtto/xS2hY/F0sWy010gYCanHGp2TEDH2qNeT/rEJOR 8dj+Gq2HfPhnzLsfYYHiSjX0xCs+58teH/iN8UfhZPc6HoPijUdMs4pHSXR5iLmwlIJBJtpVaFgc cPsyR0NfOVsNOD/eRsfQ0sTGa/dyudOfix4I8Qjb8Qfgl4eubluG1bwlNNoVyT3dkQtFIT3ygHtW HK4/CzZSUn7yG/2D8BNfG7RPiR4m8LXbfdsvFejx6hCPUG7tWQgDsfJc0c01uhuEVshy/BHxdO8V 34D8YeDPFMsTpJA/h7xBDDchwQUZLW78ickEA4WMkH86bnJLUShLod1+0p8OfHNpqPh/4uax4B1r RLfxnZrcanBe2EsK2mrRARXa8qB5buqzIwJDCXIJ5xNKcV7jHKNz5WMu04bg+hrVVIvQz5LB5vuK fOgsw833FHMgsxfMo5wtEPO96OdhaIed70OSW4n8VrHsmiyf8Y+fEw/9Tn4Y/wDSHX6zk5SmrGsY 3g0zU+Bvimy0zU7/AEO8klWW/wBpt2Llk3DJK7eQCeue/evpchxkaMnCTvc+P4pwM61FVoL4T6pM 59a+0jHRNrQ/O/eitBhuO4NK6EkyIzn1ouuxVn3ImuO2aHbew7S2IjMX+7z9Kz54vqX7GSV7Ht/w p+GfiTU9Rl8Xav4SvpPDOgxfbtl1H9li1KcEeRAskpVMFypc5wEDE8V5mNx0I/uYS95nrYDLZzXt pxskc5qvhFrnU9Q1n4gfEvw3YajezPcXMdjOdWuHdiWO1bcGLAJwAZhjgVVLFWhFYaF/w/PUiphk 5udedjM/tH4QaGc22keIPFV2vIk1O4TS7ViOh8qLdLj1BkPpWlsVV3fIvvEnhKW0ef8AAYfit4xu GTSfBGn2HhyOZtkdr4VsRFcSk9B5+GmJ56qwJoeForWo7lLFVG7UI2Kl58P77T5JtR+J3iQeHrmb LNaTqdR1i5PHP2UMGQn+9cPGPr0rKeLbXJhY8zf9bnRh8FJzc8VLlidNB8Vj4Y0G78L/AAo8MReH bC7QLe69qRS/1jUsc/PIVEUS5AIjRMD3IBqKOQzry9rjp8y7HoSzijhKbhgoW8+55ZMLq/u7nUNQ uJ7vULl9893dytNLM3qzsSxI7ZPHQcV9Hh8PRw6/dxsfP18RUxbvJlqK0XulaKV3qZSvayNGKzj6 bfyqXK5FzQis4uOo9qnmJuXo7KMfxY+oqHNhctLZDjDqf0qeZiJxZOBwFP0IqedgIbRh96I/hS5g ImgA6qR7U+YCBoV55ajmArPEOzCncdis0R7YP0NFyis6OvZuadxFV2Yd6YEDE57UgIGOeQuaCyu2 3nigCI4PfNAEJ9QaAIiT1qwG5FQAmccYoAeG/GgpMcGx3oLJllxyeKTQrltJunNQ0Vcupckd6lxL uXorsgdazcS1I0I70g9f1qXEpSNKG/Ix81Q4mikasOpEcbqycDRVDUh1Qj+L9al0y1UNWDVcfxVi 6ZqqhqRatwPmrN0zRVDSi1jp83aodItVTSi1j/aqHSNVWNGLWunzfhUOkWqxfj1rp81ZuiWqpej1 v/aqHSKVUtrrX+1+NS6JaqlpNb/26l0ilVLK63/t0vYj9qSrrf8At0nSH7UmGt991T7Efth39t/9 NP1peyK9qL/bX+0Pzo9kHtRP7b/6afrR7ITqjW1v/a/Wj2QnVIzrY/v5qlSF7UhOt/7f0p+yD2pX fW/9uq9iQ6pVfWuvzVSpC9sVW1r/AGvXmqVEl1ijJrQ5+b9atUSHVKMmtf7VWqRLqmdNrPX5q0VI h1TNm1jj71NUyHUM2bVsg/PWqpmTqGVNqv8AtVapmTqmZNqnX5v1rRUzN1TLm1I5+9WigQ5mVLqB OfmrRQM3IzJb4nJzWigTKRnSXZ5y34VoomVyg9yT3qlEhyKbzZ71aRm2VnlqkiSBmB6tVCGb/egG xhOaZIpPagB1UAo6iiWrIJQO9OWiGXDc+GYiYrvVporpPlli8v7jjqOvY5rznjbP4To9lT7n39Fa PJL8oZh6gcCuWTOe2pqx6XIQxdlQH15NZORvbQmS3tYk2tMXI5wOn6UtWF0K0tpEVZISR6n/ABNF mF0Ry3LfdRV55FA5aFMyzPwCQw6dhirSJUiq1tdSHesbsp64zj9adwsK+lTEAyMqDsSe34UKYWIv sFsmS8m4nqFH601Iiwz7JECDHbs6n+LHeq5hNEMtsy84jQH1I5/AUlIlqxmyxwknMhLA/wAC9K1U iWijJCHJRIGY9upB/KquLlK0mlXnJNsqKO74U/rT5xWMmbTEGfMvIwRyQvzVopCszDubSxGcvI5P foP61opBZmFPBb87bbPuatSGlYwp4cg7IlA+laKRaVjDuLaRs8Y/CqUgMifTpiT+7Y+4FaKQGXNp E7f8sW/GqVRLfcqO1jNk0eXnMePrTVTmd1qNNLSRz+q+EtO1aIwarYW9zFjgTKCV+jdR+BrCvhqO KVpxudVDGVsM7wlY8Y1/4E2Eu+XQNUa0k6iC5zImfZhyP1r5zF8MUp3dF2Z9Hg+J6kVy1lc8b1v4 b+MtCLNPpD3FuMnzrL98uB3IHI/KvnMTkuNw+6uj6PDZzhsRopHCvujdo3UpKvDIwKkH3BwRXlOD pu01qetGaqK8JH0f8AvjBq3g99d+Hl74/wBb8LeEfFQjVdd0m+nt30DUUJ8i8/dsCYcu0c6D78Uh OCyJXPVjFao1g7jfF/xV+NvgnxLqvg74jw6Dq2sac4SaPxF4e0zUTOpGUliuzCJZInUq6OsmGBB5 qoqLXMEtDnT8W/CWoE/8JB8A/A0zH702iS6jpkrdsk/aJUB44xGB7Giz7j0AeKvgBfHN98JPFelM TljpXitLte3RZbZMD73G49uaXvdw0Ap+zZd8x6n8UdOk4+SWx0y6THswmDZPXkYqeeoLliIfDnwC nyYPi/4jtsHpeeFWkLA9MGOQgY75qlKoHLEU+Cfgk5LJ+0UUQ8hJPBGpFlHYEq5BI744qeaT1cSk o2vfU958G/Cn4b+Jfgt4w0XQ/jpFLaz+LNIuLrUpPCGoIITDZ6kI4yhbJyLiQgjjOAeoI3o0q2Mq qNOJzYvEUMDQdSvI9W8NfDH4MeE7RbbRvitHHKUCy3TeGL4y3GMZLMWzgnnaMAemea+1wWClg4q1 G773PzvMcxhj7weItHtY6Q6V8KYwS/xG1aYdAsGgup+pLOBivSdXEt8vs/xPH9hhU/4t16DG/wCF M2/3tT8cXrDOBDZ2UKH0yWkJGfYUc2JelrD5cNHrcY3iH4S2pza+AdfvyDwb/Xlth9SI4Wz9Mj60 vY4mX/Ly3yD22Gj/AMu7/MjPxH0S040b4V+F7dh0l1D7XfS+3WZUPPPMZpfVKvN79W6G8VTteFOx v+FvHHxU8W6sukeFdWsdAhSJpru+0uwtdLh022U5eeaeKNXCqOhLkk4AySKxxOGwtBPmV2/Nm2Gx OJrP3dF6GJ8R/H9140u9H8IaBqOsav4f0pmW0kvpJLi71i4biW7kUlmLPjCIM7Iwo67yTBYX6v8A vatk3+C6IeMxDxPLGl0/EzIvhR4zihF54khsfC2nkA+f4pulsXIP92A5mJ9tlbrG0uZxpamUMvqt OVXRF1NJ+GOigM13rfjPUVPMdjF/ZFhkcnM0oaVwOnyxgH1FOP1qs7JcqNVRwlDWUubyLTeNPE8c Mtl4bt7TwppUgKtbeF4zbyyKcgiS8Ym4cHPIDoh/u10Ryyk3zVJczCWPcVajHlRyUOkIudtmwySz EDliepJ7k+pr0VGnFWscLq1JvXY0Y9Li43QyCn7Tl6ktcuskaEOmW5/hcD6VDqW3F7uyL8ek2px+ 8I+oqXVmvgQKKjqy9Ho0J6TD8QRWftQ5S2uh/wByZD7Zqfak8pINEn/gwfowP9aTrAoiHSbtRnym OPQGkqyK5SBrSdOGjx7Hiq5kTYhZJl/gYe4zVXQEJmlXj5vx/wDr1IiB5wfvqhz/ALNAFZ3hbJKY /wB1v8aAKrrEejEe5GR+lA7FZ48cq4P0OD+tO47FR1dc7gce44pp3CxTfBz8gPuOKsZWcL05Ht1o ArMvo2frQBAwPegCFutAEVWBHQAmRQAAg9KgaF3+9BQ7d61VgJA4z6fWpsBMspHNJoLllJ6mxSdy ytxg9amxdy2l1jqKnlK5i7HeY6NUuJSmXor7HepcTRTL0V//ALVZuA1Mvx6if71Q4FqZej1Pp81S 6ZaqF6PVOnzVDplqoXY9VP8AeqPZlqoXY9Wz/HUukWqpcTVzj79Q6QKqWk1g/wB/9al0jRVSwusE cb8UvYlKqTjWDx89S6Q/aky6wf79L2I/bEi6yc/fpeyD2w/+2T/fo9iP2wn9st/fFHsQ9sJ/bDf8 9KPYh7YG1k/36PYj9qRtrJ/v0eyJ9sQtrB/v/rVeyD2xA+sHk76apEe2K7awf79WqQnVKx1c4+/T 9kT7UqPq5/v1XsyXUKb6qc/eqlTIdQoyap/tVapk87KMmp9fmq1AhzZRk1In+KrUCHMz5NQ5OGrT kJcyk99nPNPlRm5lGS9561fKS5FJ7vOe9aKJDkVHucg807Ccio8/vVJWIuVmlzVWJbIy+OTTEM3e lAhhbn1oJFpgNz6CqAdQBJQA8DFAmhtxdwWFtcX9yAYbdC5QnHmHIATqDySAcHIBz2rGtOyKjG54 ZMTczTXNxI7zysXd8n5mJyT+deboa8y7n7KXGozZQrIqjsEHIx74rHlt8RzvVh58kpVwS5PUs2Oa fKnsbLVCJDKZSiliD2jXJ/KldLcduU0TpMmz/SGSPHIMjDP/AHyMml7T+ULcwRx2SAJvklYf3F2j Ppk1FxpEv3iWtLNAw/uguR6knpRzWKsI6ysv+kXKpkfMm7n8hzReS1iJ3ZnyyWkBPEs4PfhRn9TV x5p76CSRGWll2LbWyI55U4JJz9cn9KTcY/EwcL7DTZ3z7vtcywZ4xKwUH8Ov6Ue0i/hVxKKjtoVH tNPg5aaSYjrGq7R+DNz+lVeT6WE01vqUHvLJFJgs0LD+KTLkY9jgY/CrUZPqQ2ilLqN84ZQWCHoY l2jHuAAKrkit2FnbYgGlapdtmKGQqcE784575p+1hHqKMJt6Ihk8MXOQ13LFAMZzI4BFNYhLZD9n 8ilLoOnxDE+oq564hQsT+YxSVebfuoaiu5QOkaa5CwW13Oc/3SB+XNX7WXV2J5fMpzaK3LLoqoo5 3TOB/UU1Uf8AMHI+xiz6e4yDJZJjjauGP6CtFUQWMebTXbOJ5D7xRHH54rRTQW8zHn0ZjyVnPu5C /pVqoOxiT6VCudyqD/ty5/lWqkwsZUthagn/AFJ9gC1WpNCM2a0tx0/8dT/GrUgM+S3Qfd3H8AKc nqNNs5bWfCPh3XUKatolvckjAeRRuH0YAEfga5sRgcLiV+8idlDMMVh3+7keVav8CPCl3vbTpbyw dugWQTIPwYZ/WvIrcMYauvc909mhxPiaL99cxu6l4Kvte+Hi+CPGDxa1qOg25Twp4jjzDe6am4E2 NwGJWWzO5ioJ3xP9zKsRXi1uEq8H+7nc9qhxVSqL95Gx8zX3wn+IFhvJ0CSdV72siy5HqADmuCpk WLp7wPRp5/g6mikcdeaFr2nnF9ot9Bjr5kDD9cV51TCV6e8Tvhi6VVXjNGU7NFzIjL/vgr/PFYOE 1uvwN1OD6oYJVP8AEPzpcj6opcj6h5i/3h+dFpOdmrBJxatFn0L4X8XX/gv4CaxqWn3kcc1741s4 ykwBRlhsLkkEEjqbhcY5GDzW2GxNXBVeaJz47AUsfR9nI0vD3x30nUJY7TV7FoJ2HzTWb+cg5wSw HzADPvX1eF4ghVajVjY+JxnCdSEXOi7n0Lpel63rsMVxomh6nqEMoBR7KxmmDAgEEYU9jmvdjjKM ldSPmHgqylyOJ19p8KviZfDdD4L1GOMDJe7VLYKPUmRlxUSx1BfFL8DSGWYiXwosH4ZX1m6r4g8Y +ENHJPMd1rMU0o4znyot7kfQVCxkZfwlc2/s2cf4pInhv4a2JH9o+OdY1eQDLQ+HdDkRSfTzbtoQ B/tAH2Bo9piZyuqVvmWsLh4x1qfgd1c/Efw3a+FbPwb4W+Fdpb6KjCa6k1zVri4fVJxnbLcx2/kh yufkjLvGvYE5Jwjk+JlV9rVqb+Wy7f5/8MdbxuGjS9lTp6nON488bi3kstN1iPQ9OlG17PwxaQ6T HIOuGMCq7/VnJPeu+OVUIaz1OT67NxaRyq2imVriSMS3DHJnmJd2PXJYkkn6mu2nShD+GrHG51Zv VmjHCMDMKEfjVsk0YYYx1gGPYmpYGnFHDgZicD1DVDBGnCltx80o9uD/AIVmyjUhjt2+7cuPZ0H+ NZtvsHKjQjtYj0nt8/7aYP48UrvsFkW0sN/Aht5PdW2/1FZc1uo+XyJDpygkGyx7IxP+NL2nmLk8 iFrS2XrFOhx1OCP1xTUn3J5ERtAijK3TA+hUj9Rmhti+ZEyT7QI7lWyO7f40Xt8RS1+EpzRXAPzw q568IDn8v8aacXsElLqZkoQ5326r7glT+RJFPbZka9UZssVqTnY4PTOA38sValN7MGoPdGdNawtn bIgHbOV/nVc0uoOMehQks5QMx7iD3HI/SqU11FyvoZ8kbqTk5b0PFUpJis0VGZ1OdpH0p2THcrtL nOQD9R/hRyhe5Xbyz3I/UUwK7KW6ciquBXbj29qLgQH35oAiOPofSgCMjFWBFQAUAgz61JQuentS JHBufSgB+71oKuPDe2PwoGlckDke/wBKVgJRMRRYq5YSf3qLAmWFuO2aVi1IspdEd6TQ7llbv3qe UpSLC3mP46TiV7QtJe+rfjUcg+csrf8A+1U8pfMWE1DH8VS4BzlldRPZqXIWpk66mfWk4D5yYang /epcg/aky6of71LkD2pINU/2uaXIyvaEg1QjvRyD9qL/AGt71Psxe0D+1fc0ezD2gf2p70+QPaCH VCe9HIHtBh1T3o5A50RnVPVqfsw50RNqef4qfILnIG1I/wB6nyMXOiBtSP8AfquQnnK7aj/tVSgS 5ldtQz360/Zi5ys99nnNWqZLmVXvT/ep8ouYrPd5PWqUSHIrPdH1pqJNyu1wW71XKTcrtPVWFcrt PTFzERkY07CuQlvbP4UxDC/rQShNxoBhk0xDciqAWgBy96AHU27i2JKQXH5CgsxAUDJJ6AD3qXb4 mPRux5n4o1yPUpls7KVzpsOG3HgTSAEFgvoAxAzzjJ4zgefWquT5kbcrjojtdK/Zz+LOvaXpuuaZ pxbTdRt47u3ba3MUih1PT0IrieKodz01l9Rr4D9PV01UUrcyxw4BIBIL/kOfzpe0vseQok0EtjEf KjtpLhyfvTHaPptAP6mpcXLcqnuWzc3lyBBEQjE4CQKFyPTjHWla3xGrVxY7cqCt5JHAyjIEnzOe f7o5z9SKV7fCNaDZ5LdcskRaZAMGY5PHoq8AfXNOOomrFcXlxeBYk5wOgwq49ABjNU42JuyaHQr2 UGZN0UQB3M52qOOTk9eOwzWbrp7lKnJb6Ew/sm2XBY3Ep6r/AKtD9Dncf0qGqtT4dEaXhHfUy5dT nXzI7KIJERyijbwBkknqfzrWFKP2nczlJr4dEZ6wX2pYESM5c4x349zyfzNW5Rp/CSve+FamiPDF zBh9TuFij2ggSHa/4DluPpUfWlL4UV7OS3IZIfDlu21N91cbuSo25x2xyT+lUpVZbOxPurzLEH9r SiR7DRVjgU5aZk6Dtyc8fWobi/iYR5yG6t5AGa+8QorfeKWxyDnoDjAHp1qoyt8EbitfeVjLEFjI wMGl3N7gfMzZ2k569uM+9XzNdbC5bdCWSzu4I3XbY2YQggMAzc+3B/MVMZRvrqUo/Ixry6gHmG51 C4nCgAG3AVRnjr1x+FaxUuisQ35nOXN1ZEgwWYklUjBncvn2xmt4xm9yL+RjT6hOPmSKGFSf+WSD jj86tQj2Dmfc525url85u5CTnjOOn0xWypx7BzPuYFxg5MmWPTOcn8c1okhWZky7Oecex/8Ar1ad gszNl27sAA47/wCelPnLSM+QKeDx/niq50VylJ2U9xR7VLYap33Kb+XzjB9xR7Xm3Q400tiq+0f5 6Zo9q2VySRWbYvf8KftUg9nJ9SFivJyPrR7a+5TpvuRM6sCrHK9weR+Rpc8H0Q1B92Z8tlplxuWf T7WRSOQ8KN/MVlOnTlvFG0alSO02YsvhTwlMxMvh3TmJ6k26/wBBXM8DhpbxN1i8VHaZX/4QrwTg n/hF9Nz/ANcB1qXl+Flqqdivr2KjrKZ3/hDxDqfgCxvdM8F3SaRpt3MJ57W3t4WjllC4DsrqwyBx kdqiWWYKfxQNIZpjY6xkdRJ8VPHs6hJPErYBBylpbIc/VYwfwzULKcFHan+I/wC1sdL7ZkTeNfFl ySZfFerKWJJ8i8khGScnhCoraGBwtP4I2+ZjPGYie8/wMK7nbU8f2rPJekH/AJfXM5yMY5Yn0rqU acehzN1JfaFh8mIBIlVEHG1AFHtwKtTguhDhLqW0ZM+3Wn7Xm0SsJU7fE7llWX15/wA5pe06RB0m tVqW0dCOMe1CqWJ9kkWkdOh20SrPoHsralyN0GORz6D1qXUFyF6N1+vGfSpdQXIX42XggD/gX60c 4lAvRvGejAH0H9PrS5gcS4hQgDaTjuaLojlZcQDAB2gdM+n8vwqbomxYQZHyOzDrgeg/pSYrFhJp 05SRlI5Jb+mKmwyX+07yEFXcMDwR6/z/AFqFTQXfcT+1Ldjtls1ByMHGP5YJodNdy1MRm0yfI3sh zwFIYfkcH9aj95HzB+zfkVGsWJxZ3CkjtnafyPNJ1v5lYSpv7LuZNw17CMTLuTsG/i/A5zWkeSWz FLnW6Mt7uBvkktwvbOCmPy4NXyuOzJUu6KkkVu4JExUns4yPwIp80uo0k9jPlglQ/LnH94H/AApq Ueo3GXQoSTyLnf8AN3+YZqlF9Cecps0T9U2+pX/CqtYLplOWBcfKwPfng01IbiZ0kbL04HoatakF ZiR1FVYCMns3NFgIWAPI4oAgYfjQBFVgR0AFABQA08GgA3e1ADge4oElYcGIqCrjgxqrBccH9KLB ceHzUlDxIe5pWAlExHWiw7kgnPejlDmJRcGpsVzEq3B45osUpkwuTxzUpBzEq3Rx1ocR3JRdk1PK NMlW79zSsO5ILw/3jQ4j5x4vD2ap5Q5yQXp/vfnRylKYv21v71HKPnH/AG4+tHKL2gn273/WjlD2 gv24+tHKHtBn21v71HKHtBDen+9+VHKLmGG9PQtT5Q5hhvD3Y0couYjN36Emq5SeYiN36GlYOYjN 0R3quUm5Ebk9zTcA5iFrn3oUQvchNxzVWI5iJrg0+UOYiMxPSnYVxhkPQmkxXIy4z6/SqAYXzVWE xhc5pWFcaWJpCGk9zVgOByOKADOeMUAIOooAfQA5e9ADx1FAmOeSG3ha5upkgtEYBp5chVJBIHAJ JIU4UAk44BNZTnYuMTzjXvEx1OJbKyjaGyGS7t9+cnsQOAo7Acnkk9AOSdbnky5KKs0SeAfBupfE Txr4V8DaPGzahrl9FZqyDJjVj87/AEVAzH6V5+JrrC0JVJHXgMPLF4mMEf1E6F4F8M6DoejaHZ6X braadaQ2kS7OiRoEH6KK/Kp46q5NqR+vQwNFRSaPzag8+6VZFwGJIKp95vXgdAfev1iXun4kpc2p rmwhiX7XeXBDnBEMZ3OfckZArPmuVa3vCtqq+WsNriBhkEKQCR7sT+dT7M1VT7zOlLyDdEjeZkly vP06D9c1pGyJld+pq6fplxqEgV49pXkg/LyOpYnnJ9KyqVOT4S6bc9zoJo7DS8EFHvUXq3yqmBxh RySfpn1rBN1NzaSUNjmbvWZ7o7ZncSDAUsMBR/ungYreNKNN6IxVZv4zMjtJbyZY7UM12W6oS2fp gcVpOSpq7BQcn7h2lh4atrFBcaxJjZyQuM59DnI4+lefVxjk+Wgrs6IUPZ61dinqHiCGEvBo6iCI ZDTw/MSPUnrz6AirpYdz96vK77CnUS/hqyMbTtM1LWsyXbMLbPzTKeCO444Pvk5ratWp4ZeZlCnU qO34m1enQfDsca2lsk2oBeHOOM92XPH4n8K56XtcS7uWjNKkadBWjuctJfa5rV2ln5rvGR8gi+VU Hc7SMcdOBXbCFKhHmloc8uab7m9/Ymg6Lbreaj/pF+CGVVODuPbB5IHtXJDEVsVPloqyNXTp0Y88 3dnM3/iTVJBttwkFoc5S3UKcdACeh9cc12Qw3LuYuvJ7nKsPObLkiTO4M5KkYHYnjn2FdKtEh2lu U2iZcPu3ruGVb5RyM/eBwP51d7k3My4AVQZImT5h85GMZGeSORmriFznZzjIWTccgAHkHIwR6/gK 1ROhz11K4Q+YoKKccEEjt09farGrHN3F4ibhuZSO3fnqMGk5GkY3MWa8fB+YH2HvyBkf0qOexsqZ lTXwXquSDg46ewqXUNVTM2W+x1cg/wC1wT71PtrGipFKS/LZAII649u2QKTqley8yjJf4J9emR70 vasr2XmVX1DHPzZzwOtHtBqkym+ojkbu1HtC1SKj6meoYc5xT9qP2JVfU8e447/pR7UaokJ1Ujvy ePxqHXK9iVzrA7v+vak65Sojf7ZGPv8AfNH1gX1e43+2hj7x9fzqXXK9hYcNaGcbz1o+sB7DyHLr AOPm9af1gPYeROur85yeoP50e3uHsCyuqEkDJ54/HtR7UPYFtNTJAbJ+meo71XtSXR8y5HqRIx+u emeho9qR7F9y2mpHnt2I9DR7Yn2ReTUsn7yg5x7f/qNHtGHsi1HqXGN5IwMD3FHtCXA0I785wSxJ JHpnP+elHtCXTL8V6xwVGeMjPXjrx/SmqhLp2NSG9JxhwD6juPXPtVJ3M3A1YbvdtBYsc8Y9e/Tr mrUjHksa0UxAVkGVI4zjJHfirM5aGijkgHcFJ6Acg+4Jx+IpXZLZOWQ8MdxHyjHIH0xgEZqXcka2 VDeWoCg4Ibg5A7jt7U22gdinOB83mHB4G0cAcenXNUriuZ0oxlo1yMgZxxn055BoTTDQhF3cxZJb coweeSPbPUUnGLC5qwX0c6MTlj7/ADHPvXJVo+zd0bwqcxQu7dZh0UFh9eD6f/WqoVWkE6akcjcL 9ll2hjjuDz9eK7YtPc5mgiunfjvnHPP/AOqpnTiy4ysNm2MMsOeoY9xWcZOJdlIx50/iQ4I710Rb kQ1ylESdc9e5q5RJTGs2ScfnWdmh3RVkUc8VomwKLjHTvVJNktERJBp28wsiNv1ot5hZETdasVyK gLhQCYnf8KBiN2oFcbQFwoC4u40BcdkVNguLVJDHAkmk0K4bzUtDQ8PmixVxwbn0osFx240tAuOD n1/GjQLjlkb1pWAeJWFFirjhMfWiwXHic9c0WHccJz61HKw5h3n+5o5WVzjvPaizFzC+efWizDmE 88+tOwuYd9oHrS5A5g+0D1o1DmG+efWjUfMJ59PlDmAzn1o5Q5hvnn1oSFzEfnn1qrBzCGcn+KlY VxhmYdadguNMjAdaOULjS59apKwrjC34UWJuNLe2PwosFxpf3osO6GlufWiwXQhJBoJsxMmqCzG5 FOwWY3caTCzHYFAfMWgegU9RXY8DFLUdmOHUUm0luCTEuprXTWaPU7uK0dGAaOckSKD0PlgFyPUh TWLxEVpuUqdzlrzxjawhk02za4fAHnXWUQHkHCKdxHQgkpjuDWE67kOyRxV/qV9qcyz39y8zqCFB wqxgnJCqAAoJ5IAHrXPzNhco07Weu4nd6s/WP/gm18DpLrUNX+Omv2pFpbq+naGsin9454nnGRyB jywR3318VxRmO2Fg/U+/4VytL/aZr0P2NwPSviT74/LSSaHSJPLiVjz98jazD8ema/YvjP57T5Xc 57VvEel6XaXOr6zqVvZ6dHkyS3koUDPuxPJ9O/ak42OmHvanzl4i/ah8E6ZdSL4d0y+1WRGO2VFF vASOPlaTLnP+5irUblWS9TlYv2vZ0m82b4dRSRgkgLquwnnjJ8g9qTpMtSXzOhb9tuUIUh+F0cfH BXXSefU5tsk1nHDv7QnKPQwJP2wrmZy0vw9DLnKp/bRAB9eIOa09klsF+5F/w1yGAB+G68EHK60Q cfU25pqnLdifLLc29D/bOfSDOx+GEc7uNql9aI8sZz8oNsRk+uK56+FeIVrmtGtGlsXNY/bUu9Yg W1/4VuIbc/eUa2WLY6DJtxgVOGwP1frqXVxHtNFscun7VE6sGTwDHxzhtV3D06eRXa4JdNTlWnod tp37aU9jZwWi/DJC0a7S41wqHHfI+zE89+a86plyrT5pS1OmFdqNlscnc/tSPdXM11/wgOyWRicr rB+XPb/j36Y4rvhS9nGy6HNpJ6mtoX7Wk+kTvMfh3DLvQI23VyhIByMnyCD+IrDE4dYlcl7F0arw 71Wguu/tWNr1zHdSfD0RsgK86yXLZOQSfs4HHTgUYbCfVlyKVx1qjqe8omOf2k59zBPBKbDjAk1Q sRjoAwhBH4V1WaMLsc37RksgRW8EoQARzqZIBPXA8nj8c00GjIf+GgZPkeDwakcuTz/aZYYPGMGG hAQN8d55MBvCMOAwPF/0wMcDycZ9yDTcrAUJvjA84bb4XjUnoftxJH4+WOatVSHTMyb4kz3DMRow UHgbrwuR+JjH6VXtRqBSbxjLKGDaSgBHQXB5Pqfk5+lRKtc2iU5deebB/s9FABAxMefrhRms/aG6 lYrm+lcDbAAcY5lJGD142ip5xqdiPM8nVUA6Y3Hp3A44pNmiqjWtZJOu1V64yf54qeYv267DRpUj f8tFH0J7+lLnKVddhP7AmYD/AEoDjB4NNspVxp8MTOf+P1AD1Gw847dahuw/bif8IZK/W/TP/XM/ 40FLEDD4CkPy/wBpqOP+eR6+vWgr6whp+HEr8jWFGeP9Sf8A4qoaK+t/3Rn/AAqyWTj+3QB/1wJ4 /wC+qmzGsZ/dAfCSZs/8VAB7/Zz/APF02h/Xf7pIvwflYf8AIxAf9ux/+LqeVh9d/uky/BybP/Ix j1/49f8A7OjlD67/AHSxH8Gpcr/xUg4/6dT/APF1XIH13+6Xo/g7KP8AmYx6f8ep/wDi6LCeK/ul 1fhBJgD/AISAZ9fsx6/991auS8X/AHS3H8InTI/t9SCc/wDHsf8A4ulcPrC7FyP4RsAD/bwOO32c 9P8Avui4fWF2LafCZhz/AG4vTB/0Y/8AxdVzWI9uW4/hM64/4ny5B6/Zj+X36PaB7ctr8KZB011e Rgj7MeR/33R7Qz9sXU+Fc2MHW1I4/wCWGOnr8xo9oHti7F8L51Of7YRuc/NEec+vzUe0Jc7mhF8N Jk/5icR9QYiBj8+vvVqsQ3c0ovh/dgEHU4TnuY2zx0PXGferVYzcWzRj8CXif8xRAeOQhHI/Hmq+ sGUqVzQj8ETAlhdQg4yBtJGffPUUfWhexLaeDL4Y23cG0cbWDEe47ZHsaf1lB7EVvAl84AGoRZ+h A57DA6UniUHsQPw7v2XaLy15ydzAk8+pxzj8KFikT7Egl+GWsSsxTUbNVPI3FyfxO3mmsTAcqNiu 3wl1yTrqFi3AALNINv4Bear61AlUS/b/AAl1mGILHe2JkJOSXkX6YIUn86wqV+dlRp2El+EviVgS t/p2e37yQZ+pCVCqqJbgzAn+C3iWR2d9S0zJOR88hx7fcrqjjIGXsiunwV19GBfVNPGBjgyH+ajF EsVEPYA3wb1vPzarYkjp/rD/AErN4hM0VOxTm+DOtspA1axGe+H/AMKuOLUROlzGY3wR1rvrVnx6 K/8AhV/XkxewFPwX1VcZ1m047hHpPFoPYED/AAZ1HvrduB7RN/jR9csP2JWk+C9+cH+3Lfjv5Lf4 1SxqF7Art8F77nOvQD6QH/Gj675B9WZE3waux/zHoff9wf8A4qj675B9WZC3wduh116H/wAB2/8A iqPr7/lH9XIj8H5QOdfTPoLY/wDxdH1/+6H1cjPwjkB/5Dy/+Ax/+Lo+v/3QWHIm+E7ryNdU5/6d j/8AF0fX/wC6P6sQt8K3H/McX/wHP/xVH1/+6H1Yib4XOv8AzG1P/buf/iqPr/8AdD6sRH4ZuP8A mMqf+2B/+Lo+v/3RfVyM/DeQf8xhf+/B/wDiqPr/APdD6uRH4dyL01Zf+/J/+Ko+vf3Q+rkR8ASD /mKL/wB+T/8AFVX1/wDulfVyP/hBZR/zE1/79H/Gh47+6L6sRt4Kdc/8TFTj/pkf8aj6/wD3RfVy M+DpBn/T1/79n/Gr+v8A90Pq5EfCco/5flP/AAA/40fX/wC6HsCI+GJV/wCXxT/wA/40vr390fsC P/hHZR/y9Lx/sn/Gj67/AHQ9gRtoUq9bhT/wE0fXf7oewZGdHnH/AC3X8jR9d/uidAYdLmXrKp/O j65/dF7AiaymX+ND+f8AhR9c/uh7EjNrMO6H8T/hT+toXsyJopl7J/30f8KPraE4ETecv8KH/gR/ wpLFoOQjaWZf+WaH/gZ/wqlikHIQtdTL/wAsUP8AwM//ABNJYgnlITfzj/lgv/fw/wDxNWsQTyjH 1K4Uf8eyH/tof/iaX1kdiM6vODn7Kn/f0/8AxNP6yhEZ1ecf8uqf9/j/APE0fWAGHWpxn/Q0/wC/ x/8AiaPrAETa/OP+XFP+/wAf/iaSxBKQw+IJxn/QY/8Av8f/AImn9YLsRnxHOM/6BH/3/P8A8TR9 YCxGfEs4/wCYen/f8/8AxFH1gLDD4nn5/wCJcn/f8/8AxFL6yFiJvFU/GdOX/v8An/4iq+sD5SM+ LZR104f+BB/+JpfWBWIm8Xyjppa/9/z/APE0fWB8q7jf+EwuP+gYn/gQf/iKPrAckP5hP+Ewn/6B af8AgQf/AIij6wHJD+YX/hMJv+gYn/gQf/iKr24uSP8AMN/4S+b/AKBq/wDgQf8A4ij6wHJH+YP+ Evl/6Baf+BB/+IpfWQ5I/wAwo8Xy/wDQLT/v+f8A4mq+sByR/mD/AITCb/oGJ/4EH/4ip+shyU+5 bt/GUS7vteiySZxt8q9EeOuc5jbPb0pPEByQ7jbjxmrEGz0jy8Y4uLnzQfXOEQ/rUe2mOyRVn8Z6 rJsMFrYWrrj5oYWfd9VkZ1OfpUutMd0ZFzr+t3fnCbVLgRy/fit28mN/qiAKfyrN37i5kY4VV4UA D0AxTvIltsWhBcKd7Bue8/s8fAjxF8f/AB/Y+FtLSWDQLdlm1jVlX5bK3zyAehkfBCD156A15GaZ lHAU3KXxdD2soyupj6q7I/pP8KeFdD8E+G9F8KeG7JLTQ9Kt0tra3QYCIgAGT3PGST1PNfl1etKv NzqPVn63hsPDDU1TjsjqKzOg/GP4ieNtI8BaHc65rKs5+5bW8fEl3KQSFG4nHQknHABOO1fsyR/P sKXNqfm7408d+I/HmpHUNevCYlJMFlESsNsD2VSTzjqTkn1xgVaRvo1Y42qJCgAoAKACgCWP+tAF le9QUWE7UAWF70ASr2oAnTtQBP8AwmgZKvWkhFhe9MCVe1AE69KALC9KALKdFoGi0n3agqJZX7oo LLkdSCLadKCiynagCyv9aguJaT7tBZZXvQCLSdVoGiwOv40DLSdqgSLcf9aBlhetUwLK9KkC0vX8 KaAuJ0WmwLK/0qQLC9qALKdqALQ6fhQBYTtQBbXpQBaXtSQMtp2piRbXt9BQMsp2oJLcfagotDqK CZFtKlAXE6LQwLMXWgllxe1A0WV6UElyOgC8neoAsHoaaApP1poCk/emBUfrQESq/SgsqSfxfWgC pJ3oApP3poCu/wB2mCKr0FMqv3oEinJQMqydD9KAKrdqAKbdKAK7daBIrSf1oGVnoBlZulAIqt3o AqN0oGis39KBFR/vUAQHoaBIqP1agZVbpQDK5/iqwRWk/rQBUbpQSQP0agllN+tNCKzdKogrv96g TKcn3jQTIrP/AA/WqFIqSU0Syq/eqJIW60AVX70AQt2oEyF+9A0V6AIm70AV270AQnt9KAIW70DR Xfo1A2QP3pollVutUSNoEFAwoAKACgAoAKACgAoAKACpvdg9NmGMVTulogunuFLVbbA7XPon4Bfs 0fET9oDW4rfw/ZPY+EoZQt94juoyILdQeRHnHmSY6IPxIGa8nMc4o4Be87vse5leS1sxndL3e5/Q V8Hfg34N+CHg6y8G+DLEJbx4kub2QAz385HzSysOpPYdAOBX5tjcdWzCs6k2fqWAy+ll1Lkpo9a/ nXG1eVzuWiH0xn8ufxu8Zz+LPGl5axzk6RozNZW0Y4BYHEr4yQSXGMjqESv2mx+Ar3dDxuqBxcdQ oGFABQAUAFAEsf8AWgCyveoKLCdqALC96AJV7UATp2oAn/hNAEq9aEBYXvQBKvagCdelAFhelAFl Oi0DRaT7tSVEsr90UFFyOoGi2nSgosp2oAsr/WoLiWk+7QWWV70Ai0nVaBosDr+NAy0napEi3H/W gZYXrTYFlelIC0vX8KEBcTotNgWV/pUgWF7UAWU7UAWh0/CgCwnagC2vSgC0vakgZbTtTEi2vb6C gZZTtQSW4+1BRaHUUEyLaUkBcTotJgWYutBLLi9qBosr0oJLkdAF5O9QBYPQ00BSfrTQFJ+9MCo/ WgIlV+lBZUk/i+tAFSTvQBSfvTQFd/u0wRVegplV+9AkU5KBlWTofpQBVbtQBTbpQBXbrQJFaT+t Ays9AMrN0oBFVu9AFRulA0Vm/pQIqP8AeoAgPQ0CRUfq1MZVbpQDK5/iqgRWk/rQBUbpQSQP0agl lN+tNCKzdKogrv8AeoEynJ940EyKz/w/WqFIqSU0Syq/eqJIW60AVX70AQt2oEyF+9A0V6AIm70A V270AQnt9KAIW70DRXfo1A2QP3pollVutUSNoAKACgAoAKACgAoAKACgAoCwoO51jX5pGOAo5JJ7 ADk1EpRWsnYuFOUtFE9w+HX7N/xr+Kc8SeEfAOovaOcHUL+M2tunfmSQAcjpjOa87E5vhcLpKZ6m DyXFYp+7E/TH4Mf8E2fDOhva638ZtbOu3yEONC0wtDaKRg4kkOHk7ggbR6E18pj+JqtVOGH0Xc+y y3hWnRSniNfI/THRdD0fw3pdnougabbafpNqgjhs7OJYo4lHYKoAH9a+Wq1pVZc1R3Z9bSoQpQUa SsjbHFZNtvQ2SS0Dg4NNjHUwP5EWZmYszEsTkknJJPUkmv2s/AhtABQAUAFABQB9r/sU/APwH8ff FfjXRfHg1E2ml6fFc2/9n3X2c7mkKHcdpyMdK+dz7MK2AhB0up9Pw9ltLHzmqp+jg/4Jv/s5j7qe KP8AwbN/8RXyy4lxr0bR9e+FcEmnYeP+CcH7Oo/g8Uf+Dc//ABNL/WXG/wAyD/VXA/yjx/wTj/Z2 H8Hif/wbn/4mj/WXG/zIP9VcD/KL/wAO5v2dh/D4n/8ABs3/AMTR/rLjf5kP/VXA9hw/4J0fs8Dt 4m/8Gx/+Jo/1lxv8yD/VXA9hw/4J1/s8Donib/wbN/8AE0f6y43+ZEf6q4H+UX/h3b+z3/d8Tf8A g2b/AOJo/wBZcb/Mg/1VwP8AKOH/AATu/Z8H8Pib/wAGzf8AxNP/AFlx3dfcH+qmB/lHj/gnn+z4 P4PEv/g2b/4mj/WXHd/wD/VTAdhw/wCCev7Pw/h8S/8Ag2b/AOJo/wBZcd3/AAD/AFUwPYcP+Ce/ 7P46DxL/AODZv/iaP9Zcd3/AP9VMD/KPH/BPr4ADt4k/8Grf/E0/9ZMd3Qf6qYH+UeP+CfvwCHQe JP8Awat/8TR/rJju6D/VTA/ykg/YC+Ag6DxJ/wCDVv8A4mp/1kx3f8Cv9VcD2HD9gf4DDt4j/wDB o3/xNP8A1kx3cP8AVXBdiRf2CvgQO3iP/wAGjf8AxNT/AKx43uP/AFVwPYlH7BvwKXoPEX/gzb/4 ml/rHje6+7/gj/1WwX8o4fsIfA0dE8Q/+DNv/iaP9Y8b3F/qvg+w8fsKfA8chfEH/gzb/wCJo/1j xvcP9V8H2JR+wx8EB0HiD/wZt/8AE0f6x43uV/qxg+w//hhv4I+mv/8Agyb/AOJo/wBY8b3D/VjB 9h4/Yg+Ci9B4g/8ABk3/AMTR/rHje4/9WMH2HD9iL4Kg5C6//wCDJv8A4mj/AFjxvcP9WcH2Hj9i b4Ljtr3/AIMW/wDiaP8AWPG9w/1YwfYlH7FfwZHQa9/4MW/wo/1ixvf8A/1ZwfYcP2L/AINDtrv4 6if8KP8AWLG919wf6sYPsSD9jL4Ojouu/wDgwP8AhR/rFje6+4P9WMH2Hj9jX4PDtrn/AIMD/hR/ rFje6D/VnB9h4/Y5+EA6DXP/AAYN/hT/ANYsb3D/AFawnYeP2PfhEOg1v/wPb/4ml/rFjO4f6tYT sPH7IHwkHbWv/A8/4Uf6xYzuH+rOE7Eg/ZE+Ew6f2z/4HH/4ml/rFjO4f6tYTsPH7JHwoHT+2f8A wOP+FH+sWM7h/q1hOw8fsl/CkdBrH/gcf8KP9Ysb3/D/AIIf6tYPsPH7J3wrH/QY/wDA4/4Uf6xY zuH+rWE7Dx+yn8LR21f/AMDT/hR/rFjO4f6s4PsSD9lj4YDoNX/8DT/hT/1ixncP9WcH2JB+y78M h0Gr/wDgaf8ACj/WLGdw/wBWMH2Hj9mD4aDp/a3/AIGH/Cj/AFixncP9WMH2JB+zJ8Nh/wBBX/wM P+FH+sWM7i/1YwfYk/4Zo+G47ap/4GH/AAo/1ixncP8AVjB9hw/Zr+HI6f2r/wCBh/wo/wBYcZ3D /VjB9iYfs4fDwdP7T/8AAs/4Uf6w4zuH+rGD7Dh+zp8PR0/tL/wLP+FL/WHGdw/1YwfYlH7PPgAd P7S/8Cj/AIUf6w4zuH+rGD7Dx+z54CHT+0v/AAKP+FH+sGM7i/1XwPYePgF4DHT+0f8AwKP+FH+s GM7h/qvgexIPgR4GXodQ/wDAk/4Uf6wYzuH+q+B7Dz8CvA56nUP/AAJP+FH+sGM7h/qvgexCfgP4 G7/2h/4En/Cl/rDjO4f6sYLsMPwA8CHqNR/8Cj/hR/rDjO4f6sYL+Uaf2e/ALdf7R/8AAo/4U/8A WHGdx/6sYPsRn9nf4ft1/tL/AMCz/hR/rDjO4f6sYPsRn9nP4eHr/aXP/T2f8Kf+sOM7oP8AVjB9 hh/Zv+HR6/2n/wCBZ/wo/wBYcZ3Qf6sYPsRH9mr4cHqNU/8AAw/4Uf6xYzuH+rGD7DT+zN8Nz/0F P/Axv8KP9YsZ3D/VjB9iJv2Yvhqeo1b/AMDD/hR/rFjO4/8AVjB9hh/Zg+GZ4I1b/wADT/hR/rFj O4f6sYPsRn9lv4Ynqur/APgaf8KP9YsZ3D/VjB9iM/srfC9uo1f/AMDT/hS/1ixvf8P+CH+rOD7D T+yl8LT1Gr/+Bp/wo/1ixncP9WsJ2Iz+yb8Kz1/tj/wOP+FH+sWN7/h/wQ/1awfYYf2SvhQeo1j/ AMDj/hR/rFjO4f6tYTsMP7I/wnbr/bP/AIHH/Cj/AFixvf8AD/gh/qzg+ww/sh/CU9RrX/gcf8Kf +sWM7h/qzg+ww/sgfCM9RrX/AIHn/Cl/rFjO4f6s4PsRn9jz4RHqut/+B5/wp/6xYzuH+rGD7DD+ xx8Hz1Guf+DBv8KP9YsZ3D/VjB9iM/safB49V13/AMGB/wAKP9YsZ3D/AFYwfYYf2Mfg43Vdd/8A Bgf/AImj/WLGdw/1YwfYb/wxZ8G89Nd/8GLf4Uf6xYzuL/VjB9hh/Yp+DB6jXv8AwYt/hR/rHje4 f6sYPsRn9iT4LnqNe/8ABk3/AMTR/rHje4/9WcJ2I/8AhiL4Knnbr3/gyb/4mj/WPG9w/wBWcJ2G n9h74JngjxB/4Mm/+Jo/1jxvcX+rGD7DD+w18ED28Qf+DNv/AImj/WPG9w/1YwfYjP7DHwQPbxB/ 4M2/+Jo/1jxvcX+q+D7EZ/YU+BrdV8Qf+DNv/iaP9Y8b3F/qvg+ww/sH/Aw/w+Iv/Bo3/wATT/1j xvcP9V8F2GH9gz4EnqPEX/g1b/4ml/rHje6+7/gh/qvgv5SI/sEfAduo8R/+DRv/AImq/wBY8d3Q v9VsD/KMP7A3wFPVfEf/AING/wDiaP8AWPHdw/1WwP8AKMP7APwDbqviT/wat/8AE0/9ZMd3F/qr gexGf+CfnwBPVfEn/g1b/wCJo/1kx3cP9VMD2EP/AAT5/Z/PVfEn/g1b/wCJp/6yY7uhf6qYH+UY f+Ce37P57eJv/Bs3/wATS/1kx3dB/qpgf5Rp/wCCen7Px6r4l/8ABs3/AMTT/wBZcd3X3B/qpgf5 Rp/4J5fs+eniX/wbN/8AE0f6yY7ug/1UwP8AKMP/AATu/Z8PVfE3/g2b/wCJpf6yY7+ZB/qrgf5R D/wTt/Z6PVPE3/g2b/4mj/WTHfzB/qrgf5Rv/Dun9ng/weJ//Bs3/wATS/1lxv8AMiv9VcF/KIf+ Cc/7PB/g8Tf+Ddv/AImj/WXG/wAyD/VXBfyjD/wTm/Z3PVPE/wD4N2/+Jp/6zY7uvu/4If6q4H+U af8AgnF+zqf4PE//AINz/wDE0f6zY7uvu/4If6q4H+Uaf+CcH7Oh6p4n/wDBsf8A4mj/AFmx3dB/ qrgeww/8E3v2cT1XxP8Ahqx/+Io/1mx3dB/qrgewn/Dtz9nL08T/APg2P/xFH+s2O7oX+qmD7B/w 7c/Zy9PE/wD4Nj/8RR/rNju6D/VTB9g/4dufs5enif8A8Gx/+Io/1mx3dB/qpg+wf8O3P2cvTxP/ AODY/wDxFH+s2O7oP9VMH2D/AIdufs5enif/AMGx/wDiKP8AWbHd0H+qmD7B/wAO3P2cvTxP/wCD Y/8AxFH+s2O7oP8AVTB9g/4dufs5enif/wAGx/8AiKP9Zsd3Qf6qYPsH/Dtz9nL08T/+DY//ABFH +s2O7oP9VMH2D/h27+zj/d8T/wDg2P8A8RT/ANZcd/Mh/wCquB/lNrRv+Cen7NmkTCabQdW1Lv5e o6lJIvbjC7fSolxHjn9o0jwxgV9k998Jfs+/BTwMQ/hf4ZaDZygjErWizOp9mfcQfcGvOq5lisRp Ooz0aOVYXDfw4HsKoiKFRQAOgHGBXE5PdnoRhFLaxNQUFABQAUAFAH8h9ftZ+BBQAUAFABQAUAfq F/wS7GfiH8Tv+wPb/wDo418fxakqVK3mfbcGK9Wpc/aw/Tmvg9bn6NcXA9KADA9KBiZP+TQAZP8A k0AOxQAYoEJigYYoAMUAGKADFABigAxQAYoATj1o1AXFGoBz6UCDn0oAOfSgA59KAFoDQKA0CgNA oDQKA0CgNAoCwUBYKAsFAWCgLBQFgoCwUBYKA0CgNAoDQKA0E59KBhz6UCDn0oAOfSgA59KADn0o AMe9Awx70AGPejUAxRqAYFABgUAHPpQAc+lAg59KADn0oAOfSgA59KAFoDQKA0CgNAoDQKAsFAWC gLBQFgoDQKA0CgNAoDQKA0CgNAoCwUBYKAsFA7Cc+lABz6UCDn0oAOfSgAwKNRhgUagGKADFABig AxQAYoAMUAGKYBigBcUCEwKADA9KQBgelABimMMUgDI9aBBketAC0DsFArBQFgoCwUBYKAsFAWCm OwnFIQcCjQA+tGnRArrqAximMWgAoAKACgAoA/kPr9rPwIKACgAoAKACgD9Qv+CXf/JQ/id/2B7f /wBHGvj+Lf4dM+34N/iTP2ur4Q/RQoGFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAH8h9ftZ+BBQA UAFABQAUAfqF/wAEu/8AkofxO/7A9v8A+jjXx/Fv8Omfb8G/xJn7XV8IfooUDCgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgD+Q+v2s/AgoAKACgAoAKAP1C/4Jd/8lD+J3/YHt/8A0ca+P4t/h0z7fg3+ JM/a6vhD9FCgYUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAfyH1+1n4EFABQAUAFABQB+oX/BLv8A 5KH8Tv8AsD2//o418fxb/Dpn2/Bv8SZ+11fCH6KFAwoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/ kPr9rPwIKACgAoAKACgD9Qv+CXf/ACUP4nf9ge3/APRxr4/i3+HTPt+Df4kz9rq+EP0UKBhQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQB/IfX7WfgQUAFABQAUAFAH6hf8Eu/+Sh/E7/sD2//AKONfH8W /wAOmfb8G/xJn7XV8IfooUDCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKACgAoAK AP1C/wCCXf8AyUP4nf8AYHt//Rxr4/i3+HTPt+Df4kz9rq+EP0UKBhQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQB/IfX7WfgQUAFABQAUAFAH6hf8Eu/+Sh/E7/sD2/8A6ONfH8W/w6Z9vwb/ABJn7XV8 IfooUDCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKACgAoAKAP1C/4Jd/8lD+J3/Y Ht//AEca+P4t/h0z7fg3+JM/a6vhD9FCgYUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAfyH1+1n4E FABQAUAFABQB+oX/AAS7/wCSh/E7/sD2/wD6ONfH8W/w6Z9vwb/EmftdXwh+ihQMKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoAKACgAoA/UL/gl3/yUP4nf9ge3/wDRxr4/i3+HTPt+ Df4kz9rq+EP0UKBhQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB/IfX7WfgQUAFABQAUAFAH6hf8Eu /wDkofxO/wCwPb/+jjXx/Fv8Omfb8G/xJn7XV8IfooUDCgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gD+Q+v2s/AgoAKACgAoAKAP1C/4Jd/8AJQ/id/2B7f8A9HGvj+Lf4dM+34N/iTP2ur4Q/RQoGFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFAH8h9ftZ+BBQAUAFABQAUAfqF/wS7/5KH8Tv+wPb/8Ao418 fxb/AA6Z9vwb/EmftdXwh+ihQMKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoAKAC gAoA/UL/AIJd/wDJQ/id/wBge3/9HGvj+Lf4dM+34N/iTP2ur4Q/RQoGFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFAH8h9ftZ+BBQAUAFABQAUAfqF/wS7/5KH8Tv+wPb/wDo418fxb/Dpn2/Bv8AEmft dXwh+ihQMKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoAKACgAoA/UL/gl3/yUP4n f9ge3/8ARxr4/i3+HTPt+Df4kz9rq+EP0UKBhQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB/IfX7W fgQUAFABQAUAFAH6hf8ABLv/AJKH8Tv+wPb/APo418fxb/Dpn2/Bv8SZ+11fCH6KFAwoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgAoAKACgD9Qv+CXf/JQ/id/2B7f/ANHGvj+Lf4dM +34N/iTP2ur4Q/RQoGFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAH8h9ftZ+BBQAUAFABQAUAfqF/ wS7/AOSh/E7/ALA9v/6ONfH8W/w6Z9vwb/EmftdXwh+ihQMKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKAP5D6/az8CCgAoAKACgAoA/UL/gl3/wAlD+J3/YHt/wD0ca+P4t/h0z7fg3+JM/a6vhD9FCgY UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAfyH1+1n4EFABQAUAFABQB+oX/BLv/kofxO/7A9v/wCj jXx/Fv8ADpn2/Bv8SZ+11fCH6KFAwoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgA oAKACgD9Qv8Agl3/AMlD+J3/AGB7f/0ca+P4t/h0z7fg3+JM/a6vhD9FCgYUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAfyH1+1n4EFABQAUAFABQB+oX/BLv/kofxO/7A9v/AOjjXx/Fv8Omfb8G/wAS Z+11fCH6KFAwoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgAoAKACgD9Qv+CXf/JQ /id/2B7f/wBHGvj+Lf4dM+34N/iTP2ur4Q/RQoGFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAH//Z CmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNwYWNlL0Rl dmljZVJHQgovV2lkdGggOTYyCi9IZWlnaHQgNzIyCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRl ci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMgOTYyCi9D b2xvcnMgMz4+L0xlbmd0aCA0ODk5NT4+c3RyZWFtCnic7H0HnBzFnXVVdc/MzmzOu1qtck6gAEIC EUTGgAnGJppk48PG53M453DncD77/BkHjI1NsAFjgjFB5IxAAaGAslDWSqvNaTZM6q76qqrDVKfZ WQy2hOsZpJmequrqnubnV29evT/c1pkCEhISEhISEhJ+QIT9iWH+PbJNFSB2I652hLAjEGbbiGdB QnOxjdHLdTDHVAjE5oDA1R75d2HD4uFHJgETgP59fRujoEGsCfBPke9HueYWMINhO74HQOEbseF+ PwzYBQqDYPE48IzvehS9TxE7QhD93s1DxBrHeI+zo5Gct8Q6r/s5sZ4/Nk+4tUPSaAkJCQkJCQl/ BLFVL3lyQQmgc96R7FciQwrqTs+bm0Dbn3oJlm8352iBJFVsRhm57+VDgfsb7b1zyA5CHC2dEKeB hAbvlUNbd9l7rpGSayL0yvEMjIhJE+L9Cjzklfg/JzmaZQ/yDsZJoPA5PTLsY+yaiau9pNESEhIS EhISI0YOLouGYyZO1XlkNNqmcPnPx9t5OOaaa0B6XKRiLvl5WIo/7M3JUw4POmMOhpn/mLlP+J57 kjxWXxZQ7pbYYsC+yyrxoHsckqXFvjTac8T/VwtzgSRptISEhISEhMQHAZEyGhTZj2UGsqUgxpmD qo7oI+E9ztHM3Ys4m+VHo4NWBfkQerFlHhw2F/vMc7GRP/KgxT5nFPvkHAHlbmYf9Do9fI1A/E3W Q5KfqQP4MmksabSEhISEhIREbog/4ovITci8pCdftThARERZ8urnpsjHJx2kLrOPhuGCJoX1E6Hz Ie5BPm+OvFXwXNML/kwYNm8leJhxfI8HDx6gCot9RzYg8v3UZtLDCMxONXrYuQmfOt0dhjd6i6TR EhISEhISEvnhPYuZojf371FEXSwup8PYr7vdwaZTEAfuFxSGzXLo4eRn1xGvpu61beRtWR7GF54D QVR+JJtH3ePgvLzFuWB1H24d40+O+bNkXYtusfH8ODHg2xBzje/3kfvLpDQ6k3veEhISEhISEhIi KOshAZEUgV1ym4ZH0N1fjR7Wc5wdx5g5pdGGoAh9xGgfXkscBHpY9mzDsnMMr15nhwrW3f3b5zFm nvdnRMifgufDtg2nMrS4bVAHr3fZV4fOh0yTnBsZfaYnXLDpjd7cns5xGgkJCQkJCQmJkSBfl4Iv 7KYjNYEAB1P0UW3dR5zLAE8cnqsXznNi7g1/Jr/3WXIEmzcCwz1yn1HMBnEhOFnv74JxU0YkSA/D bqEYSBcoUXtSO9zReIY3eliBmX/sH6snTsnlCRHTVySNlpCQkJCQkHgfMYLkCg5bEfTRa3Magl30 0ZSWA0wU3v5BXg5jHMVs5fJC5BSkgYOw5mvbsD56L1sD800VpBf7XoML85yJOQ7xz7UwGviq13kJ 1ayNv0rt2x2zLwoGJUy7uhBPKkjQlDBwXyN8p116oyUkJCQkJP5V4E3P8B4X8b6rmIaFQqiiYhBW f89DYOid/6zYmMJmxFwdkZ/W6evlcBzMSaNFUptj2yIajjfnnnygPcPwqADFfivSwcAxR2j2yJ1u YbbJ6fYwTMzGvXK5q22Om1tIZnNwzsOvPQKCYTpXY26SziP5jh+EjgUDpdHSGy0hISEhIfGvgxGU 2QOcjI2ofVAzTyGSXD4HO7Asz4QQgV/mSggRbQ8ijc6Vge2agkfWdbL2XAo0NN+P4H7SwQ1G6qs6 u9TxIPj7vC3kQ4vzQV4b+0Qd16kKB2nVuQdnlNpzZ7xBdb5kOtvYWeYwd7Ke/drwVUsaLSEhISEh IQGC6DVy/EyfbRNEeoJ2+/kW8R621AjMyXFFXwen+yOwRHvN0D6slzi6iG2CzBuucQTnxjCX4Bk2 AMH2DHME2/zA/4aWM5tABICv9jyyraK+Ico2F7fHzx3MLJLXwAZ+z5ifZmy9GK6lDsy1ljisyO+z 1mo/N4gLhsFD0mgJCQkJCQmJ/JGvmJ1fub4cAyo5oiD8DBUMYt0NXwLtu5XQl3wHRXMI1+VmtI79 jgHRIhAi18EcLpQc+SNBeyJHSos/AFNHrrJ/uboT/0Bo4KdVC25pwTbt1zmoKmFgQB5xbDrMnS0N N7TJLYYSEhISEhISwyC3H8MXLhLo9VcAxk50j5cDZalw3qxd8W0nMNGgcGi3HmxwMk91FWdAtb9D 2rlr0MWeBYZNfA7a6Xv+V+HbhWGY7yKXlm/osP8QU4cFPyXbTwO2l0Mu+uxVqZ3nha7jxNNMtHwE jwPsU+fOlpY0WkJCQkJCQiIQ+fM2V+Bajizn4Xwaxim4CWGYuOWs3zroXEgxM9RyKMfiW+/WQ8to 4e97zkGdvSfKEazhvVlZV4mJvFLzgtRlF10eqQg9IuTycvjAVR0wQJAO+GXC5Xv2ZdU4ePsghu6Y DtcgOOBiTK//ekmjJSQkJCQk/mXwHsRHJ1fLS4r2s0B4G2TpsusgFyMdpg4/Gk28Eq+PviscH9Y5 zRRrYcYC6w1k817zhu9ZsqMOZ242pyoQuaDZujsGa///SJhJGnk3dh5AOfb5+fciaLg4DvPGBKXa 2cnT/h5ooRK4jxq9vlUG3klISEhISHxo4fp//hFyq2E4nwjk4Da5rNJ+RNPioPYI1mtnYwdVDdqQ 50z58DqYOVUTqhhan5i0PkfdQSi8yeHccFysn8wMnPzeiUDVOZeE7HGh5In3zLbzr7k9/FD+CrSj Iw5I23AF5Fn3DhkJM4KE7Y2LDvJhQxBU55zXXrH3brKXkkZLSEhISEh8+BDEcfLftCcg31Q1VwyC iCA/g2ujoY97Oovh5GeH1yJo/1+gwm1o4XYyCQxIxIP5EehsF4/p2c/oPHzNmlxis8Ch8/Eov79C tSfK0Pmp54EIymP2a4NcR1gii+fRdgfn8V7I+FnDU4TFauZjmxZhxHpkLdrOU7A1npEbvU7SaAkJ CQkJiX8ZjJhAZfnRyOwcLgTlUQTRaL+W7gH9iXJAeUKDJXvH96Pm/hTZUsf9J4/cjRVXqHOAopxL RfbfWegps2L8nbvYii/ZzZN2vy/wP5EzFgPkCpvLz0JtRekRyoQt4ABLhotMuxizJx4Eucg0kDRa QkJCQkLiXwr50Oisq9SzkU4g0yh/2y7IW41GvmzSo/56R7M5NPCEwblyP3zJt0HKOZdy08285GeP 49nBzv2v3W8yHmboUrXtI7453OLl5MDfQ50DVWeH1TgvuCzOPjQ3T0otuLGDyLron/ayYdeN99SF cYviNuDalqTP+SQkJCQkJCT+lWDwxMDAtRwdgx27wmgIkdycGzsNzd42ble0q00OKdpl57C3G9oC JOfQPizZ5maBVJVZBjxRe5xSi+O5lgquC/Rxa+SsTeizzdHjSvfS6NzWi/eMIDZv09ag4vM5ChNa r9zyc0BH5Ktk20qyI3YjYAJ2CrUfmTaVbOyZAHt+1rbIpA4JCQkJCYkPH0ZanY4hB83y/cCXIPoN hbjtOMeOwKypI59QDh8C7Sc2O0wXgWqxY2KiAO8VoYGLQ9PXTrYnsnnvHIy3PusOm44HEGhfj0pQ tcj3nSvngyBaLE4mh2KdP6v28Gm3VGz4PYz7mSPMzncTIfc9u/h31nbiLQEjabSEhISEhMSHEJRH BMjE+e4X9P/Iv714JleAnfukvu4OMakjB432buBz2k6wk0MLXmF/em2QUbdMLojW/m5jxVmiBfjN 2WnkyE7MrVLbgxg00bkf0btlU3GSvL+HMVt9R2bweH+t1F5uah93H8HZ3xBAoDjtoNQOTwjxcTaD ADKNRXXfOb6r9qGk0RISEhISEh9C2LFcHgTRaGTUmgjYCZeFg5xkqafomXbROzc1dIyW0xvtonqB 2wrNjq7ternGFHi5Y3rQc1LXGbPLAL+6g14btNsuIq4ExIQNiyaa9m6rmcEy83E8e84rLBsIfR7e L/4bSNzfs+XaN/jZPSbxNyjnrjKIXbP1kOkAmwe7Wb60G1ghHma7NS1yi6GEhISEhMSHDSNlTfnr mtD2M3g/AoqRkBAQlGEA+xoSmNsheM+ixxLt4LguKdp2iXC7KxJPZp/apZTD7Hsi8mzKn1zyeba6 uGe94R7TRfoN0kyQ62Bur3Pe34s/6R8WI1Wz83msfEsJ5jW4kwfrAkfm1Qb5p55wDxtCFl5gAIjv vkZbk4ZCdIm9+xAAMWTaweYljZaQkJCQkPgQIn8aPULiJXh8PYO4jLlOWons7iIxdRmjvfMRZWyb QDus0v75dNjrD/FwaO+1uOcvJHhkRWiX0Ou5Uj6roCwRxyE3hw6Q6odBPq0+aLv0cI/bCJL1HJsC bdoq5voFKNPAJwgv29IVOC2OY5NpnwGduw9dZFrSaAkJCQkJiaMYQewkIGTN2ddmhr773pxnyVGO RISH+WEvMXU2FhRovxFsi4XPRkBPvJ243dBL6L0cWhCziXtwZ3t+h3THaO5Ld5pDhlOUXYJ8UCCg u1dWifd3Nn/QdHmk8HuszBVXXt39diU6mDSrx+ITC+3k08OTadeJfMm0zaRt0VrSaAkJCQkJiaMY +SQkmEeMn8S9kuhwZuh88qG90q/VPhdZ9NJoL5flyDorXKqwL1tlBNcyLotCsljl26lnuwcx/8SC wcOZoSFwaP/6KYFqtGsct5jthvCRU3QP6nCUgAhXkA+lDvJP53B6+NmmTcbs/a9ApOa2x8MzMfpE OAzT8K3DMjdaQkJCQkLiaIVPbrH5Qb6Bd271N3hXYgBR9vBFx0du1uh1MGc/9TeEMNOC3dGgxVmD spOGGmN6VW2rh5NAQyIScX/V3FtXJXsJ/lW+Tc5NfBNLst9LUPyfE4HpdSOl0SP1TI8UI91fKC5/ RjSOb7iHy+lhj5ODSQPPklJk5MG7D7OheJxGN8ukDgkJCQkJiQ8b/FOFh+3l50mwgG0iCzyk0z2O x39sw5CEraGy+xF9zdbAZLTO/XMWtRU4NLYTQqCH9FuE1XEcooBS284sjqA1hljs0D2OtZXQ52Ae 7Fmwbfh9mqOn37X8UzAsFaaTxB6hN//udhvGdIN90sBPeM5flhYN036Ds0uAqw5LGi0hISEhIXHU w02b8y7kkaMBD0rLvuawyahiv/WO6anp7bCFOOOfXR5lL0Fnjg7fTX5OYZhRH9vOYY/jqlCY5dYe I4cBm+VzzdE6ESPn4uJBmLPXVSLQaK+RI7gouu9hZxufXv980pwnAgusON6JS4i8diWKaR452huW aE+DADJtJXi4mLRrBDomXNksvdESEhISEhJHK1z74YQP/Gm0HZkhSssgmJB5TQviMF6V1+a7ruFE +RY4PMHZedrk29cY7UujxfZIqIoinMhnryEQaHSgFO1U9F1maK9sL06Pzxq5j+TcRzgsHw76/EPH pMX2w4+pOymw39ZA63WAwcM+4gjFyyfEgy7ZVh+SNFpCQkJCQuJIh2+xNwOubWpe04XRN7fLI8gE Io5jjIy8u/3s82SDMrzds2zbmrBIZbBt6vBow25Hh/E6Pw7tnJX5yieVL+u1gG6l2ShJI4rx/l4O F9HH7ugPs5AKdp0d5MZIFWjC6pCLLmHxdwDDHcOWQMQoVw4RIBoAarajlQJixLx5EgxF5RazNwoT bp1n9IH1jZtZJ4ajg64zMMYIIWxJv4iOz58HzOcK7R2ihM1SIbyKjPgzAv+1RM9W50HmBXNvelD9 FGBR6hxk2rfsi6uEITuPVKMlJCQkJCQ+BPDSYAx9mK5NGoLUa7cbGDp+Wxf5q7Ox03nsbuB2NQg6 NLKZLgzQoR1DOQM6BHXZ7dwQLdECvx8u2M55X5wlVHJxaNckvXXLvcjBh3Mw5WHlZ8z4qHnhBis1 1iIKwQQxJo0IY6/0ED2iQ2S0pwcZTYQKaww1BRt0ltse+BUxzupk1Qpgo/HHLIdyjJn5gZ4K8Ucs m5zIzgutnga9R+xbZHdcI5h99bQBQhoGCjR4NjAIMCvfTsk3LzWIGIenVNr4auh82FXQS0R+sXpe cXp4Ju1Ho43vAUgaLSEhISEh8SGGk3LZtNUNxvnyoNFeg4eXJXtczjm2GPowb4HjWhNznZcfgp7E DxcF92jefDTn7j27fZCRw7lmyOmHNt+4tyTmdHE4JpM97tNsRBC/5WzJEkj5MaesiJNpjHWFkX3m beGyrU6gwoRyYC4AuDLsppjAFKTZ8gZTemxI0dktoD4wZW+AzLhl8wLZxDBn+9AirHRMjXXQAFQV loWha7x0oUKpP2Y3nfD1FhuHUmgdcl0a6pSNY6TS8yCQMURuysQxstlv3kw6e6WeGi6OfYfi70Jw xSEZeCchISEhIfEhwXCsC3tptEM3dTqq3ZRa2HHozEX2JjH7O4ldORUimRa6ELfRIqfqDF16M39h R0Q7Z+VzaUEcGjhotI8f2rt90Ncr4oLQxnkud0PfLvnApNFcY7YKhTDzBuYhfAqfFZelWYVAzEkh MsgxYv+jTJGRUOOIQZGN11x1RjrRkbFIse6MJVH7+zoUrkXjrEtEh5wA05OHgY51oEMFsQ2chjKd ISAETFNJtnAgHx/arw1STfhVKMaIdAVAmETNO+g6m59l8DBIsF0EUWDBfm5pYFyIT5UW85V5mbpR 9F7SaAkJCQkJiQ8BDMbmZ+Twbya+NeBLo12/49vHnYl4ngRlp1A9EhpNRAJqEmXBcu2N3UAm4bPN 1QYzdovr0GmigGJhcFGJx8Sg29Y1esZxrjpstd5XC/ciTxHadY0jgmVvNk0dSPhW6WA9Sdw1OBRS kY5BaQGKqWFFASmdDKWxyll0JBQOQaAi1impYQ3rCCFVgWE6EiYagT3xgaSW1gAcSmYKCyLRsFJS WFCgqrlnlcZ4KJUe0ujNUjQNx0JMUI6pqDhCT0XYiXSYxiSjaxCgoogCtMygjvrSJJ3JKIgUFqjl obCuZ9Jc2Mb8OSkOhSOQG1TYRRNDq1aMxZP1iDOXukstF2zT+cfhiUyaK+JEp3++eVDSaAkJCQkJ iaMVliRqMrkcOxENeGpxe0d0cmKh6nI+pg7jIMy+zhpCAuzCrs2FZiNX2ULexkPWrYPiceistCI4 Rly+XmF8z7ZCX7OKw8uB3NTZQB6x0H4Hc7UfGY1mUi97GBDhii6zQXPn8N6+ZFNXIp0h9HVFcUFd EYqGQxjjgZTWm9Aoky0OodJYqCymRBTUn8QH+5KUPUcUpTSqRimn1bSugURr70BnV5wt1RRQW17S UFFcWVgQC0dAji2wbBrYunWITi2lg/jQYE+ScnQd01kiGAa4oTRSUhBOajCeyPQNJfp1Qs9eUxiJ INybwu2DmY6BdErH0ZDSWBKpjFJGrw6mcYJOi4CSCGooi8ZUw2ei0D8VIeXDN2QDBMjSVs6d+2Jc bmlj2aYDSaMlJCQkJCSOZhg0y8++nDOYg0P0M7jSPHzYWy4aDXIbnemnCrMT+NivPcaMQDXax85B srPyCN6unYXBUjRwrxx86xS6/dB+VvL3UFrlfRShLfBlCc8DSWByoCe1vnlwa0t/GoApVQUzqiKT q4tpm31dyT3dyYRG6stDE0pjtTHKocPpDN7WOtCWgAoC9bFQTYlSEoaHewfe3Na0dX97FIFpY+sb a0vryooaq8pDkDJd5mY2fg0IMnUY9xARm2cj4+ZhiDWd9KT0viROptI9CV3HsKQATa0tiKqhzsFM 60C6sz/RmyLFkfDs2lhhWN3XO7SjI7W5uX9A049pKJpbF6PtsY4OD6RaBjJhBGbXFI2riDJXh5U1 LtwUD5MWaqwAH4OHf3VxMQuP3ec3JI2WkJCQkJA4auHDthyEkfi99BsnwMtrf+SNsBA/5chVSEVQ f302+UGHiZm4aG4gjRbPGEyjvRwaeCmvQMetSAqH3uzycmT7GcXYeTRHHhwaeGm0cdwIffPet5FC BSQD4OF44u1D8ad39G5vTVAOet7M8vl1pZXFyr7u1Ot7uvf1pMdVFp44uqCuJFpbGKYnpzT0jQN9 9Pjk6qJZFUpVoaogsmL7oWdXv9vWPXDcjPGnzp1QW6TWVZdH+ASN3Dq+9c/wPaPgGTPbMxC+aIOw UhJuuKXpXxlCBtJaZ0JriSeb45kChGbVFk6sjCYyemdC33K4d0t7SgHoI1NLJ9UXtfQO7elMPbGj b1Nr/5TKyHlTymaNKgkheLBP29420DuYmNlQtnB0YVHYNJm4Yu9s15NBiHO6O9z1ERmNtjVsIzFG 0mgJCQkJCYmjFy76QjwkDJqHg0fwcybYHwk/fXNZUaCtPDA4K9z6jONVnc3UBvG8WVnX2Fhmj+8S jEVbhU2UxYotRoKEPROEbJKE+K42vjsNY0XhV8UEW5X9+g/4FjWAFE4KCcQKUVhkBQvi42QaYpUo utMjbpewYXvkgMK9CYwYYsa3cQggZt7lMceYEW3IN+oZQRXsJcvyIziDkMojL3hIBVHYFes8co6l TygQs918PMuZn469BZzQc9rKsuroIGwvoaIgHdB59yX1dw7Fn9ndt3Jvb1cCXza76uPHVIwpjWGg r2oafHhTZ28yffaUynMmFdWWRKNI0RF+5/DAX97p7E3pZ02pOKE+XBkt6Ojtf3z1zgde31waQdef v2TB+LLG6vIw80vj3KEcfycYx8W4J4kPxhPvNA92JTKLxpYtbiymH/UMZta3xJ/d1Rcf0C+cXXnm pHIN4EM9qce3dN63sb06pp4xtercKRXjysJ9Q9rK/YOb2+PTaqKnT6gcVRrmoR7IVpERwFyr5qfj GyBNNZ1F57nnwwNGdKtgZ3bfoWHqYFstXzuY+KDuh4SEhISEhMT7hCBPs+unaq892uzolHJFZZoI uxINZiyewuVjRj4HbduDz347p0/a5L7ONGiBOgNHX699GXk6upi6RaazFhcrKNqIWiMqi6wwb5EC sgSdsSmcgYrKaJOiMo7KZFaTHzMFVfC0iLdI4XHCLGSNWSHMbAnON41gE3ZaBfFtbsY+SLaHUWFN EGI3gzls+VmYywAjHfLZKTweWVchpe/0HDovRa4SQ1bHAJq0mvdSSYbg1ri2fE/v45s6NnYmIkj9 xJzya+fVVhdGKLF+YVfnPeu6MU5/ZmHjqZNKawtDIUgSGbKqqe9Pm9op77xubsMpY2MFYfVwb8+t j656bPXOCfVV/3nJwsXTGyuLwjpQ2e2jJ1OUD45DG2DfHcykQVjTtLb+9DM74829Q+dNq5g3ujSk wmRKW9nU+4e3OjO6fv2C2tMmlYaR2juU+uOG9j++3V4QwgvHVt24oHpGbTiRRs/t6H1tf8es2qJz JteOKVNCIfrNM8UfI7Y3kEWUsJAPwlcsbI1ll9oRJyNMzVSmRSZNlz2SRktISEhISHxIMKwZgP+O 7nVR5+rrCrazf+dmWWjuvoKu7LF8IKGNoTSberaDRgPbG223sQYy1WiYDQ/xL3wIoekJseM7eO08 HtxGiQ/jx4rxyz4ydGtKEGGIclYmAhv1P9hrVkSPVffDvEQfo6ua/+KB0Wy2Ic6wI+t8aiGi6dDI +0AGyeZxbGbiG1ZVyo6tIimAn8MwZPM0OqzrSDGkX4wtws67UxKoYKasa2xFwFTSDCGHu5Ov7um7 a0NrRzxdEUMXzqy8et7o+kJ0OK4t29l595rDoVDo2jk1lxxTXh0L05HSGbDmcP/tqw61DKSvnFP9 idnVMVXd2dr10Mvrb3/2nSmjqj770eMvXji5OBZm/JIlTBMVGnYIxDcsDlOw8O+BschglWDoWaGi aNqOzszDm9t6UunLZ9XPHRWlbHggmX5hZ99v36LXBb+weNRJ4ysiIXyoJ3PHW83P7Y4n05lF4ys+ v6B+am1BQifPbO15o6lnWmXs7CmljZXFBSpbDikYMCJN/2IZgAoQKmViz+82rvBsMVJa0mgJCQkJ CYmjEqIV2AtRkHZ5drObEZ10CAXsdvPQa6wYXl7B2CA05pzYvftQ1KQtx4WfG0R0aACDffrRaCAM JdJog2Gz+nVWbglzUEAVMWMFS34wSk9DTmD5JXOuRhhlQ4rxKz/gV4eZJwMpBGR4eT/FN/XPuA86 wioxhGuQYZya9lV5xT+ILHGdUy9iFg40CvYRwuwckJfsM6LVkJHQzL0kvOKgQVi5/xhh5r1GvMI4 HVvlWzbRvt7Em/t771nbdqg3EwuBM6fUXDevZlpttGcw8/q+3v9d3jyQwmdOLr1lUd2EykI6vbRG 3u3u/783W9buH7zo2Mqb5lWPrYjub+t7Ys2Ob97zan1x9MYLF9x87ryyWAyyeA+cQSq9DpXt2GPX wPwNuTJF3h8Qm9VCTNckKivHglbv6/392paJZQUXzqyeXRuj/LW1L3nvpo4H3umaUV3w5VNGz6kr QkBfc6j/rrdbVjX102mfMbXs8jmjFowq7E3of9vStnJ/79zG0nOnlo8pLQgpCjbMPApiIjvRNbN+ InKF3AG/4iw21VZpp9cPSG+0hISEhITEkYLgxDp3Pe1hx/GN3XCHHNtRZJ4xffVpm/v6cWjT2iEe h+Jry9ThvIRAGm3XOzRiesVJer3RFCrMlu6z5e1EMtndn6K8WTUSoaGp4xJgujUUpjWzlDgMYFEI lRcWtsSTGKcRUBSoI6N+CGThD4bIjRgTz8ZpZwiIKKi6OGYqxkDPENjZ1debzPTFB1vjg0kMakoK 60oLakqj1aUlgJ5Pp9PRCItmJr0DQ4NpOnO+AFBoZ62sNFakqpRzm0o0+0PjWwf58EzFhvGUtq55 8PdrDu9sG9IAOaY2ds3c+jOmlus6Xt88dMeag6/vG5xcFbrxuIaLpldE6OUhtLNr6PHtnfe+3Tau ovRLS6qXTqhIp1NvbD/8lTuf27K//eNLZ3/jsiUzG6oBXxgovAqgQaaNm6ZbX+P77uuA3kLiiNvK Mf+9gHJpZlsH8bT+6zcPvrR74IaFlUsnV9fHQhokr+xq/+WKjoPxxKfmV58ztXpSZawvpT+0sfWh jR1tg3pdDF08p+aj08obSgt3dqSf3ta+vXPwnGnlCxuLRpdENG6VZso3fbjMsBFgGDxEDEOjX22S NFpCQkJCQuKogUtdxs6CKb4YriS18SprDoXOaAufxlzKdb7N0mIQTKOhxVcEz0ZQvoepRts02vaK iHTcptEW5+bV+FA2y+z+lzc+u2ITjBYikuLNIVc5Q8bOQkrRWKkRlW0OTGv6FUuOOX7GmG/87qkU ouSYb0uk6wVo5qcZp2Y/5Qu6uJZKTx9f/eVLTy6MsRjm7U09T769ddXWps0HOnqTeoYVvNZp46KC yKkzxnzipJlnzZtcWMBYfAqijAZ+/tflm/a1hRTIKvBpmVAo9M2rTplSX8VKDDKBnFXGJthg8Fhj /hL4bkfyz+vbXtjVTaejIuWsaSU3zK8dXRrb3514YHP745u7Ejo5b2r5jXNrp9RG6SUnNe21vb13 renY0tF/5bF1NxxbOaosfLBz6NZlq+94YnUkpP7ohnOuPnVaeSymc3M2hca/f8h3Q7JyKUYiB0J5 hCj+vSA8XJr5xqG5w5PdZMjXVERfdSD57Zf31ETAl04ZvbChIoPAoe7U79YcfHxr76zqws8sHn3a +EL6rKzY233fho6NbQP0dk2tDN9w/NgTxxdqWH9z78DDmzpKI8rFs6tn1xYWhPgWUwQR1rAR38FX scMyacPaQZdBkkZLSEhISEgcfbCtEXp2O90wHAd5vBbiW3fytGhZ9tvdiPyKoTAK69wmKNg5sjTa 6evwp9EQAt+kDpFDG4OLc1CEs1MCm05r53/rrm1N7SAUgZarldMz1Sw3zSIa+D+UM6fTy370me54 3yd/9GdQWMK9DBgw84UGuI/CcTfNShwEJDI3Xrzwlzeek0hlfvfCmrueeWd/1yCbusJT3hSWDMGK bBNI0loIkB9eu/SWCxZSthaCZFdzzynf+GN3fIg1o40TqdlTGp783tX1FVHIWSTtp2CkIdPnoOv6 8zu771jX0TeQZherwC+fNOr0yeUFIXXVgb47Vh/e3ZkGMHXJzLrrj6+nR1mSXZ9+7/qWx7d1Al39 xhkNZ04qi4bh2p0t333wlVdW7541cdRvP3/+wskNxq8gOqutzYtcMz2YxZoQQyRnywnmkOZlAnM/ ZX8v+PqBUN4MdV6cEHL3BVB4volOb2tHf/KHrx5+u3ng84sqPjqjPhqi6wRyz9qW+ze20oleMafm 43Oqy4qV3ji8bVXTK/viCuXIAF49p/ay2ZWlsVBzX+LRzT0HOvrnjyldPL5sTGkBf65MGs1ngBzF VoD4WojAg/wbljRaQkJCQkLi6EKwSSNQmQ6qq2IyTt+K33b5Qv+QkKDUDodLxCNLZxmwxZIdWwwF /u2m0caY0LlF0uON1hXOrrmqiNra20/65n1J/qs9xDpGIUYLIcHIjBRhZwSs7h0gmfqy4pX/c93P Hl35m2ffhpRsMnszZmF3yLA6+9xVgrFC4N++eMkpc8f8/NHVP7p/OSjAejjCrNc6YMMyb3W2WgdO ZYoV9Pr/XT9tdA3lh69u2nPJ/zyWRJBn8wGSGvzqpUu++4klYaZgs0g7ww8NuMu6L8EI8VPbe+hQ OkmPKot98cTGY+ujOlYe2dx+7/o2XSc6wTcsGHXx7MoiVaHcc1fbwK0rm7d1JIsU9JXTGk4eV6ZA 9MiKzV+566X2tv6TF0y8/eZzJteVY8DFX7Ybklmx6Q2iRNJIhlYMVzc0ibwC6UkUnxvxfsJ03duJ GOy+8e2Y9H5yTw5MavovVzY/tb1z6aSKmxfV18RCdKny3N7OW1/ZD1F4VkPBFxc3jK6IJZL6gxs7 HtzYFoaMk8+sKvjcksbxZQXxZOrlA4Ormnpqo+opE6rm1MTogoQ9DtYPOwRkf83IfteuJGmDRr8i abSEhISEhMSRjeGt0ALXNA8Mpxq66K+nHIm7v+GvMD7hlALbR4Bju6Ejr0PwPbuD+Yw6c0awRraL 84LMWQlVBgV7NDH1b1PbpvxPQTx0j4fJ6fTD19fvu+pnD5OCCDTq+tG5pTDRMxBCQV/UIFFJOnX5 GXN/dP2Z53znT7s6e4Ea4X4ZY7siC9Jgwj/zUNO3IchEdx7qrIHJ1UXP/NfVOw91fOQb95KyCECq gpGu62XR0PSGsta+5L72OI93Rio9Ex0wmbz1U+f+27nz6Vg/f2zltx54HYRVrrZqIKP/9WuXfeT4 iUaUH99tZ4R4oI6B9G0rD69u6ouEFKzpE6qiXz517PiSUG8a37eu7eltXSpluBh86sTaCyZXKQqj 4G83xX/62qF+TSsLq99aOn72qEJN0+59ZdM3/vRSXzzx8VNm/+KmM6qKi4atHp8nELcav1+jAU/U Ob0iXriFLe7oNzKY1m5b1fLizu7Z9UX/fmLd2LJCHZBXdvf+5s1D9D40lke+cFLDtOpYCqPnd7T/ fnWrokKsaWMrir6wZNSk8sIU0dceHlh+oA8QNHdU0ZLRhbGwonMPPIEsbZCfjr7gPhp7SoImLWm0 hISEhITEUYB8mIkg0losNieN9mrPPkX4LJ3Y1qohFJ0j2I9DOz4NotHGQcuxjb00mv9NgECjs22I rT2bZf+s0YxpEi6mIhZyh+D37n3lDy+sRZGQUWADpjM/uOq0uZPGJBIJ2lhhjZjgHCLKYCYxc2wD wMlTvnavWlSAdYJURGlvPK0BXcNABWZKBoqGUDikanzvYSqRunjhtO994uRP/t9f397TAgpirA8G 5x474QdXnTK6skTD5JE3t331nhfTCjIt5yntlnOO/ckNZyZS2vW/fGLZ2r0gwsNFUvqYquKnvnvl 5PoKwOv+IV5ghV7awd7UnW8d3twyEFIQBnBCRfirp46tLlK7+zMPbOx6bndbAVRpj+vm13xkRjXT 1nWwav/gr1Yc0okWC8GvLp14TE10MJW5++WN37zv5VQqdfaCKff9x0UlhQXG/c/1oOQNLpy/LyNl IT7COo/oBsSscUNvZF8qc8eKw8v3944tL/j0otFzaqO0/Ys7e/6wphVjXB4L3by44dhRxbT5Szs7 73mrBShherwqBj+zaOycuqgO8LrW9LrmnjQm48sKThhTVlmg8ueExR2yXxLoQo/tOMzeHx8a/fIB GXgnISEhISFx5GJkNDrbJRc98qXRPschLwwi+CicBg/bv+Hua3HobGvkFKqBH40Wkjqys4K2/8Ot cLsC75gFAvKqgYiRHNTcFb/sJw8e6BlgyWaQ6AgUQ/jyD68bX1uGkcKT1EiIwAzSVaLwQoc4Pqjt a+3CIRQCoECBO9r6v3Hf8829Q0YBPMp1awpD3/3EqSdOHTOQTKhQpdyuOKa8vKHpy/e8QBTV9GaA 5OfPWfSDK06JsJRiSKfxf0+sbusbiIZDGsGpNFkyfcznz5n3yqbdn/ndCwfjA9C4LE2fN6Huvi+d P7a6UiFG7hsTvHceTt/9VlNTPw4xiVRTVfU7p4+dWFFwaCB558rDO7qG6FWrQJlaW/il00fFoKJp +oNbup/e2o5Z7DX55PFjzpxcktZS3/3z8l++8A69L/VK6MUfXze1vkTjRRA/0BzovxNmMRtOXlUM NB63ogGk8qxvRPCBuPb9F/bRBUlEVS6fW7t0Wrmexr96s3lja1wnMIzgx2ZXf2R6VYLg21e0bDwU N0YLh8NXzKk+dUqxjuHrB7v3x1kiSakC5tUXjS8JQ27wYOnSdPHEfdXZ+Tgd0mz1I2m0hISEhITE kYyR0ug82vsV7nZUNskOa71y5M0Jn2YLsggGZbNUsmsvoOvU0FFgJZteZ/pTxG2IgqlDDOtw0WgA QwqLtuCiNEbPrH33s3c+revEGh/NmVh323XnjK4sIljXea0TFRENk8KQEomE+J6+ECJMxiashAp+ ZM2eL9z1bH8qo7CrZKx73uTaB75wYX1phJJmzLl1IpG46bfPPrl+L2O5UFOAQrlveSR0/amzz1sw dVxlUU15kRHuwaKoAbsvhiXmp4+t+d7f3lRZKDXzIWOFnDNn4oNfvjTMildDllcB9PY4+eWbB1r7 09xhoEdC4SsX1C0ZX9yXzNyxon1re5xXTlSqCvEXTho7riyaAuCJzW1PbulUGNVDp04uv3JuVUSB P33irW89vJyevDAU+u11p1128izE0vyObA5tJNBZb/nPE5Cnb/OAbaMejU5eZ6EcnQRoIQyvOWHU 4vFlbfHkb95oaY4n2UOghq6bX33SuPLuwfRvV7fu7howYl8iIXTtgvp5jYUpDbywu7d9KE1XVmGg LRpdOqUyRlcXmrUG9KtrKNDol/YP/eNuiYSEhISEhMQIMSwt9pOig1taJQDtI8YLbxkXl1XaI0Wb 9NclRQtOD0cKBzANGA5rB3TG3llqdHbToZ15Z5tVhJ2LWNySyOprs/A6zRyQkP96+LW7XtlIdMOM QRuEqssKjps4CqqsAgvlqpTCYqIl09o1S485d+54nq/GfbHMYK3QLl9/4LXfPb+azhkRxMushK48 efovbzyXTZsxOjoSaI8nbrx92atbmxRe5xDwQoM6L5wSCynTGyqOHVe7ZPro+RPrJtZWGF8OnVw6 g2/47TN/W7ONxzObcdffunjJ1z+2WGG7JFmdxWQG/27Foc0dCcQ2R6oKBufOKr90RqUO9D+u61xx oI8lWhOihtD18xuOG1uESWbVgfi9azoyfIvctJrYLYtqCyORZev2XHPb46kk07Y/e/bcn1x9iqrQ NUIGsQ2Xwc/KPxuOoAy+ZlJ44DfEegZSyouNWjApXXtwfdeKvX30Cy4LK59ZPGp8ZXRb68Cdaw4N pViYXSyifnbRqIkVhYf6Bn+1ork/AVg1cKBXxAr+7cTG+pJwdzL16PbuoXQGwlAIwdPHl0yl6xKS YUF/zlWlL42W3mgJCQkJCYkjBz5mjBzM2Pg/doeEnMc5vOl4CrOeuk/tGNbwNfgkfjAa6JKiLc7t DsVzWTtcgvSwNNqm8ubpBG1bIZgozNvKL0TTNHzlL/666t1mLgFrzGyMKG+GlIPy8oIKgmkMFEp5 McR333LxhfPHcYJuqbOIDCQz1/zib6/tOGQ4lVlpcBj68VUnfuas+TzAjqXDaYxt6d/98/LbX1rH lGYmclOGjYBOGbXCK+AwxZeyubljq646afpVS+eWRVQ65+3Nndf86qktzR0hHg1NECyNRu+86azz 503m9V7YHsFlO7qe2dpHr1cnWgio02oLblw8Oqrit5uG7lrbCnmMNL2iRWPLrlxQTS+/uR/ftryp P5HWkFoWhjed1DihItTal/zIDx7c1tJBzzFzdPXjX790VHkBgiHEv4SMoilYzeN5+SeA+HF8wxjN F3WsuqHCCLHSHE/e8ebhzkSGXuP4SuXmk8ZGFWXZ1s4XdvUyezmE48vDnzlpdExFq/YPPLixhdV3 B5SOa3Sl8ekT6hUVbusYenpHL11x0RMUF4TPn1o2ppgVTmfLIT1bkEXSaAkJCQkJiaMUI/A6Z9mo 84izvTggEs0VRoYGcO0vHCGNthp7dxAG0mjB+2FaO+xChsPTaFZlUKEsWQEhDLU9h3uuuvWvLT0D jAOxDDcV8zIovDgLpgSaVV7hRbyPGV9z183nj6stoyRMZ75qVgmcctm1u9tv+M2Th7oGgPXLfn1p yV03n7t4eiOzFCvQGAFAffOBzk/++undrX2UsVMirxFjfvwyufHDyNgGSP3UmTN/evXpUQSXbdh3 7W1PDqSYTM5K9UE8qbri6W99vLG6lF0Uhs2DmduWH+zPYO75Vkui8LoF9ROrIv1J7ecrDnfHM0ZV xbKC0E0n1DaWhTBGd73Vvqmtn1N+cP70yrOmViBIvvSnl29/fgOdRjSMvn/FklvOnscyQ3Qexcfs JRiAI9TX4c6bs55hzMs/8q+Q+aR5bof+3M7e597t1AGLalk6sfyCY2r6BlJ/WNN6sDcF6QUr4LRJ RefNqKHU+4FNHesO9tEvKMRjOC6aXrtkQjEdbdnWrg0dcaNa46iy0JVzqiMRBWFzN6FzSuavB6yc paTREhISEhISRwNGtmXQp427i6M2m+j3YGwV+8R0mNkdPpsRGasUJ2N2JCAgzw4DN43GzgaOwDto xfnloNGE1ctWCNIoCSYKevTNrV/786uZTIrPglcV4Vv0EC+kwlRGpvhqtOPFC2fc/pmPhKBRc4SV 3mA0HGXuf2P7f97zYlrHCi9jSFsuGFv1yNc+UV4YZVEgPMhYJ4htXoRw467DP1626tn1ewnfMIh0 nduOWZ1plpyBeE4JQbEIfPgLF586Z9xPnlz5/b++yQ+GFF50++y54x/64kUqM08zUf6+tw+va0so GtRVyu7JKRMqLphZTj94ZkfnSzvj/OT01minTq66YEqFAsHbLX0PrG/X2R48vbG44KZFDUURuGZX 8xX/79HDAylI8PwJDc98/WPlhRGdVz5nKwF2d9H7na7x9wJatcFdNBpmMwrpRzpEKq+bw6ZP/+gc TN+9pqV9gLnMC0PkmoXM2rF2b/xvW7ozgP0WURxSblxYP6YstL8zdf+mjp6EZuxJLY3CmxaNrowp B3pSf17b0ZtOG4XnF08sPG9aNXuieAVHZ0EWSaMlJCQkJCSODtjs2Uc15NxCF9/mHgtaql5QS5fZ wxXfYfFZvocPusuymI0FkzUyezh82KJDGmZDOEzCLWwZND+wBWlopkSL5VdMe7TBrlnABS/7R2ni N/7yxl9eWcdvDjLqpTdWlU+oKaEkKUNYbh09M6Y0WiPXnnrMx5bMsNLzdKNsH+WX37jv9d+/uBbx gGg6S9rpqpNn3n7TWQaXYlsJWRQGY8CIx0v3JdJv72l5ZcOBN3c1bW/tHkpmEGD6tkbJFkgTHAoh FmD3nUtP/M/zj7/+9qceeXungpllgF5AGMKvXrzoWxedaNgVDvRo96071JcyJG1ESd5V86oaSmPd Q5nfvdXaM5QkUKUXWxID186tG10WTWna71e30A5cW4YfnVV3UmMMI/jpO566//Vt9OaEEPz2pYv/ 86LFbEBeaZs5o/ERvcXQgK+1w9GAEW8dE+XpHZ3L9/VA9nsAmVUfu3J+bSKB713f1tSX4DQYz28o v/iYKrq0eXp718r9A4g5cNizcerE8vMmM8f5o+/0LD/QyX9IgOEQvG5B4/TqMGGEXdP5+grzcZga jtlPMCzw7sV9MqlDQkJCQkLiqIQt0eWjRgMuJBMrg9m3g2scZIXWubzXTDKEPgYPRnmhww9thXs4 skGQKD9DozKKN3nDPK+Vi+dWoEUabZ+dpbwR2JdK3nDr39bsa+WVx2kLSnjw/15x5uVLpgFWkk9h 7InxIp2AEKuZjVilQcRlWsirHHb1D934m6eX7zpEdEqD6ZCgQAn96Kolnz5tDuffyKjTQfmVzl3G 9LwRyBR52jyZGtrbOfDmu80Pr9qyfl+bxurAMBOJBlEB0n581ennz5/8kf/9666WLiNdBOFMcWHB vZ+74KxjJ2Cu/T+7rWNFE4tsg7zYyILGko/OrIwA8Pq+7md2xhEnl7TnnPqCjx9TFyJ4XevA41s6 0zq7r9Ux5ZoFddXR0JrtBy//zVPNvQP0zHVlpX/76mVzx5azRQXh8R5so6NGGSF8n3KjRwpHVUir xIlVWXIE4PmGbCW5rzPz582dqRSrrRNV4GXH1kysiLy2p/+lPd2spDtBhSHyyeNH1RaHD/Sk/rqx sy+l8agPUhFD1y9oKClA73ak7lx5qDetsd8RMJlZG/vskjEhtsOULncUPmFmwsH8twUzN/qF/ZJG S0hISEhIHDGwq6bxfIncsGk0gVnf8HDALk4snhd6AjsU4EPTLUbrrqiSNTpDgSULRb8NIIs0ezr6 5HW4aDQPtshFo+mfG/a3fO72ZU09g3warKD3mMqiO285f/a4erYHETKuivgGQG5NhrzYNeaFv1Xj vOt3N3/yN08f7qWcld0SDepVpYUPfvGiBRPqVQIyhCVFtA0kb3t2bX9SY4YQlaSSWlVZyRfPXVAS U41EtsO9fR+79bGNB7pYRUWuZxfH1Ke+ftlgRrvox4+k6AkJc33Q+U+uKX3p25dXlUYBVBMZ/Kf1 bQfjKZVRfhBT0aWzqqfXRDIavHd9666etMp5u6IoH5laevzYYh2jBzd17WgfwpgSPDB/XOmFU0op 9fvho6t++NhyVoSPoMXTGp//xqWKykV042Fhyj0YMWn9gDGs9uyFzr9GnTk04N1rWw72pHRWwxKf MLrknCnlrUOZBzZ29Ca4i0dBpzTGTp1coWvk8W1dW1r7zSdQCZ09uei40SUDKe23b7RuaIvzxZca DqHPLKxeOKaEWa7NKHb+3xozxLDgEEajn98nA+8kJCQkJCSOGAjFh23K6G5CTFuFL7xk2uVj9hwx eiGXkGy3F60Xrga2tdZmwwaRdQ3FybRvtUKHuyNbz8Vi0lmviMW5jffQJ98jq23/ZeWm/37g9cG0 bixF6LBT6yq/ccmJpSXFmqax+6YjBWlsJyGEKY3MbKyqKy2ihB3xn+3pP39Zvvnf//AcViDP32B0 dvaY6ue/dXk0WgAZKWYH1+1pP/2/7zdK93GTMb1AcufNF54/b2IsjPoTqdW7275y7wt7Wvsg42H0 vKH546uf/84Vv3p2zQ8efsM0TNPjIHLJwsn3f/4Cro6j/V1Dj27viaczChP9cX1hwVXz6grD4FB/ 6uGNPfFkit8XXBqJXnVMdU2J0jWk3/9OR9+gRhsjFVw6o35WTbgnmbzy50+8tOUQYmI5uuXMOT+9 9gy2S5QY2rPhhufRFPmtvT5giGp0Lvh/zHNY6L/P7e5+e38fM71DXBuLXH5sPb1vD29s39OVZmkt ADWUFlx5bG0EwndaB557tzODCavRTvRJVaFLZtYjBTy8rv3Pm1p5JrVCVziLRhd9+dRGRUFE141C nIYmzf9EkkZLSEhISEgcoXBoxqysHRL1aV8O7epiN3MypQAabQzr3OdnDeuwKYvdDUFa1MIFOwfO 7g4EwEWjzTaCu8N3r6Hh7shfkDbG+d5Dr9794jsi91dQuCAMmV4L9AwjQNxGzVM1YmHl7s999NQZ jRDpgG9AzOj42395486X1hlFW/hlKp88Zfavb1jKiDWv56Ij0NQ+cOp/3d89MMTSOYDh0oXVRZGz 50+sjpU09/S+uGV/9yDbgaZgJolTWnbv5y88b874a25b9tzGA7zaC3NC02/1R1ct+ffzTgD8Fq1t jr+4pxsTY/+fPqOm6JLpVXQGG1riz+3s07BRnAU0lESunlOrqnBba/8zu3pSOlPWiwvgNXPrKyOh FTsPXPvrZ5t7E5hoIQX/v2vP+tTpc41bZ8WVIO53OeKSOoKYNAnUzfmSEuj0dm7vSj25vUsjdN2D ChT0kenl06tiK/YPLD/QxVZ3OghHQxdPqxpXGmkdSD2+vbsnkWJ3ApDSmHLpzNqqArR8f/xnbzYP ptLsywFqTSz032eNnlRVRO8by/AgvIwOCwhhtXskjZaQkJCQkDhK4FSpQd5+aLOH2/KBhY8U8YhA kYHziNlAcRIae5ca8pBsxbkdEAgpH8FM2uH9sJqRbPKdeVLiFaRNZzOEl//skbfePQxJho6hMwlW Zz/zY+6BYb4PZkfGQKWMmBKuOWNG3fPZ88bWVWBOryndb+0d/NTtz6zaecCYBcvuUNSfXbv0kyfP BixKmN4vto8tQ/Anbn34pY1NhLkIuMGbSc5mKAdPHAZmnh0f+YYz5v362tPebes570d/PdTbp+os N4Q2iYZDT33tkkVTG41Fz4t7O9ceTpjuWwRPGlNywtgSOshre3pXHRpAAHHDN5lVU3jxtAoNwDf3 965s6saQ1VIZXxm7bHpJGIbueWXD5+97XUsliRIOqeDhL3z0nLkTEc/pY9J6tqrIP41GE4sx29+p +Ta/vgKgQr8LxB7itsH0XzZ2JDRzlbVkXNEJo0r29Kae2tWZ0IBRWWfpxNL5NUUZiJ7Y1rqnJ23c TzUEPzKlYmJZ9N3OwW8/u685njYemIgCP7d41CWzqrnnB3Ejdra6ocJs7PtkUoeEhISEhMSRCG9l QRGiC9mwFuRu7/SHeGm0eXxYGm0fsaI53OMH0GhzBOQkxCKNBiZHF0p/87/s9UJWluY02mpmBOEh gjTIZFa04Ct3tPf0Q6NgtM0UWckUtpkQ6URTOMHlQdFXnjj91uvPRqx8Nv1Xp4OtO9B55f891DU4 ZDB5SrXLC8PLvnnFMaNrWFgeNPwbrDjHit0tV/7yb33xIZ3xd0CwYkyJEi6N1fRWuJsWqwjcfM7x 3770hKJI9Mn1e67++WNMnCbQyLSeNrrm1e9eXlYYosRMw/iZXV3v9miMVBI9rKhnTCieVhulYz6z vXdH15BRX4Z2P66+8NTxpRpAz+3sercjwbgxQMfWx86cUEJJ/Df/8uqvlq0xfCOxcOjFb31iwcRa wJg9q6RtWHGsaLl/9hZDYX1o7Agd2Tg8oYX9QoDgYEZ/eGtHd0IjvN7hzOrYmRMr+lKZR7d29qX5 yoHo8+h9G1umYbDiYM/aliRgLdmzcNr44tlVhV1J7ZbHdu3oTPJpMZH73Bk1PzxjHKbfp8JoNAZm OU8Wq0ifhGf2yi2GEhISEhISRyhyMGPG8KBpR/ZpD92sF5hJHVZLztScHNpubCnTzu4uQ4hpwxCi PFy+DsZthRGymwgFwm0NbTpAkFCxBWYD8qDx2z3IcncirgqYykyQEfxML3z8TbcCQ92EfNshYSFl zApCFH4NxIigZmVZgPbfV5z56bPmM2O0hg3mfefL67/251f5LaSnYS2PGVP3/HcuCymqwgOnmazJ ODgTdl/ffOC7Dy3f2NQBzBp7iI6pI65PY01Vw2fObLx+6TGnHzMhpqoJnP7OA8tvf34D68n8IRnK vi9fPOOufzsf8ho2KZ08t7t7d29KBSyOLQrBWRPLJ5dFh4j+/J7B/T0DOtIVzJI2FjaWHd8QS2fg U7s698fpXU3RERc1FJ/YUDSo6Tff8eKDK7ZBlZH1EAAnzxpXXRrNMJmWUnqdkXhDheWbMv/JcNJo +7l1/9hC/FVz2mUwkz5pTPXNF59QANUHd3S3DCYV9kWA8SUFZ02uUBB+aFNHN714lmRCJlbEzh1X DJD6Tvvg6kPxjM5pNCHHNZQsHFXYl8bX/GX7zo4BzFw/rJjLhDL1yRvm830D7NmiSzACjaxwRdJo CQkJCQmJIxQuAh1k4QiiQSjAA+0cDQPPHjPfLYbQ3QDbkxQpL+BuaZcH2ibT9hHklJwByIZJC0xa gVaYc1beNpOvffcaUmrLRWFI/rpiW0E4DFnxQl76Wzg74gUaMcYZluUcLgDk+OljRlfFmO+C1cBj CcEbmlq2H2gtCIWZIIxCOJ2YOKp68ZQG7/0xhOeD3YlXN+9+Y+uBvZ198cFkWFVKYpFR5SWzxlQt njp6xujq0liYM3dAz/vSxv1NbV1IVQBRIUxrmrJ4av0x4+oZNQf09PjpvX0H40k6cobgQgWdM7Gy sSicJNqze/pa+lM8PQ+ECFw8uujY2hhlzM/v7W+OJym3I0Bf0lgyt6aoo2/g+t8+//KmPfYq4kgz QL8HIMPNzorhYPO9ripQ03hAy4VTRt311ctiYXXZ7r4D/YzZ0qP1ReEzJ5ZGFbTs3e6DA5g21gFo LA6dPb46gsDO3sHlzf1pjT0O9OYfW1W8qC6qwdDrezrbEyQEeYQ4gREFXDCjGtCnBYWRxhYi9LzM 7Q7oikTSaAkJCQkJiSMbua0aJLgOna8yDTxEWRSSnQ0cvZC7FwFiwp0rl4NPTTyIXFXBia/knE0F sd8CJ5OG0FbB3UUNWeEVVhAFhxHU6PjM/YAcfN2o8MIFeYVtGlPpC5VSbaJjFKJsU0Hcj4GNMDNd ISxfmtVAZHWjs0GEjotlm9QUHQMNE13n1Vson2eVCKGK6D98AxxzHTANkzE2ZAjawMiExjwKj9dY VOm1pIn+UlPP/riOuNG7gKDTJxaPLywY0vQXmnqb+zNGL9rnhNqiuXVFg5r2/J6elkGdLxD0ExuK 51YV7mvtuepXT6xr6jK2MBpWE9czcNQB2oU1eVAGf34Uw7yBAbny2Am3/8dHFUV5fm9vUzxlCMx1 haGlY0tjIfTyvvj+/jRbPUHQUBg+c1xZCMJDg6lX9/dlCLtBtH1jaeSUxrIQ/RrZ4AjzZ4XyZqIw Ozkr1IIBL5yIDMmcfp8hStWf2Su90RISEhISEkcORhZANuxGQy8L94ZDA6dz2kmjbSHTlYnhju+w O9rcFwjKNHJZNTzBHTaTBs7thsKn2cY2kwZWrURufKa9dADDbx7oSWsoBLFm8GY2mptEMnc0tAzC jNbqCjSd1CriYXh8faLwjmJnJFwUnw8y6xpCE9j4BrFx/cSOnmDCOTOJKJg7sxWoh9UQq/XC/LaY UvAplUUNJeEV7UPbOhMqpgQPhlBkyejolNJoQievHuw90K9BY2gE51cXzq2JpbD+8v6+wwkds6sn i0aVzKwsaGrvveXu57Ye6lFVVQeUkSOFskO+ZnDhn5obHUTrA8wbUEMwDDS6kFDoSmQonWkfSBrW c6ion1k87Sc3nUubvdoUPxBPGZ742mj4lDGlRSp69WDf3r6EsTuwLlawdGyhipTWodRrB+IZYn59 jUXKksYy88tlXhhkuDjoOBpQFCOakH/X3GON6I2NUIYt1WgJCQkJCYmjF8PSaGAZPHL3Ev3TQGDJ rjbCvkPfgt4Cv0QuqzSbg+Jnks5SbU+yhyKc05VRLaZTQ5Nz8xBgiO7dcDiVwWEVcu3XGtPcZ5gd hGuZTDW2mK65e8wUbrn8TEymzgRdk0Ixx3T2RwC2VxAJGyiJ1cwEsi/HTKIwyDRCOzuTz27vGtR0 SqUzlMXr+r+f1Pi1JY1vNfdv6BhC3GgdgmBhQ8mcymgagtcO9O7uTXPdmk1mRlV0yehCDcOX9/bt 709xsZbMrSs6YVRMz2gHepKpVCqMmC7OApNJYN3v3L915MA/2lQNQwSnWbI3XUSoytq97f/2mydS vOQk/egHHz3+Py5ZROnu0zs7W4YyfD8paSiKnDK2hNLoZ/d1H4ynWLYGRnXFBWeOK6a35dDA0BtN Q4mMZnxZo4sLlo4pUhRFY455yIely7AQuz/0jaYDVeGCNNSM3BhCVPrm6T0y8E5CQkJCQuJIgb0F cDjLsv3BMD/WZ2moIZJCILomfMU/yyzht0nR1IZ99oFZvmdiq87WJWSFZ8UjZiNn+IbzRKyjwt3M ptILHNzdtnZYZ1HYrj56Dqwa9QsBVFQgUnP+wuDQ/AUyCtkQoqgsVZpl1kFWpC7ESCc2PhLGh+IN t80wMGs4MC6cpWFgqAPmTUZiGgZiJAyqnJ9v60h8/vGdrQOsbIphFbh4ds3/nDF2TevA+ra4phPW HyjzamInjy6ka4M3D/Vvah9kVcAVhZ5uTFnkgklllM6/vDe+rasfMR8LmVYePXtihXWZbFjK9jDi 9+qDTOTgLosAFXmkQwXkRpsLEXYt7Ca/snn/JT95NAMoCaZfHbrnM+dctHhaStOe2BPvHEwZ3+3E sshp40op0X5iV0/LYBrxbJQx5bGzxxfThcy7vYMrDw6m2BZDNv64ssLTxhYBbH/dyNChVayxnxeQ wmqzG7EeLICFHkQh6Y2WkJCQkJA4oiAmfuVTYM7XoTEshFon/jRamIO7HiH/C3M91llX3KLRIEso TTrO3yJRkLbaYEdMHsQ+qXlOHoycqR0GuybElIRDzOiKFJjREFKxQ1O3p2QQfbZ7ECi8EAn33bJK 2iqfv2Zoz5hVK1SMLYlGZRZbI3cMaLBtbA5OeI1DXvnbLijDk5oNydxg5uxKQX8qdcuTe7a0Jih1 U1mosbZoTOmvL5ywK669tLsnpWO+KTE0plj56PQqhYB1bYMrmuJ8YvSO6DXRgktmlBcg5a3m/tUt cYPuN8QKLp1eARSksEgWnlfNXmiszLlnFfbe1OQRP22B5VSC4D8vXuJRMWiupoD7Xn3nc79/2XgO J9aV//Hfzj52Yl2/Dh/e0j6Y0bm1Bs6riS5pLEli8Mi2zt6UZowzs7rgtMZSerfWdgyuPUh7GJPR 51QULRpXZjwv2Eh8Yd8hs9xA/pywh5M+HJrlyIdKUs9INVpCQkJCQuIIwohpdB6mDqG1aTzI3dH1 kUCFzY9sjRYJzDLrtbDfQk+Yhu3W8CPTotSdZb2e6oYGN3V+CgwKbloyWIofI7a8Vh8BljlEtJdY 2w3Nkn7mzBlbQph9xMRV41NF4SzKT5u3z8sGsWaCoTExU8/WgTUB/oJFVxOdvqVc7ydvND21tZPw kniYoEllyu8vnZ7IpB/b3tud0gFMQ6KWFYQunlldFUFNvYlndvX2Z3TjtIWqev60ijEl4V1dg8/s 6Ull2HqgOBS6YnZVaUGInixDGPFnxm+QoXT8g7NgGA9p0PjD1vf2dPAfCbM7hLjqzwb8/l9X/fSJ lYBX2zlz1qi7PndRSVG4qQ8/uaOF1XMkUEX4tHGls2uKWga0x9/tSGS42x3qJ48tPbauiGDllQN9 21oHdMQ0bnp3TmysnF0fM75x5i7SNa5Amxo75vs66V8K+wYJr72CBgaHKI2WarSEhISEhMSRgmAa PUI6gnztzY74DpMOCj/HQ6NGnkVhs68d7mdGKI2PkEhMXfv/stK15Tk221h7Ex3BHVkXB3Q1s3YQ WrYOg/W6NzhSLspUX8jKddN7yKIWuIUZQE0k8fYSwmD5xtQw020Bp84si5ttVDSujhE3aGzpE26m U4M3jitZjwqvkGLmMRNo1nlh+9Z4U0rJNYhUzK7ntT3dv1jRkmY5bOwGFkXV/1o6flZt7G/bu3Z3 DRn9wwidMalodl1JWtcf3tx7qH/IvqNLx5ccN7q4P60/uLmneyhFAIup/ui08skVUcPRAXklRe7o yD497wufzv9ZHDGNDgD7WpivAmYAk9Yv+/mjz2zab4jTX7nohO9dciJlt28fHFx+oMv4gaU4rF4w vbKuSN3eMfTCnm6iMTdMNAzPmVQ1vjyS0vXHt3c292UwDyAvUNCZk0rHVkaZIR2bv6jomFWvIXxV x+tj0qeFPRcYKWwmKtzaPQiXSTVaQkJCQkLiiEduZRqaMW7Ebkmgfy+7XIvNBXMFVBvmDatkoLMB l4e90nVWRXYm3Hk8ysYeQUcboQsSYjqARZeHl6U9KXgQuCNBrKEs4guzJNN1OscVOdlzVp533T2P x8Z1fxBXv+k06f8Saf1bz+9v7kkyfy4r1A0/Mbfu43Oq3moefHl3l050hBVK22bVFH50Rg2d8Kt7 elcc6sOMizOpe0pF4WXHVBCMnnq3Y2PLoHHPThhTfPqkCsNFYlZKhDoBwbGIAbN9v+iv/fOFOWxw Q+tFNj7EPQfMFGH6Pe/v7jv7+w81d8Xpw1lXVXj3p85eMnMspb9/3tx+sDfFt2CmJ1aWXDq9lFLe F/Z2bzyYoKspehNGFRZcNqc8Egof7k0s29ERz5iek8qYcvnM6nA4bC8dCdCt6SD2XbEgGLZQs3xQ MBJCvz7QJmm0hISEhITE0YHcTJrxJZuKmFpkri4uGu0qJ247JcSW3uQNi2I6BrQ0aSd/hQS6BufV wkWWaeSL+TJpQeH2ScEDIs9mpEeUw7mPRVDHkaB8m/MRxvEyaWNM4HSnOC5fvMnQxbYdYwJL42dC OWQpE09s63h4Y49CNB2qiq5Pry/62mmj+jPgnnUt8aSho6PSqHLprOrRxeHWgeQD77QPpLFRrLE0 pl48rWZ8WeTd7sSjm9tSuq5DMLYkduWxNbEQy1QGUEGYsIg4kp9D6ANG7pWgo6WHxBvmdF1nfu8H lm/8j3teTmcy9KG9cN6Uuz93figUaoprj246PJg2Nh2CpZMqFjQUJdL4gc2tbf1pxNzS+nGNZadN KKP3bvm+vjebenmaIVvXzK4vOXtyZZbxswWIufeU8HRqw9kPMeI2dyPfEH1uRzN8cvfg+3yTJCQk JCQkJD4wiGTO8AwIPhD3jjqQB33y0r6sedoTA2IyUWD7PZyxFY4BscO7DMzIOScZBaYLObsl0Tkg hFCwZVss36wcDq1LNt6J04ZO2g2E8jFWY28ZRc9lCunU4v0UybT3Pnvvm4tGsz95MrECcOeQ9ovX D7UPZABL9kDhEPz0wsZj6mNP7+hadbCPzQErRNFObCw+Z3INUPSHN3ZvbRnUuNiMgHby2IrTppUg Tf3TxrY9HXECQ7EQuHhmxfSaEh5abdrTXRXj/ynIx+cPglVw22KexuSaXzz29Ia99G00Grrjk0sv WjIbY/z0tp71h+NGNceaWJiuJYqiaFtr8untvRmd1SosiMCrZlfXlRb0pvBjW9oO9mkhwn4CCCNy 6Yy6cVUFWcmc6c/WfwVsh6aGkQqZL8S0PyGE+ocSV6+VarSEhISEhMTRgGwVj+CtgUbD/JoBrzbs 38ygwpxTOBORgWWf8PJRh1ztMEh4mLTdWIiUdm9qhM4NjoDHdwhnJOKnrsoswGLSyH1G9zjWuRxm EvvaXR2FS/CxSruYtOMOE6RAoguscuXe3kc2dbASMHxv4oKG6BVzG+LJ1G/XtAwawjPAZVF0+Zya sRWxg73Ju9a2pthGQ7aNsqJQvWZeTV1xaFdH6k/vdJAMy6OYM6r0stlVqsILZrMTYVbsZeQZG+8L 8j4rDCLQ1u8khMcIgte2Nl37q2U9Q2n65Z46ve6hL10aKlBb45kHN3R2D6WYAA/x0knFJ0+s0DLg ka1d2w7HeVFJZUZN5GNzaulQbzUNvPRuGwaUF6u08biKgivnjTKy1TFAWTJNjBUI1FlOC3N0EL5P FBMUCqEXWzo+92IXfFyq0RISEhISEkcD7J2AIi0Tycew1Nnu5NvY6dnwGRM5GbP42puLZynTlhgs irjQEFOhuJ3RZtL2W9GbEWBxzp7UG4THm2JbPhfdHXYv40SO6BJIXEVhgGjwcFqfrYUEAG7ntPCp S9HnNJrNEWFD3Uxj/NCGtu3tCXaNlKqFlCuPrZ1TE3t1d+9Tu7pZVjFBGkLHNRRdOrsqoqBlO9pf 29OPgI6BgiFaOqHkgqnldGaPbWxfebCfDlIYCl85v3pKVdS4vTqvmh1EZ0cqUn8QZDy3DdvcrMlv cFLL3HjbU0+v3U0XHYWR8P23XLB09oQM1Jdt6XrrwCBfBGXqy2I3LKyPQrCrPfXQlha65KCriIgK rz2+bnRxQW9Cv399W8tAmpmO+P7Cq+Y3jK8M82QVnsJhPZPWPWNuJMx2NyrMwE6fIqKEIPn6vsP3 LOuVNFpCQkJCQuKogS+TdsFVwjsHvDYG4DGBuE4kqrOeBtgrM3vF6WxWBjLlbZG+K+6kZ0cWHndL Iyc1Nz2sBnGHFpl2GDwshRsKlmgIHFNFLjOJuwSjYCmB7rWElXXtV63GlvyRPWdkblNTrPQ7gtoG 0n/Z2NabooxRUzCqKAldP7c2ikK/eat5b0/CGITO8GNzaxePKR1K63esPryvL6Xy/Z+FIXjDvLpx tdH+pPablS2HB3AYp2c0lFx9bHU0xErJYARVXcc8Vs+Lfx6NzmXhsKELv67Qb/LB1Vv+4w8vJdIZ HYGbTpvzs+vOpiNs7xy4f22Hpqd1EI4gcvX86qlVxWmd3LehZWdXkrAEbuWUiSXnTSvFRHl+e9dr +/v4laj0i1gwqvDi2dWEBSNiF4E2vFKEb9PklV8UVrIdgTBUOgcHrlh9eMs7SfjYLmnqkJCQkJCQ ODoQFPlsBAsYx/Ok0cIgDnHa2MInNAuYgLOYX7ZBQNVA66Bp1c0eQXZHpzEDCVsJicPUYafsQY9b 2vrUGd8BgDPBw+GWDpSlPeXH7TG91y76W8TLEWFyepaNpytAwYa6TzSshBUdb2tPPLOrWwNQp1QN gWNGRc+bVHWwT7tjxf6eNEI8baMshD69qKGxIrK/I/H7NYcHMzojeVidUhf+1MLRMRXubE/e/dah fk0PKejjxzLODYwaIgR5Hpl/GPx/OckNtpPP2Zjy3F1tA1f/6tGtB3sVos8cV/Xk1z5RXhTpSeM/ rDzcFmc52wiD06aWnje9BmDy2r6+Z7a26zz3cExpwfUnjI4pyub2/kc2HKa3ja4qVKCXFkVvWlhf VhDSEXe+8O+IGLCmzU3SiOUtmmVZoKKgP+9v+f4LHQMZImm0hISEhITEUQNfGu2wTbPadc4uwaM5 7RnWCzeNhqIEOSyNhlYih0OvdZyICPTXNHgAwW1s2TAEb7TgGBG1ZIPzKKaFJBuEBwS3tEuWzsGk RV5unwU4jdf2TRAleWGeILvnkni+Jpi9b6wlQYynM36mcGquv92SWHkgrlMyiHUVqkvGF82rLVnV 1P/n9YexjngVFWVMefRzixuKC9CK/fEH3mkFGq+aSMDp00svm10NiPLG3r6HNrTpBJdHQzcvHtNY HvpgjBj5Iy/VWYSLQ/M7jXqT6S/98blHV+yi96e6JPrA588/bsrYtJZ5ZGPHmgP9RjTN7FFFVy6o LkDhvZ2Dd61pGUqzRUZxJHTDcaPGVoZa4tpdq5t6htjahd6zKASXH1c/rabA5Xnhr/n3Y4Z1sGhC dhmYaAjRhy2T1q9du+/NFQOoGEkaLSEhISEhcfTBnUwnwMpkcBQLtJHDS229deS3CTsR3XMQpdms guug4AIZcjqqjTg8s4Kg1Qxaxb25MMz4v61JeyspWozZcj87FWvXvkMxvQ4Cr41b8FgT93ZGMXJZ vGOORDzgvg/ihB03zeERF7owr3RmXVvi7dYhFsSmIAVqpzVWTikveObd7kc3thl5JhjAY+qLP7Wo PqrA57Z1/21ru5FnFwbk8uPqThlXSod/ekfXE5s76BiTRxV99rj6kqiCiSXtczkcY8IeDMxE6vfX pGFgRKRZB2YBSLOiu86sQYYFhS6lmKkDKljTf7Zs1f88vlrBIBJGt9141gWLZyi6/vyO+JPbO1hN FEKm1cQ+edyo0qjSPajf+Vbrgd4hhHFIUa+eXzN3dFlvIvnHNe27uhKIaKzsO9Yvnttw0vgyQjR+ ZxRCLC9H9hLYE6hBts7hpSkzOkBRFS070PnVV9t74xkFShotISEhISFx1MJV6wM7CJ8luDq7+Fo+ nGzPQaNBlsX6bEy0PRgBjmHPQdFI7SS4wHIkiwQXOGRpAgSaLsjSLguHGBSdnadDZkYOydy7f9E4 nct84q1B482Wtt/aWw9dXczXgtvEbM/0VIXoeH3X4KZ2SgEJREhB4KTRpY0lkWe3dTy6qZMAHXHx +rgxsRtOGB1W0JNb2p/e1EW5tQZgoQqvX1g/f2wxnfZTO9r/tqlX07STJ5RcvaA+HFJ4eXRKSOm3 SEk0AmzPHB2OHnnvRNpJl0fmGtGBaWq3h+I3E2msuIzOTChsB6YC6B3B+LcvvfPtvyyHBNM2P77y lJvOOE6DePme3gfWt7NmJDOluvTq40fVFKH+JL5vXcs7zQP0K1YU5bJZNSdPLO9L4bvXHtrVEg8R lKFLSwWcN73srGk1kDN4zXRuOK6Ie7LZfyUqgRnahKisNCYCqVTmpg1Nr73RBwrptwUkjZaQkJCQ kPgQwr8UuBNev4fLwmEccx0XOKLdxRrQ7XZwl1wRzBJZ0dcoR2Lq0BYnFhPljCOK8FY0UotMGjgT PKAgsXsMG6LqnGXeJNjp4alqLlhQPAsJaDlVxEtw321HQgjmk2R1zjd3DK07nEhqGcrewiF4amPh uPLC13f23Le+I8WCO1jExHENJZRJV4QoY+5+aGt7IoNUki6Kqp8+rmHB6FIMyUs7Ox99pzuukaWT Sj55bF00DFnaNGXckFmyGWNnUSGOOEIRf2e2R+58RrOICeZl0pkMTEk9IJa5gt9k5lWhXDaja3e8 uOUHD72S0kEsrHz/0lNuPHcexvDVA50PrG3VMvSBUWbWha9b0FhZpCZS2h/Xta9t6qOjRFX4sdnV p06q7Eom73yr/d2OfqirRMGFiJw3ver0adUKizpBog0aCDsaiRXGzsqNM92eraoKwuDJgx1fe6G5 Nw4UlTDDtKTREhISEhISRz7sGit5/wzvr4O6sp+9sNhq1rzsmIVbb87CFo+dZ7SDMhBwib7QkewB bHEXZv0YUBCYjSPi+Mhp1bB7Iaehgh2xlgFZMm1HZzhrgzsdI0AwjdjT5uM4ndzWrfM3zLiiPAKd HlyRBpTfIrSnN7nyQG/XkE4JXIECFo8umltftK5l6A9rWjsHEgorB05mVZdcf0JtY2lk9d7+eze2 dAykKFMsicEbFtQtGV9KSd7qg4kH1jc3D2mnjqu8bl5NLKIq7J5DwDNSmKEmSxf/ERBNz4L6iwgz qxC28xKyxAwIVAxZCcZEInXrM2//vydW6QTURsPfv/r0S5fMABn4/N7Oh9e3pTG9B2jJhNIr5tUX hmBPMnPf2y1rmlkAXU1UueyYUSeMLdzbmf7ThuZ9XSkejwLLCshFs+nNKQf/n707D7LkOOw7n1n1 umcacwIzgwFAXAOCIAASJAEeIilKFHVQhy2Z0so67JUlrxXyWvaG1xGrfxz7x8bu2pa94SN2FaGV LMmWRVESLXlNHTRFSqJkmzJFgiRAEAQBEPc190zPTE9fryr35VmZWVWvOwcDAiS/HzIG/d6rV/er +lVWVqZqp7Ke6CcJZtckuh2OtuuB3F1NuToeplPD2VZYqOrlixs/9amnPvnps+KKiV2F8ncepcE7 AAC+WvVbhOgZTW9z+Jw6/L4Rt6RhP+tV4RjqZiXvxdDUr0gHi/o17PVyYpJ0VIQc9QEuopJy+59a JEnXFE6LJBZHXavEkT3E6Cxez+9KJp7PKl9d4WU7WJav62erSVuJBTVt9bWMPHlx7b88ee7hk2tT JRZk+4Zrdn/zkX3n16Y/94nn7z+2siAmsppev2/px+45/Jbr9z5+auVXPnP0oWMXp0LuqeUP33P1 995+aDbaZ86s/fJnn/38cxfvedXST77t5lftnei2K4ROjbpHlq4y8OXkWnqeW0Na53lbFlzJtvFb UFfXngg1Fao+fmbln/zH//qrf/r5Sk1uu37f//nXvuNb77z+fDv9vfuXf+ehF6p2Yd9S/T13XPWX 77xqtrKePbv2q5994QvPr80uQo4c2vXjd1/76kM7P/nU2d+6/+iJC5t67arq1QeXfuBNB+86vFtP 1LS50TTNbCW2rWgq281NN9u+hrQ05dF6RieV/Jdfeur/+dhpZbugnK3DjU1iNAAAX922Uz4dl+lu a5zhAbuhN41+M3npMCbX5s/hpVGyK9CVyTvCR/Ch9pt9oXIyWt+8dBUXFdtEW5nZiEJ/VEdF+qck o/LvtjekfaceKJn28xD3Ebid8um0yoddUt0Mm6rqqhWmWHoye3+W8+47euHPn1g+dXGzmtQ37Z58 +2uuunbf4ge/cPKD951oN9t2Ue1enPzg6w794F0HVzbU73z+xB986fT6xnQ6Ud93++G/dvehPQuT lab9/S+c+K37ThzaLX/q7Te+7frddrqNLqTXgVVcEmXKjYOx/sZHw7SsTYvOYZVW01merWcBd5aj 5V88+tz/9tt//omHn5PN5ve96cZ/+CPfcet1+58/P/13nz7658+dnTTNnYf3/tU3Hbrr8BVCTD75 3PJvfOb4U+dX67b6ttv2/+jdV+9cqH/ngeP/6cFTq5u6bki1IL71loPfd/uVB3cv6brQup6GrjUi TPuMm62+WRHX0lZmn/Gl0bre9GI1efLkqb/+R88+88yq3Kl0FXMpmpUpMRoAgK96WyZpnQ/l/CGz hw+TUtXBEYZqx0IMxWj7Uje6O/BRVmxsVV32TXs9NEW/Ubl7N29RzYq2Sh/4y+pdZL0eDnQhHpVM 96thyDBmM8/9hdoyTI/dDYhKwU3PMrqCg+uSWhfVt5Oj51c/8fS5zzyz3Ci1d0f9jhuv+sabdj99 fvPffvr5zzx9QdWTiWzefuO+H7vn6iNX7brv+eUP3n/6s0fPzFbAm67fM3vzzqt3zZb9gRfW3/+5 5z939ML77rjqb7z1VXsW5FTq5+aay1QaXdQ6h3DPFOrGsxvV1pWulSyqelOKdrrxCx+9///9w3uP Ll+4amny9//KO//me+7ZuTj5z0+e/fV7Tzx77vyexYX3vf7q99x6YLZYF6ftv7//6Ee+ePr8ZnPk qit++J5Db79h98NHV99/34kHXziv21yZyFsPLr3v9kNvuXnfQttM64lsG12NY3YRoZuyq3QLHLMr pzasBRegVbSvqUm7enHzpz752Cc/e17MAvVsHnV9mFad2ZS//TB1owEAeMWT88qSL1OMzlv16BX6 arYQUie8OOZG7eKFB8XCv4O9iPeal27Tnrq7r6TN1al4gDqaSj+ax7lcRL0eiqhMOnya1ABJGpm2 w7fZ/Fe91qxNv9HDFTmq3uJnldSlLgKtGjnVcVLpmi4m5ZmeG2exb7r55dMb//XxM/cfXatle+P+ he+87cDNB3Z96unTv/ypEy+c26grtX/Pjh+4c/8PvOHgxrr4s8fOf+Bzx46vrh9YWvj+uw794J1X LSxWy6vtx584+x/uO7a0MPnrb772W47sa0yr02LIWCwOw5fm5uxbunEMvVYqXRquZpFebMjJfQ8/ 9i8+fN+f3P/ERtN+/903/8yPvve2w7vPrKlf/9yxjz1ydnNz8923HPj+1x96zaHF2Yp54IULH7zv xGdfOD+R4kffcM23vXbf0sLib3/+2EcfPXd+da2V9YEr6u+9/dA33bLn0K7FDdFOdAvQlWyVvXKY 7QyNrXzSTqVYCEFa2R3YXMmY/W2Wu8U/fvipX/ujU0pOK3OVYxZAqWdWiNEAAHwdybryHh6mN0hc 5tpredrWUU6GjAuqB55E9JcEWeXp0Fth947+b9qFYddUnIra63AjjFN1FZcNV92cpNG8jUqak0Xo sntSUcQOYN7prZk4WIuoBDrN1t3lUJ0ubLLg3ROeU9Ntte7KcaORDx5f+dPHTj10bGVxobrzwK7v vvPgVVfIP3p85TfvP3rs/CxMy1uv3PETb3nVu27edfJi8+GHz3zwvufWpvK2Q7v+h7de/bbrr5xF x9n7H3noxJ88sXzjvqUfeePB2w/v0RV/VWOKwSu9DLrJjDapoSFNxQ/VuFeituW1es2k7eW5QtzG 1qXRS6rqWRDV7XH4yhL2Yb/WVIDXRbo6lVbq2VMXfuEj937gv37h7MX1u286+DP/3bu/6fabr1hQ H3ro7AfuO356Zf3u65b+6huvef3h3YtVderC5gcfOPaRx85sbqj33n7l991x9U17J3/8xPJvfv74 06fXZitr764d3/Oave96zeEbds/2kno2gardnM3MpqztNlJxnQ27VUyLHDpDt9IUUevHHtvJVDST 33vq6P/+0adWLkzbid2DTCl+0+7baOUHH6ZSBwAAX/W2WSAtS2pICx/pxsosjbz6Rzpw10lh8pEc rrzR1XJOKkvE3aPENaqzmO6Kz+OaHl3Vjl6S9mOLHiKMipNl3Jd4HqaT+tPRUrdDT1V2ib+/fnRY TxucjtesbgxO6J7AddlnXc8C3qQRF5vqS8fO/skj5754crVpmruv3/Vddxy+aof80yeW/+CLx584 s9G27T3X7/9bbzv86gOLK9PJh+4/+gePnFqbqnfcsPfH33zNzQd31kIdOz/9/YdO3PvMym0Hd3zP 6w/dsHfxisUFpWtYyIl+ANFvTGl7yWntbQmlV+fU3aLQFVsaYZ/MqyrdoIWOyW0btypjk7Qfm7Jd Lra6pH0WaFs9bHts+cJvf+LRn//De89euHjL4QP/03ff/b1vf93so889d/H995148vTF2w/v/OG7 DrzthqtmYfzsyupHHlv+Dw8cXZ/Ws8X5/jfsv2b3zs8fXfnA50588dhKLdV1+5e+/Za977n14LW7 F90jjPoZRp2NbUT2q1bPki1Xtnlaz7beSptSLJoZa5SsFuqFe5974X/8yBPnTgixs9Hz3swWvtHP gJ6fft+37SVGAwDwNSUE1qzYOJS7JQNHA2w95qFaHL3vuojZezYxqh/cqi7aqmrwYUTXoFiXmFvZ S6jm6UDlh09KpuNiaTO3bTKqvEpJG4dme6s/LgKPw256XdFGX+neNH/XWaoWUaWUoRU+3OukWS79 z1Q1tY7jtbA5tW0ePrXx8cdO3f/s+bOrzRuu3/feW/dcu3fng0fXP/ro8QdPXjx9fuPtN175w3cf ft3VO4SsP/zQyd//4qmz66vfesuB77398M1XLu5YrJbXp7/7xVMPPL96/d7JO27ec/OVVxzavWDD rrQ1LvTstK4sWW/Dyq5nG0Cl6YPbDOOaf3brtrVvCt2gRavb75vFfb28lS7GNkOqjbZ5/tS5D937 2K/84afOrG7cc+Twj7/njd/55tsublQPHj37oYfOPXLmwj1XL33vXYfuObx3ltafO7f+50+f+U9f Ore2Mf3GW/Z+520HD+yYfOa5i//+gRceOn5x39LCqw/sfPeth77xhqUDVyyYlj90sbp9hlCYKK+f YJTVNN7/VdVESVq3Az27iGh0VK4rNZH1wydO//QfP/HMs+vtznaWq3Xhu95fddt84mjzKz95EzEa AICvI4O1C4ykYnRUqWC4vbx+ualIc2QQN0TdH0lXqbrqmqjLRpX1XFhFtThC5o5Tr/RlzDKp2533 2zJQATp9dlD6mh5htkOe7sqz08cK+5clobJH9mZof7q/WuJa6bNIJ33H6bW+5DDdeesW26amE5X2 1Nr0k0+f/y+PnX92efW6fTvfedPeWW5enVaz0PkXT51/6tT6TQcW3nvble88cuUNexf+25MX/tOX l589vfLaQ0vvOrL/jkM7D+/eOUubf/TlU597bm2xVjdfuTT76NDexQNLlS1pNhczoTUPVx9DR2Hp S51bpfvzE3VTuYrF0nfu3dquChvdRnOjdESdDXxiZfWhZ0783qcf++i9X5zl3e/8hje+7223venI wWPnp5977ty9z104v7Ixuyr4S7cfuHaPPLcuv3zi3CefW33o+IVdk8m7btp396t2n99s/uyp03/4 pVNHz23eemD3m2/c9Y4b9r3x8B5dVF7VEzGdmhzvy8KFbRPazI99hLCyzYzE15m2e0d38VnNLgSq J4+d+nsfffLJ51flQqvnXer+amzD3rNorpbFZ/7BG4jRAAB8PepF3uE2OfqVQOLAGj9N6D5VA2E6 Cp0iS4xxWbJ/q+s4MC707XcfGFf2EC40D9RI9r2I+2oevUomVa/vlSz42lLkNBn7mUm6cRnr/DxN 3v2KH2EGeqnaNCHS6CgrJqYHm43ZhKaVnmXdBWBXnN8+fPzCXzyz+vnnV5pqeseh3XceumLPjoUT K+uffn71kaMXKlHddd2Ot1y/+/XX7Dm3uvnnT557+Mz67h3itit33Xpw6c5rds/G8NjJ1S+dXJ3F 2VmevmbPjkO7F6/ft+OqXYtVq8uSWzelbt76W98H01Ae7x9cbdVa2z749AufffzEf3vo6SeOnjq4 74rvuvuOb7nrpr27l549s/bI6fUnTq3tXJi88bod77r5qtkXHj2x+siZtWdOri+vT6/atXDXdbsO 76yfPLv2iWcvfum58/VE3nV419tv2nfXtTtn8Vrpes+zWZzOrtk2xURXgzEPAZr1tmBubDQ2Itsa JnEhtLWpO31RtvWSWRR/5Oipv/snTz775AW1VOtnP9vGjGw6aavpbOSr1atvXPzYj95NjAYA4OvU dipyJGl4/FtZ1QXhEuFwrd8sTEchOw/TogudrkS2yourXZ5OC4yHH++L83RSzcNOPa2nIaLC6RB2 0xodZnJpY3ZR3E8el4zydBXPTO0LSrsxhGrJfjyzXCdnIzDlqmYw1xzeRNcuqFvZmBrJE1ObQm2o 5qGjFx85uXH0wsVatof27rpul1ysq1MXN588vXF6daqkePWBpdccWtq3sHBqbeP4ufb8xvqOiTq8 d8eRq3Zdv2dxoxGPnFo9fm7l/Np0quqlxerw7sVDV1SHdu3cueAqdejZSUOz+Y99gtBsMtcAs1jZ WHv06JkvPnPi8WdPnriwvmNp163X7n/jkauPHNi/JuVz5zZOLK/OZv7KnfI1h3bOJnFsZf3ZsxvP nVq9KHQHM1deIXYv7mjU9KkzGy+cXd1U8urdk9sP7b7t0O59S7UuHQ7NPEtT86V1QV8X1QtTtKw/ V6ayc7dWuwZDRPhjQbabQpeabz549NTP/MnTzz17TuzcWYu2mc5WczPbF/TljJ7MhjrZ/KMfvfHv fsNr5W996YIAAABff9JAPPboYdeSdLVVgI7fnB+j/Tsq+0oytoHHEId7AhciaZDOlOBGHyV5Oqm6 3TWNlz4CGHUt7gbIq253udkvlO/QO5mrXmfmvVofUT/nI21v257MlfRXJlWt28AzD7qZh//0V6Xu +a+yDeVVle7KZNqq55Y3T164eGFTJ8krJvXOHdUOKdZVvby6uryqFurqqqXJ7qXqioWqmcqLm83a tFlarA/srPfv3LFn5+Ti+vTU6vryVJ5Z3VjbbGd5csfC4hUL4qqlxauvmOzeUZv+/PQzfJXQfwtT vdj8K8+uTJ88ceb508unzq1d3Fi/Ys/+A/v33LB/1w37Fxcm1dqGOLXetG1bVZP9O8SunbJpFs6s bJ5ZX1+f6rY9Znl9tlSzpViftrMLgNkI9+6YXLVUvWr/0oKsTZsiyvZ9aB+LlHLBlj6ba4zGbLVZ 6G2Fe3ZQf6cRppKJclu06+vbtr43C9uL9dpa+7tPPP8v/uzZ86fWqh3CdAM+G2BSq9l/Zyt8IsSm HvrM5qd+5m1vffUhYjQAAF+DsmaJx0TDDD96qKIYHZdGq2gw6R9nNOklruAxVCfYiJr1SGZmsEGP oXzZ9ipMJxUzQpJOJ9ovb7Yte3Tf7aJ891DjwDyEQNzNaTZM3jl5N+cy2TBttpni/sbtFxvTKIaJ qsIE5dYUQZtn3UzNaaE3h+4/vDYRstYJWy+8nCW/yjTw4crRm1metP+apuZkW6vaVhg29UNs7WHh GqWrbHPX8Y5ka0lEdSG6fcO+9FlfmFCry9DNDQQzamnrSetGP1rbroewTZGYiteymZoNJNuQbvVV wSxqm1J2XTHZtZFn6mebNje6rlJ8v4yzqU7Niqlt++ZJjWfTJXgrmrAscafli4uLZ89f+NXHj/6b P352erFVO2ajXRBqozJdtOhKHaYudT2boYvNG1+/50M/+OYbD+yRv/EwMRoAgK9l22gqepsl0/O/ tXW7H9VIOxU28o72d5iWakelzlEJdNrMs0gysap81u+VT6v4W3Frel38ldljjirMajI2OyeueDhM q3tYsDdXIsvQ0tfeFtGVSZ0Wk4vB+uiVe7DPvB9PzURSmayfF22gMr1dWB+vu6usTFwALKLFaaMu e/ynPiLnX69U9Ghg/Lm5Bqii91298Wmjy7yFLktudZVoszp0ab5+3nH256QyT0Y+c/zsP3/wmY9/ +oSO4IvTSTOZVo3eH3SS132zS7Fp5148f+Hf/p03/chbb1lcWJQf+NL5S16RAADglS+O0VsWUW+n DNsYqbAx0D9LMvJQ2aP/kUgayqiSKh/KB+ioleW0okUbButGLrNWqFXWm2BWPt2v7NHl6UrFL8NE q3SKuvDVBf0k7LrlkklBuHBVdV2N52y1xGX/3sCyZwY239yuyC8X1bvy6ndzGJf+ii40V/GbKv96 ZZvOsP28KDkcnZM3zTCN0tl5qu+myEpXzVBtNaka1ZgGoU2zdY2QC5O6Obe29skXTv7sHz1z8vlz YteC0pWqG92/o1oUakOvPtO+oDRdLaqm3t+u/9nf/+a7jhzSi/CBh3jEEACAr32+8HBbJc2qSvPf VqLwNxyv89A89BxePFivM5ekEnMocu4X1pqkG81D1Gl5XPfadf1d5e/LKHRW6RwmGTpN1TJq3COZ k+5llmUHugcPf6clx2ll62744Q3Tj8tpmyedfql2kSwlt73RDPUW7h6ONBUsssRcZd9VaeZOxqmq qLk6PVybZmvzto7YjQibu250HZhp20z0k6PtZrW4NG02Hj+x/OtPv/Af//QFHZh3zLZ1bdqb1nVe ZrnZNUsiZ6G6rdWknW2L0xs/+b6b//F77jq4Z8dsAYjRAAB8/cpauTPFoQNFxeXVQuzI+yWjeW4W STzN61JX6Uvh6yLHNZhFv15yNPWkk0I/fFyv2qXMqCJ1VELcfTFKvW4MgyOMRpsvaeWydTKY6Fdl 6T2kmC2Xf5lskqGnP+e2Cz5SJ36b4qoXQ+PJS4jFQDFzMpiKZj9kZRHVYM5G6LuDkdn7ITfr6tO1 aY5Fz1ljK43rL7UTudhIUZ84deGPj5/6hT97evnZi+2+erYZ6ql+dHGWt1Xb6McYdV0O3YienRep C6ObanX9Iz/99m9//RG3rX79i9SNBgDg61GczLIaq9FALh6FQs341vxY4xIDWbn37GB/yJCn7ZNs 8adz8rR7PxphVv7q27nr6kYL/0hinpVVP08ngdV3JZPXyU4yfd4sdNdHY6j7GxVUD6w00zvjcDl9 VgbdT8NVmq/Hipq3UQg9r+WWfklz/zprKGrntS/yUakqNJ3Rn4puvK43njC8sk9R+urXtp+UWXRu hNmX2roVqq7VRE5OnDt374nzv/HAU/c9sKzrWu9c0F0t6mrTdWOa5daV7lVbNQtKNrpPx7bSTQrO Zunc+rvfdvWv/+Dbr7typ6loQmk0AABfi1QvJsUt5r7IW/xZHeXYWBWC/OvuD/dwWn9o6VtyGCy9 Fl3xsEqG7006a6jO1vdIYu42yqf9nMzL08In7xCp48ok8USr+NHGrqpGfhmTlVULkTw9GUdMO/Mq uq4QA5sgbYnlRVSVHqqtIUJcTh83jL4lh8K3jsbVdsqbwzhbu1Z6TxmGeiCWVNVUj1s/JjjL0AsT 3TzImfOr95888+Enj37sU6fk+lRdUen+vXVlDdMqty6rVq6TFtOLuG7VROwQ7XSWo3V/5mea3/rb b/3Lb79pqVpw1T3e/xCl0QAAfD2Kyy1DrsqyzmjeGonRY18ZeyQuGt4XJ9s82kUx33q0kP2sL7uH ApNxVr1eu9OKH6EybtQfeNIfYTxjqk6nKEwcz/Ku8F2xZG9K3570WKqOeyDPv1vlxc+it3qzuwTV eCWNFxOdx/SeF3RaOy9+9uK6Gf3v6oTd5h/Fw4eAHNcAiet+CB+joxY/9OavVbuwsGN9Y3rqwrn7 zpz72NPHP/7nx9Xahty9oOpabm6Ymh5m59FdfFetaYe6qipdGq1MN4iqqauqaVuxunHHrft/7ye+ +Zarr5BqQowGAODr3ciDatEAVRKrQ7ZRvXfcy6GstmVN61D5IZ7QnNrAVe/JQv9+nqcHS6l7FT/y AumQevu9c8u8y/G8QNo/mFgL90cozE6qPouo3ogYX9h+tRk/HiXEnLJn/13puiCpCzN0K6rB93VM VwP1NAZTctSMtB/SP7oacnMoaU7LpJPW9KK5ioqr264MPnyr8QPXplfHiysbzyyf+9zZ5T99+PRn HjgmpkosTdTEFVLP/iObqlbN1Iy2ck1W64aldbzWrW+bkmkp6mbanN78tZ9+6498w20T0/e4q5Pz a18sa/BusKDet2+TXr/ai4TLeuUTT31kToBRyY9Z5u/ElBw+fIzVFdvyPNQbf9nwL72y5X3phx8W 1vMrbwV+nbg82/Gld3l+v5drN3vRx4esh4uX1ujcVtls9VNTb1Rz8/RIkhZj7eh1VbRtbx12HqTM ZjgcvOO6yF0A7T04GA8ctzeX1G+2TUqPLUh0DRCP3M5Y2hxHm+dmmUxxeMF1+2vK94XuLzZ0NZhk jrpHDPt1YNx/x6pMv5go1Y3HNlttKmmk1wNCxdU5Wrs6TQmwqbWs+zOx7dkp0/+i7WnF5VQblF16 nn2ge4vx3RfqnlxMM9Jto2pTd1l/a0HOUu7k4tramZWLjy2f+/Sx5d+774XlZy+KRSF27JSq6WZY NTKq4q8nPxv5VOqKHUKXTJu50FWide81Kytvueva/+/Hvun6g3vMwrZ2/RfHaHfLICu2N+9Fc7at npMumR05GRoAXnnGntzH9uUtHnxlzIn72TldhYAzNNicRqPj96vuXnyTleb2Bs6vLJJgmleQsNU/ ormthqtrZ70eijRMi166nSW8bgai0mKZ5tm8LkfyMGKv+sr4c5nSFyRXJjIPRe3hDVbLZNvMaWLF Ta70etFPdyyG6alH43S9ElZS2UDddhU5zNCmBkVri8xn79X6kT5bNNtGFXv0WCrdG2Pry/j1cJXL u3rL1ZOqWl3fPHP+/PMXV+87tfyp58/fe/8LYqWVS7WY1Lr16GnbVr7GdZSebS/ile4/UekWo5V9 X0rT6J2+Ppjl9gvth//nb/que25p3SOWjb3bUByjkzUpfWvYurdyM2tppaXLW2DcTa674qJA+pJ9 bZYqvfTjebnG/7XqlbZ9v3KRJfVS74cv9XS/2n1VHB+qr/D22rKQvv8Em79bP7K8vprEWOMe3YDJ +6a8duhNMZBZB0ZV5Q02DzSWZ9+Pam8n78cP8GVVrrPpRn/riaY1qlW/AoZMuhzsNZBnC2R9UbQJ lZVwj2S2Y70S6mfmhlZ1V5KdraLCw0a/m5Vuft1i5AnbzJJ7xNA2mtL6yh7KdM3ts3Jtu1ORqpll a9OFiqxtfQ8z9kZs1qKeCnulpNfHxKyP86tr51bWjl5c//zpk/c+f/FTXzihzm9UC1W7qOO1vo4S uivC2ZVbW00rM/8ur4bK1soWeZus3izOcn1T6R4P66ZtFyp5bPUHvvvmn/vBdxzes2SKyaMLqn/3 YFndaFsHqBXdJYK7aLANjbz0uTZcd7Yv6jbEV6vLd/PxpT4cX6448nLN59CxZt7uTYy+NMPrTY4c p8f388tTyeTlu9P10sa17LgRrcayDp8v35p5pcX9l+syrLQS1OVStlxjcW2gJRA75rEYbYcZaXbD T2vwK/mOl6Tnyhfnya4WRxgmq/Ux+Aig+XugknGI2nnzef2HC3ttfcRzGxrRy2uY5BE8rzoSkrpt /s/VRXRZq5Gmt8ShFRaNNq6H3W2XJK+P1SAYO952lets19zDQ7kBTDm6Mi3V6VjsNpaeg0q27rpC B9yqMqFO12y214u2UvUsQ8/emQ0w0QNUtrZ5PQvPjTizduHi+ubJlY2nLi4/fnrl08+e/9Kjp8VF JSdKzdJzXesCa2ma4NBly42+naBMgbepUt09vRqKg2chu9ZdrsjpRFWbphK4UrUUqxvX7Fz40D/4 trfeek20GhthS6NLY3Tja4Jn/4oQ7XvvXB5VN9p4E26n9sh2bjC9FC7jdAfXZPYzKBrh9udnsAmk uIZ60XQHR7L98c+frtkfxg7fA+tnzv6znYaftrN9x7bLS7E+x8zfN4qmOGc+L+NULsv8ZAPMn4ct 97cxpcu1nd/pZVxX2z9uDC749vf/sfFv57tfyWPy5ZqH0h/seMMXY18fXrcvZrpF2+WSN4qvUHF5 YnoyM0MdgEcDpA/t9b/uuFJklyLiBpbjngvTPN1VKdE9cCQBut9tYfetMBLb2WGvsFwvRdbmXRql 7AyHleOymy+yrPzijCzpgIGHEeXAZY/0Czz6G0/f3rJMU9e66C4QWnvPom6rqWvcWdplCmNuVLsg TFHwLDbbja9rPquLG9OLF9cubGyc2dh49tyFR1cuPnly7QuPn7nwwvpsTNUOKSaNqhZ1DpgtV9MK OW1NDWzTZsfELNJ6K3cKtWnnRLbdnOt60WIW2VtXx1tOdYKWqt5sp6vTf/U33vq3vvl1u3fWelGk XWpXQ1/+my8UVurQxexuuyqhe3mxWcTUE5fuamNgV3ixbAm/vgtg5vzluvP6shs7HLcjg/U6U3Xa kYaKwoOyA/1aDZHzLkQHfoRj8Ws0VvpHSfJRjTe0NEjfyum/+dVTVlya87aMlZcwnpck+vS2o0ob MNrm/PSHvrzHn8H9RClV+uT79sd/aZdw9vZo3+j+0Kvdup3pDg0js+S3zQv7LTdQf4ovZj98pVUh GjuO6ePe0Eej231kbY+1oTb6bGD0u1Oqe6EKw/HYdulPN2kReaiUOv2ZJ3k6LceVNgbFTeb1x5wF 7n6/g+bNgZ3cJe/epIdjt34Z1fqw/3ajGry4NfPj02QWVG35UH72H6jEMtwBZPist98O1892n8nR cmY1eluwzRr3cPWPu8bvWpu5K1HrasiTKq7IEHrbUbJWm9P1Zrq2sT7daM+tT4+urp+Zbp5YufDY mfNPHF195tj6xtlVMW3EpFaLlZxIU/N6s61NZWYdoGtd3VnfA5gl1lqpZjJ71zYnIqKO4rtVasvN XQskevka3TqHjp0nV979zut+8299+zV7lroVaZ6itGuhOEbbpe0ac6mquq5lXU9aHXNnlw5t24aV UjTmLc026rnlC63rid1SYu5V7CvHi6+MMf+Ekd+07dpinHPaG56jwUmPFWuNb+VtLViYsbHLg9FT ZjvyKPeI7upu4BgVTzj8uuqBD/XyDl/9v8idPboc2uLqP14KO+X+MMKf9gYmkT5d0H0rfwbfa4e3 e38+44vnwa8Mvj9eSjevNC4/w5n3BocfHU/vHNmfn20mvCKh1dve/Fyeo2U87vml74PbvX+V1T9z D5IjZVf9/dCPZ1vbZXC6yVRK9ttLMrY/D/fiNjb84P5pDkojUx0bTTXvVzYwuBjejjoGbPM6x17V yvwyKR/MLckWv1+p5hWBxaVCPtHGRivadaG2f9lgCo+3DOtdKfXwXCUt30Ujd4ejuNGFEJqjqJ0f 5erkCdJumrVIjj/hQD0xrULMjroLdb1zslDZzVdJmRQ3DHSxnrXw0rvsH1il23s2caApujnXWDZG 27OGbSlls63WNzebZqo72J5ONzens+i7srm5utmsTTfPTtuza+vHN9aPXri4vCqfOXHh2afPqPNK N1iyoFugE5NZDq/184a6LKOxpd3KjrytdesbclMH69kbzXQ2RK1Mt976IUKh07E5j3eHwRD3TQXu qm1MSx2ThXa6ud5ev2/hN376O951x6u6RRa+8pJtqeNXHiwsjZ7No5wF5qquFmbb+Mzy8vKFtTPn ljemcmVlpWl0mG5MBZey0W5FryNZHz1+rBXdvjX2SIHIm5gxA88vZdnybkh0Wbl92TXrnAG2HEPp 8PGF9fbHk13fd3/3bwb5g9T2x5MdzrY5G4Mvx0pVtxxhvwBj8FMp8piexcR8QmP7YbXFD2Gb8x9a MlLj20jE5+qR0VZDJSGyN3z2xTlTzN68hP18eFcZOX77UrH8W3ERSDqtvEzIqwZnbHT/H4mV2Zv9 P8aGzP42VfBGS3P7f9u7NIOTGxyPMpXiquicYZdHzf3WnPnv/eFu186fmfkzOWcYOTJYu73xb2P+ h6l2+PjWX29uPY+X0g3O29jwphmvoff94NvcXiPdKW+922TDu7sWvb6pVTK2rU+O/fkZuaoM0TaN iWEHlt19b/uR/c/gsVqM/8yzZyXn1cA2f8QRM5mWf8ddTERVNcJ8xvNgIrBs06cbzRfc+ahblyqe VbVrYeHg0s6dVd22U5O/u+5j0hkOxzfbzoSYb6wwZTuVOuKRz9kHzK6iA6wwRa4X2/bEyoXV6Sza VxfWN04ur2yIHSdPryxfaJbPX5yeXqsaqepKTczaq2eZtjbZspm93+pY3DamxNbef5tdljSVqW2t bztv6Jrobd2aLsBtQx764UZl1qpvWc8tna3RrqIlNYXwur+VtmraZqGZ/txPvPNvvPuunbMxyanp csVVgxkojZb53RNz9VAJW8qtKwTpvsjrhXoyu4I4cfLsc8dOnFw+9/TxU8fPXJz9PbuCWDl3Ttha KG07dlZ+UaT5bdWmGKByP0f/Ubyxq25ZwmxU9uzrStHCc4rdUUlU3ZVXKwcSX/qzCeOxOSnuOKcb Xl/7mV9R5X/wKjp5+xbRq/AUcNj1u9Ndlbz0Vw7JDzI6EEgZN0iZzE9oQTOehFRhDblVIW1TOelv 0v4Ow8J2mcxOX7r6Evb92pdb+MHs2MyTEPoeix+5+U8/1GZHHD/bdbeM7tmOKmyFeNNkS2135PCp q5KVrop4DP6P1j26IduwRu074SDVuqeww90q2RvJQCFE9ofdjXv18My/YQGqKt618pH4elphS7k/ 0sL0/slAJr15yaGg6bL7wDWGWTDlDuJRW07KjbkfQLt3Kjefg5+GPyYy2tP8ycbE5Xjuks1tf87R mGu/ZrqdxN6m1LuTvXsWnXH9eqvCah+cMasrgJmdzEyrWT5FhYIZZT51K6f1acw962JKQVq7H6ou QMf1Ed2brYrOTF1ItY9165et37f1Ubc1/Q5U+UiE+/2GEhdT0rF1pjQvq9A1ropaicom0Y+VYZFt fT89kjh1+W+FkbiDhZmiX0Y/sN/s3cB+hoQ/bqjejHVts0afyl7ydgOnqVV220iFycWnyNlZW6oq zJ6fARm2b7TJqjCqbazt7l97i1v6NOnm01faybZvozdwm82kKaFr7L7RrbFoAOX7WA6rS7YDs9fm L7tJu9HKbnPbHbKyD8P5VaT8btm6s55dYVW8BtxUop9AuHUTz2c4/9r7guYobX8IdondYc23FNGV G3S7mLQpxY3H7p/msKDrpor0oT035yM3AWanS/uomj19KnNKi2KJP+mr7kRrxNUJq/zmuq/KK/rM irbLZr852OKgn8Sw7FDmp1xW7il7Rc/zL0fd8kZXPsodsX1WrEzTF5U7fyhTjdlUXI4m5Pde6V51 FdhkdvfJzYw/RMShP5Q6m9gyO2TqduvEgq2b7PY3UyAt1GJ74fxPfs/rfvaH3nVgace8tTGL0fYZ yf6KaCaynob8JHfs2Hnu3PKTL5x69OkXHnnu2COPP712bkVXkZ/U+oRa17pWtzlcutV2WYN0+G0k UaPrhSiP0aIXrYX9WUrXdI7waSD6Vvd7SwKpF086rCu76tqhGG0+tEeKEDXiMjBzUrTPotoY7Y49 8RV/FS+dXdik6Ur7y/d/V3Fz8T4F+hH5qBHNZxUecVA+RpsLrBDd7B+1CPkjDT3KtEAeZVw/iSbE 0O59Ufu6QPNSbPbS56S6W4qwUKEOk6cn4J8Fll37/OaawcxPlH2Hjib6c38Y9n+E/UBnyvCpcBOq /ETsYciurrBxQ5wMp+Gw7PbKxAX0aKmV+1Ybljp8V0S7TdjJ/dSTaWVLF+da3eiPXodJUjdbqvct t/IrGe9R8R/RJZlbOlPcOZiM7RyoONzY+Qk7s3SVweJLx3jZhRgo2nc/RnOL3Ybs+GGANvr5+CHt D6Hq74eDL0PxTGjiyqzu7vRvY41M4oIIf/Rfhjhb2eiTlkO3ve/qGW3c+olHFedI17SqmROXZvwz Kl3MEklXw4Ozl/xhx2YeKjDnpJDgq9FlTMfQuueIwk7e6gXt1YXozUmTpSsbJ0OQCguVRWoR5WMX 9910XSmAXTPxestnIBwbw0iiGD24okIZbYjR9gq8W9Fmq+kNZKqE6qHSysdhs9oeh8Ok7ZHeX8G3 YZfLsvj8RN5/qUyxcvKtsOvKgYEHR9KEGdTryhYoRNHdrUMzTpFsLNPlctMF5d5e6sqq7Ry2bh2I ZFu7A24bRfN454zP2m1axblR7meSnD7Ss3ZrL/mUHByD8Md5Nz9Vt1fo8lIby0VeTG63ajcbwi1F 1VbZIkv7P1O+lO3SjX90Plpqd/ZPTmShHe7uzJsU54duxfIT7vwM3JOF/G5/SCs9Ru9X8Y3rLj51 u03+UEf8Y3QzH+2QIWemg0V7Zj86p2MwB+HaFhe7zl+UbgxvNurZKXIW45uV8299ww2/9ZPfcfPB ffPrqMpf/sL5cK5KfjaVjubStPO3s168sLn25Seeu+/Rp+575Injzx8V1WK1uENXYDKPT+oao7KN i83cbJVvntEZ7cWsNDIOxOhu6v6KJ/zIzMc6/8Vf23awG37fLbsPYW5WwjqpkgOoDyJ6NVVdbap6 cCQhj9oYl81Jt9/0ErNIA1xer0t0l/LhZ2F/ZbXvPMgmI/9rbKsoP2XhL4yzGqkpEZ6tHsh5Krmd 1NXV8RuuW7R0obJld0sZQqdN0rINsTUMbNubtAdNV56Xpufh+YzyqPKXGcKfp0USo+3w7pAX7n7E /7bZETAZfxKjowG6pY5CdtNf23aThenGs+Snm+6N0q8EVUVbdmA7xpMwnbraFjCVL1SpsvWWvrRl kt2k3RqL1nm8Bfsl8V1dTzmwSt1I/HVPNgPhnkkVVb4cnk9/NJP22knK+BwgRPdkXnikz/VJu1WM 9nPoX5qzy2BeifOo2SitW4HKdcTQlf/FUTKK0f1P5cgksj/aKN7ZaUafVuGEl6XqbFRtUsDbdkXL tlSyndq40s1JVGs/S0jRaJMUbgNxWLqx/GcnnW+LNDVmX/FLrU+oYRLxAaeL0bK7ReASk+qO+dFS mwgb7oUqfzMtKkJOlsv8x7cL0a3nMFA+223SPYmbAX9oz2a76WfxKH7FiVhEVyPRpLspNf4yI56x +K6QGXn+KEWIp66YvHVF6U14wK4LuMmyC3/wty13pTE6/H7dFglji/a0tBjYbRR3TBC+EYwwUDxF P92B8K1a/5OU3X2DZEGiEm4zqtqvZ18GF1a4G8x3EGJXvj1qu0sgGcovAjvytOAyb3lDzFUa0/qj G/gFxXOj8gwdr6VoWV2w1pU31Pg4e790Gb/j62n058pEZzPF2fpv2toc3hvVmv4PXaeJphpM1Zxb ufPWw7/6U+9+883XbbXyTIwWfkdRKj+vT6p6UskvP//8vQ89+Z/v/cLyybNicbGu63BzfLavtrIK vThuubVevMFMJlwnmS5eyHD3NvxmBmJ0l/+yQt8QO7NK89l5N8TT8FKIOITEszfYQI+db/2vbj/c hD17PMk+lV2hu6ngmJZGuyO4TCYRZqzyx7fwrbihH5nGaPsLldsvjTYVfqSUSabxly79gBI3vdlP kL2Xca3WWoR4LdvuuNZGk/DFmd12secG2ZU72p9vdr8+DBa92Q7GwSzu220RX4b0Y7QpgMlrqthR DZZGx3tdHJT933mMjtZYnP6TUhn7i7B/m9Jo5S9x4+s0Ga43otKOeTFa71uttNd1bp0rV+evP7CL FOG5DBUNFjdr6vfbbpNFay+USiZbWcwpjXZ/VMI//BCtmOH59OVVyaemi6zkiBzK8OKb7Gq8pDZk IFsarU8SVePKSJIxt9HAvnWoJI/Ga6A/iVCNJIv1jak62M3+3Bjd/WFnwb3ZjixU8sv1IbvqUr4w v0EV5t2spdZUNvCnbz3b3e8oj+ammmB4J13JrU1UofsGl3Kk6Y1M9K4cxpa9y0mh2MzE+rFKHcMr 38doP9/RdY6v1BEvWvZ3PvL48j5sUNtRxcAMZFshWYHhXoTql0aHqfsL/m5Vp48j97N4iA39KQZt kmaqUCnF1oTrdnXl7+hGxc/Z85HJ6nKXW90B09/b6ZJZ40qvw1awR5DGT8IN1kYHAX+0kUPBMjny hzqQ/lu1KyPoBXo/6W5LKTtw2F1l0llJfF4zZ2Q9TGN7+Otqqvj02UtcaovQPFwanUWdLdlbmkNR dWQ8vd1DqYH7Y4FMnrLIo3D2XKAQSRsyyaiSyh5JgYVZEVPToseiaqdKbEqxYNqCm6pzzZHDV/zi 337vt991g538/FzrYrSd9iwfN03jw5CqFyarm5uf/sKjH7/3i48/+pScTMRkQRc+V+kFun7qsZW9 OgOjVxIvTnaWHavU0Zr20uNcKYZjdHbR1p2n/c8gLw8Le3CYH/tO466wu8O9SIrTkvezGiPbqdQx cB/cTH1epQ7hbrjbwtf+arSVOqQronTrScaZO/pWP0YLkRQkd5+aOtAimhMZpuiLO8NLK1x+RFE7 L5GV8QzItt8mms46bVfro6vX4d+xU6vTGO3LEvwP0m/3+TE6XGbEMTo0UzUW0bK1GnaC8IGfehjM VJRS+mZcCLXR0bNKX0Yj1zfj4wwaKt6ocK6yK136miS9GD1c7cHNg3T1Ak23AvqMZa/s44uWwWXv HhhXlbv2i9qQGgi13a/PlhBHJ7Mo7HZB2c+9ykZV2V9s5ZdxZBv17kW483/VL3a16/ASY3Q8sC1K absxJ9/Vle66yUZn37RQJ03bAzE6rJmx2Uv+iIu2kk/b3kLFWyT6tOneFCLvr6GL+y4Bd7EgJDO3 b6tszPFKNhWUZZzvR2N0NEWf/OJF7tdBVLZaS0GM7oKwuYHcJWD/6UCyH9tnwvEtPM8UfZqU4sdL 0VVx7vbVENFCnfi2962wbuMY7UrxezG6X7He7n5+fdr+UIStKBjm0x6CVFirbbLF45nXFQ9M2XSc bsO/MtxFTK4c9CWMuYrutrKptRzVJYjWZzjvxz9qPyfDtYTjX5dfLV0YCHc+hegeV3Bbwm5lKdwN cJeD3ShCjXA/aV/OoHw7wmbMvja5XWNRvaDefA4E67HWbBJldaP7cTn+zWaPlcVnKJX+BMISZPcr wm2cft0MP0Q7WlydRuf4i1WYH1v/sDIHn0b/YdbvpJJNe27zyOHd//S//8b3vf3WBTXRO7QebDK+ KqIYbcceejZfXFw4cWb545998MMf/1Q7ncV0u2foKQnTBaUKV5B63/DF0VHR0VcgRovucbF+jNb3 EbYRo91X0pGEmJU31yB6u2m+f6SfZnel+9/KSqNFus91pdGiS42DczK/NDoJKP6A6cKEDx32n0om Y7Z/jJRGm8NUr+6sO+X0n1O8rKXRbrionXJ3Iz4U4cRPiqQPRGdxLSv18ZPuYnSy6kZKo1s5XDe6 SstTuxnw9UCUSEqjRW8/1Jc0uv2dLkZHA8cXVHn+iz7KS6NdDt6iNDp6NjTdRn6F+5dx3ejxGB0W 2ZUZh0c2t1caHWJ0umh2v51XGl37YQaXYmDv9aXRqvvUb2bPnhrN16IMdzlKo4W5syxEd5sy5D// qhXjMbrLJVHVT7FVaXQ48WRVb1vT6ZeP0fNKo8MCuOJ55c4jMorRUSyrwkNvYanCAoZx+jfMqU6G KXYByMbor0xp9DZH4l76Q0p4v3IP7/X2oih8u/+GYeIYLZLrojkxevDl/NJo92+vNHosRts/4poh OvC5LRiqD/ndsgkVMLrxdLtZevXSuuODUkpVaenvyDLah/+6utHuqNW6SeiqpZULKu4XYR9m8PUn 3U/SH538r6nOJt3NYfpm3O6h9Hdl7V6UXERlFeKrOtQhtpWV24Glk3GXc67yjKhN5yD56dLXqR84 saYGsrIdfqwfiTFDzzZaY6XRA+/HizxY+7eLv+HTXhU4kfafIn0tR/fF3or1kzM3uFq30UzzdrPz bC0urtx8cO/P/s13/tBbbjPHEF2uJfMWY3pj+6Veg3ezqS4tLT30+DMf++T9n/6LL9RLO6aV7/NQ 5aOT/uKjka5aj0wD9OWqG+3mzT9iGH5jc2O0mbp0D/SKeTFahF9g+CFFd2G6+BJO89EPKXlnoFpz +kf2MpTnudoRYVoyzc2hq6G06kK0apK75LJfASNdb9GYXWm0e8dM07aToA++VRVXMslyXng3uvAw n6ZXDtJn8XQkRTFa2pKS8ORZt9xRCNaJ0z+crocJK7BKGv2x2Tcc9bLT1ZyYtWVpdCUnWSiMv+sz X5Ips6UOkVGEiwcf6+26jXdR0f3cBi5aohF3UbgSKvyIkht8AzFabFGpI5RwRzF6cL1FSyGSdW43 Wbrm+/9GK0cNVuoY26Pa6Cav8ElaDtWNVnFVH1u1zl8RKXs0SE8PA3Wjh2J0v6UON2/byEBZxAwb Ol4DeQQUeYMJ3ad+PqWPU/6ppmQGwvvx/KR1o/uzHS11FKPTpuLaaCTuV+BfdqXR0csQl10E98Fr rG50NpIkRttlbHyvYW2vMHVwW7jL4172HRzYrfyhSh2hXC0eVRza4mVJRtuP0bNlat3aK4rR8WBj MTqUmHbfdfE6vJLZt0LrdTJcxQnX5JOKKrVLW8On6rZ7suuaRKt0pYw6pPb5MTpauiqcJrJ9xoyq F330HbCkbrQuRDe3Iu1xz/cMkvfhl530u/eFO1GK+Dhj5sSfJaPVGVaXiGN6Mq02mVYSvu1TJf1p JfHDvS9FVk69dYH0lgNkBoJdOJ4MfzSU75MdNf569ixK98PJ43g/KPuX/rSSFlq7E7d/RkgXRZta CROhpucv3Hj1vn/6E9/yQ2+7rbKHCreDbVFUn8fo2TR27Njx+OOP/9Lvf+L5Z55TO5aUaValnu1t Va0PRPapiGiFyOjWWzaqLqm8aP0ajS/6EcM4Rl+G0uhs/x7/1kCljolvBVO3e6iaurvYq0JCyppF i//oV6Hu/h2p1NE9hjgUo7NKHa5N8qGWOtxqlNHAtkDiMtSNFlG9gqGWOoQYKI2Or3miG21RQu3N QFqFOpuHwVAoohgt/ElRiOK60UIMlkaHHc+V19rmC+z70UiyutEyLUTvYke87F1ptKiS6foYvf1H DO1hfZt1oyv3FVPDT6R1o0VelSLbBNGaUWGJ4hi9/dLoePyD8+nGXEWbrNfopBiM0dt7xFAlLXXo xRlrMTqO0VGfdi4ny6j4ObwM/yrVL40ebalDxtPqArFLw3Zo/2F/ofKb4/Fs+1EJd2HvSjdt+4Cu jLmLUz62iiixmb+b7seSvK/CsvdnTJaXRvvhXmzd6FDSuUXdaHvRJfuVZFx4lYOl0bprtcEZSH44 2R61dWm0bzcz+e543eh+RZE0D8kuRtt12Utd7sZU40ZoT80hmpvlNqs0Wqx4YZV/mE/6s5dpZVef peIdKS0d60K2iKplt3647jM3h0n9IhGybMLf/XAPC5rtlpYiiZCFVFcXxTSYKOJiVjc/sg1V9cKP qw17eyXzDe2jTDZb2TVYv1wvH7wwpw3mvXj82R5o62DE7yvXMob7vFepY7jSSFANvNnlZhHt22Hb pStudgqaCheyzVlvZfmeW6//X3/oG9735lf7wrjalGUm1zOD5L9+4IKNSPYufDWpH3/qhX/z+x9/ 9vnjupOYXo3Al1128vNlnN1jZ0mM3u4jhvGHYjDp9icdn8iFPwSMPUo4lg+yloztIakfo7NOmPo/ hjDpboquD3uZzWdcqSOL0f1HDO235lTqMGNMG7xTXXLN1tslVeoYrxstRCj/s++EdhuTGC26MuyQ fZPqGQOl0cN1o+OXyahEEqP7A9tJxxcncuQRQxHteEMN3nX7wfgjhnV/yCxGz33EMK8oMhajB0uj 1Vg8LXzE0M1tvj6HY3T49/JW6ug+jRs6NC4tRgtztpgfo8Pt3bhSR1jkUOIponNzfMKIS6P7sU/4 nc1+J4p0IzHaLLv5tIvsWYzOThChBcDBGG0GkCKpqZzUje5X6pgNENr7N5Iif78S8kodbroiafDO /u6yAuY8RndLUhyj3cvxRwyzqcQbLmxH4bfOcIx2YWt0B5v/cjBG+yn2qgtvI0aH+Y92PLvs0UKZ ljri42Rcd8gNZltx7k0rZKChhZJ+hHGlji6BtS4Ahfu33f4Wx2g7icYdwQamK6K6HDZg2DxtD4/u 7pApawprwB8hVXxFEWfV0L64fyDK7xy+LKP3s5JNugfGd4AvV2HlZadCAWvaElf4pUcH7LgSc5V1 Ox8tdRqv53RWGvYZado3MUVatg0ic2yqzS0I3dizWGtmb37T7df8qx/71nuOHL6ExZS/9MByW01E 0+puvKvJufMr//f7f/eZF46pejJ24fLyIkYTo4nR4dPoJTGaGE2MJkbPe/kKidE2hibftS0A9qbV n3R0BPZ/yIEYrVwN7Py0HnJYtMuJbPtmGzpMsfEhzw+mwmhNY2nRV0wrxCLaUv5IMvDMmC/Ol+Gs p6uXpIM13S9Vxc9Sx6EyPYcOFKAqmdfqjD+aL5tt12xc/1eTiOeu6rcMnc1lOrbRutpdNE+/MrQE ut5E1ZhZdQ8qmPvZjW7WxdxjV3J1Y8fSFX/lbUf+0Q+989VX75+7OKPkL91/tjHV8PVz983mL/3u n33m819s5ULewNMrBjGaGE2MDp9GL4nRxGhiNDF63suXPUb7RjZU+MONeShGu0cDzctQeyTSxVm/ QvoxOhneLlX8Mslhfinszz/eIvGSmmWUcTcuKq6LEu0kYSTxMc3tI+Evc9IPJdNRF4zRV7r5rPrV YwbZKY5G0ZHh5+jF6GHtyDD931f88x+MxduZDdGdPdvBT8P6FLbd3tDNnGpV04iN9vbrr/zx97z2 p9/7tr1LC2o4i29N/uL9Z3UXKk0tq+YP/9v9//7D/7lerJVc6A6j0Z4R7yIvF2I0MZoYHT6NXhKj idHEaGL0vJevnBgdFsTVmPcbTsXtRquu8kOYbrpQeTI2I0xidHTEjnKbr+MR5j/e8bKD/OBa7SK1 vwbQ8+HKxf2DW1H3kyK9SNC7oqv87Y7U/WmZ4buNMjhYkJ1ABx6vvCTdMhZLaioH2xxVdrwaH8ZN Jat4HWbbPorRmt4hq0a2tarNAUWsbIhdi9/1+ut/5i+99Vted6MZ2v7WLmW9yV/8/HllWoz+8jPP /V//7ndFM238U1Nhhl726BwjRhOjidHh0+glMZoYTYwmRs97+bLH6KwFjGgpbMuKXVAeeyI2LbHu YrR9GQXieTHaTiFdUUmMDqF/zlrt3nd7VhO/NCuhV0SququF9BlKXzDvV5MdJhz9wupNmneI9CPB 8KyODDVa2eNyZ7/5IxycifQrej1UQ+MYHLNtINr8nGwNadmub8xW62tvOPgj73jN3/+et+zftWj2 hKlQk0ssixamNFrVk3Zj/Z+//w++/MxRHXXq2f6Qt1rwykGMJkYTo8On0UtiNDGaGE2MnvfyFRuj 9R+mUaO4Fodbi3Hdj4EY3Y69DO1HSTWcuc0fjS+4dTue+W0q31mMCsdeEaXqePWas2cXmkWI0Waf z9od7z87KJLubGTY98NzimGFhPWcniuT0tMw6rH0NpZhS/PeWBoeGos75PfesePpf2MgKHeHL5kc ZgfnSop06yh7LmjFZivWNw5ds+db73j13/mOO7/59ht8AmxtjwdRJigjf/7z5xYr+fHPPPj+D/3J ZGFhqvfldrRp7VcAYjQxmhgdPo1eEqOJ0cRoYvS8l6+oGB2Wwk1IdJWMZTtvcdpuJMMxumuGT8b1 bmXYVQxTG7ud6j9MDz7mU3vMy8aZpDc723E4jmN0nKoH+9yJW6K0e2aI0fGh3u0CvTWQxeh+VPNf n3d6Dd8eevMSDD3OOPRAYf41X2ln6Otjgb/HH1bib8eTmB0+qlmAXtu46tr93/TaG77/npt++B13 LCzUJqiYCXVr51IrdfzcAxc2Vtf+j1/4wJmVNb8DJSOKjx2vBMRoYjQxOnwavSRGE6OJ0cToeS9f UTE6Wbf2eOibvQsx2u4kcRPpbtai3rPjjGvFrVlHR2x32gpDCbf7mTxtHxlsk2H8OHtrJmXq3uZb yu7zdkvFx7S4frf9qEmetmx6tU3skH7BC8NY1hN41R3ek+C53ZLTMPU8gVT+ozZ82q+WM08ct+Kr n0wal8POmXZQ4n9Ks3+nbbUxvfKavd9y2w1/5S1H/uo7Xr9zoTXtb5uJ2BZWbAPkZhzbXA35vP/8 58994v5H3/+7HxO1qxJdqbaRE1l+paK7WJo0ol3UPbnphvlmr+v4HLktuvX7qdKPVdat3uizfbE1 //FT8ae3EKDDm/6MW4cQJtLEnMXPfoyO9vgqjDmPoVGsCZMWUfcr8dHWfDoQyuM0Nvt74h8I6MXo buDKxtPQhXI0M9k47cd2cfKOVEScyVyGdqvOVgur/BiisWU9v8Rrsf+3dPdQVFjkqovR3VFvcCTJ vA1NMeo1po0ztNsotisQXzVtcCR615I+ikXHdB8NB3qN6d6xvz27zm0QlK5rtHADMZmfdFShcyx7 Og8xuhq61nIR1sdNJbuRZ8fl6B134WHSpgpH/7AIyhe2RDu5n66/zhQRO87+ru5WXRSFdfQU6dVU L0bblwMxOvq0W66o05Nsb+zNoUvMdW+Pav3flYnRdrblyM4ss0sdO2m/UC7QZ2fKKAltJ2aFP2xE no1EX52aGJ19N4TpSnT9mAyOKvujG9W2u18Z/MN2C+K6CHVvtT43Rx03pjE6RHMZpX8T/M3fLlW4 LOtH4mJ0FIiTcUrbV4t78iy/VolXXb7y7de7kZhv+8uQ/paSUZYNO8mc2rFx8HUD+4bbwgjDmtS9 T6hk0t0sxWOLe2PJqtjaiCny2e7P2JyX9o+mNxIVlZ0Nzl66yfy3TAXfrPsVG6Nr6ZLuYPcr0cz7 9puj9+0X4zKX+FfmVnWU4+Nh9C/VTLLpes3IMnE3D6ZvrCYc/7MBRlZjJaLrXtu7lllPdehKxG7u +CIqH8lsJ6lVfJWi+3h0RfKN9OXZoZhKRAcBs5NIu+6zE0EylcF3Xz6l8TRbae54rtdzYx4a1Ms+ i0mN7iFztraaavZqtuvV0rUkPW3k6lTtnLz2hn2vu+ma991904+84w0LtXBBWZXP0Fzy5x9Y+Wf/ +jeePnF2tj+1bVXP5qPRHXeWxl9lYricjcQeNcRCJaaqqrfZPktQt21junSerQ/dn6w0N1zaVkRn OxkVw8ddTIffQ5x73B+VymK06oUJoysBtS/j1DK4y/rzro90VVSK0wsTQXhpS3mrWiT3eqJPRRpk 8wX0S936/Fel+SCOtvE6yeJydkiKJxHPQJarsmWRURSLfuF2+MqPZCBGpy+Tq44qHXjO+lTp1c7g wPbnk5dGp/ykq3g9hNUYdwYewrGYF6O7Qu7oAkPaSO0b3+lmeDizDl22+Zd1evkn3CxVyXqIdwM7 AyK65tcvq3Qx565zlykrGXqndys/+mL+rcpdOWRbp7908fvRRWB8GMkvD2wp9dCVauXjdavCAqYd emXzmQX6sCm7vsFDArA/2LgzcJGXUmeBz/xl1libBNDsBmiakCp7pu/2YTeqvOPxOA72RpKclnxV 0SjcRN19Zykz+7Q/zu5lmhFD+FemWC4ODXFEixNSKHX2eUWYaotu4O5YF0WKwYUVIXDbSQubfMwe a07F6ZD2u8mRsL+K4q0fMmVUpq5EdKcgO4wrb3C2+1vQz1laGm12uTbb37oxdIea6P0qu42QVodI 908/vPIXQipeTdE449wso+4z4ygs/U/YjiS91HIzmixCq+yhqTsP+vuNYRLxOoyXIq7uHC4W3cij A2xWGp39iHpVeHtPBw6tt2jtVdmWcpeOMp7n5BRvB8t/cVG/g8pfVMSLk0167JnBwazyMspnOxgt dY5uAekYqNdGPcuXevfQG9kUX+mrOH3vQse7qS5snYXHqWo3Nvcf2v2mmw++6abrvveNN7/njTfr e1GzQ7hZt1NzqquHp3qJ5D/86JP/5Bc/IOqJzqzVguiagymMv7oEetrWtd2B9O9dTcyVQ+F1kdJ3 OfV5xhYZKn1oquQknK7s/hGl5+SAZXSP6woxUBodZqj3LTX+cnS/jM/6Zvb76XBeabRV26UQtS00 0geOXuBwQbZKlrc7tego7lNOEqPTWKCScep/hzoDt+lhrPvxsQScRFiVJBJfIWS4NHrsZYitXYAL 292MXEWJylZu80NW8aPH3fnMtD/vAt9gjPZXI8qPoYuYYf2bjnNDcDTrsFVi4KrJZzBVDa3AbD9U /kyerMaRfBkG0PEuOjHLdGDRe5lN2o0kGvngpLM/ZhNt0+y7dWl0emUYdq0QlMOat+OJ9s+kglA3 zrS4ug0/EzuVoRmIbwVUI/Opet+SPl7np3CfctxZ05bzRdlXDKXYUKlDdOd1XfrgP+0Gtv9WPoRl mSwZrT/jmg+arjPqaLrbL42OT/OuKpf/VnZvvR9ekyW1A0cfxIP1i9jtMrbpOGU0gIyvYaL4JSrZ X5x4YtJPMR5DNtOhAQRlKhgkQw4VeGepTmUVG0KMlv4yIOo2L1nq5FqiyQaId3rlYvToyh/7O1sz LpbFVUTiLw5V+RAiL43u1wzxu6KvOCdcQxOuumD4XUSNVyTrXLhbGfEjhtLXsOpv39atz6xutJ2G sPcqG9EV5fRrH6kkRs+rDJ1+JYvXo8192DIjVdUq2y7RcaOrfOJavBZxkbb5T77b2NNJtshj4aRv rKWOsTT7ko9nJGdKeyyouspUJivP1l1jrqzMxp1FZx1YK7EpRbMx+9KVV+06cmD/62888M47rv2e N91yw5V7hd+ddMbRSVq8mIbtxsj3/suPfuyT9+lqjmozrndYOiJl7m+ralq3vn6CbGq10MrpJcyW ztDKFBmar5tifD/H6cmvFv09KY/RMlSJ7p2NoxddLQ4/kuQQObanxuFmTt3oKF4PpGpfrbn2NUOG M3evdnIXuJW5x+GXvzsRSl9Xp/uiuc4T0eVHvMXT9NCGifbrRst03rb8W/qLgcHE1pq9p/f1tl8a HYo83RHf1nIJ1XOz+BgNLERXGp1sGqWySfjtZBNfN8LK70F5jBZ5aXQ0qrYbVTJA1T8SRZ8mu6L+ Ww1ffpgbGfa7fguas5iu8+QrHdpqTu70Vpnlrbox29lTcWl0Mj/DlTqipWi7nWroMil76cuHbFFu mH0xOIlQBuyPpHPmZIvdbzBY99dnmJ/up2HfTwcbDKDxY/hzcqpwuTmtDtH7O8ujYa5CehuMSnHd 6PC+jSMiOsnNnz0RlcLaFOirNQ98q6urLaKLijwot2lptA8Hvg6DmYSrohqP03w1LqrPy1BNldZ6 fqa0z/y4zNp2v99sVcTJabDAPln5MpmKe1O4q4XskDJYmDq0JtPV69oNlqGmh7KVfntfcR8NLX4j Bt608yGjkYSBZG+ugjZe7bK7OTOyL7VhYymRXUPlA4eV3PgU6w5WwlVijCfRJvXC80cMK1flQamu 3eXWPsoWho82dBKj/d+jVUGyncRLirR1dEmej2yz1ah8m3oqjtFy6HZNlMeyZb9k2w/cl+ZFzl7E FZQpXRYrpb1MdbdLTM2NaaO7R59O5a7qyIGDN1+z945XXX3HDfveceu1dx+5VvpzvbvO1mOaCjkx s5henl6Web3u7/3SseMnGzmxtTzdWtCpeusHLVO6WkFbz/aMBV21Q//8N5RYLK5jbY6Js2/p6iC2 flVa3XwsRotkFzHRSqSnHx+j1cDwIi1+jpKuPz6GiNaL4kk+btPKMKF+SJ2WAHZHWBtPK9u+4eCM +ZfRTa7wfogX9sq7K+QLH5npD8RoO4b4kqykbnR3PpZCDqaTdOWHf8di9ODKiSsTh3fcS19fMIo7 TTLb0X0b6RbbvUzqRqcPKcbTmhMH49OkXRvjMXpgJdjZMU+luNgax0SZhm+7C7W+06ze2vP3vnvz mY7Tp21T7haWXXbDKzE0w2N/uOW11fiHNt/YauxunZrYFMfoePPNGVV/eOlLo6tosLa3Vt1joAOX NNHLkUodMr0NGMWXKNZsI0a70mhbOhyuXaNzT5t+txoPu4Pvd+EmfeRRX6b25n9OjFauGNHNgD8W zovRWRbp141OE4n9VhuNMzzylcTo3iP/SWWY8BRXv5aLSM+YWQWMwRidJd24CHZwvYXA1KZp1dUp D4eppisId40Z+/Xp7qfZmujxyKMyhctVN7ofxeL3w6ljcJz9ejj9htjct1p7NO5iqPK5Ihwnh2bA nD23WpzufXs7P1pF2UtbGu0WSSTdoMTnjibaQcJs2JeDKzPfAfwaix9nUlFrfa3sx2hbJ1uFHkOy ahvDayB9GCMaVR4JL62Ztf545iuNy6WVEkwps9RVxqf2ylz/v5pOdU38hXr33qVD+3e/av/uIwd2 Hblu/93XX/O22w5ft3+3vS1sfic6Z7im7/Rt6u7o/RKk6NkIf+BnFxbUVC6q8CCI7J6rLaN0d4ht VduTRK1a/Yh14XhsaLbzINY3xUZTizrpBbTy1+hGV2qSFRf5d+M3w6k0Ku3zT4TYTCO7Z0T0y3hf Sc/x3bMXstu/3filtLlbf112w2VzEi+vq09sFi9UJk4HTlszCIvTvZtU1Q2TiMNrEpKqcIiRdjZU VJobgnK2VqvKXe6ny5LczQ/FJ24c5vIsDFOFdojSuXXlo20cJXtLEb8/UtG2l0eHlyK82aZjcH/4 axq9K9bRhrDXAO5pJ/sV5VdgPMWByvTdBYBd2Da/AvHrf/iiQg7diBBD+2G/EF34K4doFfR+F3Fp 9EiAjl/aAp4uoZpD1WBLLG4+o35ux8a51cs4r/stKLsGRno/k6ScPvz27cBqqxjtdqbeBrIv4/O6 9GHCvWMf229HcqqN3W0SQMPj+fHAXQLuinWzOhVS9CYRF3zGf8RDup6HfRgKvcQJvyDZmVhGdaPb qLWvsTzarZm4WC5u9qH1kTEODaF2bD8rpCeRuJzbVvTPn3LTGaV7VMaMvLVDhjjYm+145ds91c1P WFgpZZabs0XWs5FulKq3ZuZksvRlN2Dljs9mEqNrWwr/rGr0vq9LHbagT2yt/8tvnDBXvlghfcQw pEyV1ujIVoX7w9cMVnHJcajMYJ6sHVwnbW8FhjUlXCKP3+tfv/lbyn6J4jK4bHh3/G02+z9qK+zh 0RST68lY1VXD17uPv/2t0pLp8F0p0sszIcM2ak29Vjekq2Nmc+SQ7Ke9pbG4XBqLX8x4khw1Orxp y7ltFvftWVyQV+/dte+KhT27l67Zt3jdlXtvOXjlLYf23Hn9oZuu2TtbNbVpl0KIif2iL352bXH4 KenjnF9flzlKS/nD/0xElzX9XaeAvkVR6+Wpajm7bphMVHk3Lvpk18pGyVo2rz9y+J4j19SqaepJ 1ea7ePhj8JqsHppuP6D4o7k+XuZFs1HVCOFLvOKR5E8muumq9JMwvnx+wpzbtWbeqe1RspZpmXY0 uf4i+PaFstYbkpQ8tuxSdk3PZzFamHfq3reiUbl6YINp1fXI2gWXbpzxnja2e7hhxOjlh4urvcXJ RivTb7lzS5gBP0Bc09fW6NN1o6Wb+27qZlhdlhAviF0VUeN0QvQKNbNjprlM6v/MpA+F/a+IaOUn v1CZN4YTZ/3knWhFZY39yXDT31/bqHx3yv/2z1J1jxiaVVHHTxxms50vj6rcj6zXOkp/umN7Szzy bM0MjDPaK+L9cHASMntUou6O+PGEdJmW/SOOR6I78Yv0UxVNXUUf5ysnHmagNKs7d/Yn0c1YPJ++ sCxLwNlpeGBsdg8xN3OUeQpwcIrZo3j6j8atw6Q+SeUqGvVjdAgoMnrUzN0gUunqHVxdIdulPVzo mdEv21AMHKfDblX4+1p+T3aRtFXdXiH7KzleFb1Tp+wGy+vwhG+lubB/cVKFHGBeVyErz9/6/QnN fRn9osdHNbLdBy4PKnNYCBX9B/OocJssrHNXCSQ78cXXIWGKcxaqSoaq/B2Vts0qvZiSPvNnl2ij AaQQA7M9OD/SP1kUYrRS/uA+VIiYHceyScS3gOI3t9woYnvxtDSPXa7xjI12PI7rolzZTG+65uDe xfqma/Yf2r3jVVdeedOh3XYAW/DgTr76sVf3MpzTza88acNuTt54kWT9Qz/byEklG38xp2tZ1Wra FvbJrouyP/C/2FOPXhJ7jiyfISUGF/syVAl3O/YlfNHH6HhUl2trdKN6cSOdv4sU7UCDA/dWQjia Fe4nL8GuvP1x2uN9nKqHvpY9sj1nyG1+PPqV/j45tpe+mPW2ze9elk3TP0nM2y0v4+9oi5mPH3er 5PaG97a1h5esvahiS3Qm2N53L9FXcFWPucQjxiWz0fYrcBIN07J/Xa6ppKc/MVw681IuVJFLnpNL Pi9vc8wjI2/jAqDLxz3L6MZ8uUs9xStpi7/k/J7h1qK9RrYlyrbEWfnSTmk/aOyzacpfv5jX4dDq /1Di8j9iaEujL4v2N38mef0S7EMAAADAKwExGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAA AChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChG jAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYA AACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACK EaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMB AACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACA YsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRo AAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAA oBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgx GgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAA AChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChG jAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYA AACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACK EaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMB AACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACA YsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRo AAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAA oBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgx GgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAA AChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChG jAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYA AACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACK EaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMB AACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACA YsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRo AAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAA oBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgx GgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAA AChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChG jAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYA AACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACK EaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMB AACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACA YsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRo AAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAA oBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgx GgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAA AChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChG jAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYAAACKEaMBAACAYsRoAAAAoBgxGgAAAChGjAYA AACKEaMBAACAYsRoAAAAoBgxGgAA4P9vt44FAAAAAAb5W49hf1EEm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AJtGAwDAptEAALBpNAAAbBoNAACbRgMAwKbRAACwaTQAAGwaDQAAm0YDAMCm0QAAsGk0AABsGg0A AFvIooPSCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKPDwvUjExCjExIDAgUi9SMTMKMTMgMCBS Pj4KZW5kb2JqCjIxIDAgb2JqClsvSW5kZXhlZAovRGV2aWNlUkdCCjE1CjwwMDAwMDBGRkZGRkYw MTU3OEFGRkZFRkYwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwPl1lbmRvYmoKMjUgMCBvYmoKPDwvUjIxCjIxIDAg Uj4+CmVuZG9iagoyNiAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNyAwIG9iago8PC9SMjIK MjIgMCBSL1IyMAoyMCAwIFI+PgplbmRvYmoKMjIgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovQ29s b3JTcGFjZSAyMSAwIFIKL1dpZHRoIDk2MgovSGVpZ2h0IDM2MgovQml0c1BlckNvbXBvbmVudCA0 Ci9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDgwMj4+c3RyZWFtCnic7dExEQAgDAAxDZVAHeDf HCMe/hIL2f3OzB1aVnCb4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTH CY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4 TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjB cYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJ jhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhO cJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFx guMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmO ExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5w nOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC 4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4T HCc4TnCc4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc 4DjBcYLjBMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLj BMcJjhMcJzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnCc4DjBcYLjBMcJjhMc JzhOcJzgOMFxguMExwmOExwnOE5wnOA4wXGC4wTHCY4THCc4TnDcAw7YkdUKZW5kc3RyZWFtCmVu ZG9iagoyMCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNwYWNlL0RldmljZVJHQgovV2lk dGggOTYyCi9IZWlnaHQgMzYyCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9EQ1REZWNvZGUv TGVuZ3RoIDMyMjI2Pj5zdHJlYW0K/9j/7gAOQWRvYmUAZAAAAAAB/9sAQwACAgICAgICAgICAwMC AwQGBAQDAwQHBQYEBgkICQkJCAgICgsODAoKDQoICAwQDA0ODw8QDwkMERIRDxIODw8P/9sAQwED AwMEAwQHBAQHDwoICg8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8P/8AAEQgBagPCAwERAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkK C//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNi coIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SF hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn 6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQE AwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBka JicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5 +v/aAAwDAQACEQMRAD8A/ZjPvXvWPnrhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz 70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70 WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC 4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z 96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96 LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LB cM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM+9FguGfeiwXDPvRYLhn3osFwz70WC4Z96LBcM +9FguGfeiwXDPvRYLhn3osFwz70WC4u73osFw3D1pWC4bvQ0DUkPz6mgOYM+9KwXuODGiw7jgfek O4/8aBjx+NILjwM0myk7jwue9IB4WlcpKxIEpXGPCd6Q0iQR0rjHiOk2Ow4JSuOw4R5ouFhfLpXG O8s+9Fx8ovlmi4WDyzRcLCGP60XC1hvl0XEIY6dxWGmOi4WGFBTTEMMeKdxWGFMCmSRladwIytVc TGEe9BIwiqTuFxuPc0E3Mjd9a6LHPcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osF w3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN3 1osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aL BcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXD d9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fW iwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osF w3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN3 1osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFw3fWiwXDd9aLBcN31osFxd9KwXF3Ghod xdxpBccD6CgadxwyaVgHjNIB4BoKRIoPpSuMkAqSiULmpuVYlCn0pDJgh9KVykiVYz6VLZViURmp uVYlEftU3HYkEZ9KVyrEgipXHYkEVLmHyj/Lpcw7C+XntS5h8o7y/ai4KIeX7UXHyh5ftRcOUPL9 qLi5Rpj9qfMHKNMVHMLlGGKnzC5Rhi607isRGI+lO4rEZjqrk2ImjqrktETIfSmmJohKH0qrk2Ii vtTJG7DTuKxzW72rrsclw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1 FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3 e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osF w3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72o sFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG7 2osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1Fgu G72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1FguG72osFw3e1F guG72osFw3e1FguG72osFw3e1FguG72pWEG72oHccDmgLjt3tSsNMcDSasMeDntRYCQfSkUSjntU saJQPapZRMq0ikTqvtUtlJE6rUNlpE6p7UmykidY+nFQ2WkTqntUtlJEoj9qVx2JlQelS2VYlCel S2XYkEdJsLDxH7UrjSH+WPQUXHYdsHoaQ7AI/agLC7DSuFg2Gi4WEKe1MLCFfagLDTGPSncVhhj9 qLiaGFD6U+YViMpVXE4kTR+1O5LRCY/aqTJaIWj9qq5LRC0ftVJktEDJVJktEWz2p3EcXvFehY8y 4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhv FFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UW C4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLh vFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8U WC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYL hvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8UWC4bxRYLhvFFguG8 UWC4bxRYLhn3p2AXIqR3FBH4UBcfkUDuOGO9J3HckHPekO5IMe1JjJlqSkTqKktE6qKlspFlVHFQ 2WiwiDipZaRYRBUNlpFlUqGykiwqDipbsWkTKnPSpbKsTKgqWy7EoQUmMlCYpXKsP2e1TcY/aKVw sKF9qLlWHbTSCwbfegA2+9Aw2+9ABt96BCbaAsIV9RTuFhu2nckYVHcU0wGFM07k2ImQUxERQU7k tELJ7VSZLRC0YxVJ3JaIGQVSZLREUPpVcxJ5rv8AavWsePcN/tRYLhv9qLBcN/tRYLhv9qLBcN/t RYLhv9qLBcN/tRYLhv8AaiwXDf7UWC4b/aiwXDf7UWC4b/aiwXDf7UWC4b/aiwXDf7UWC4b/AGos Fw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/wBqLBcN/tRYLhv9qLBcN/tRYLhv 9qLBcN/tRYLhv9qLBcN/tRYLhv8AaiwXDf7UWC4b/aiwXDf7UWC4b/aiwXDf7UWC4b/aiwXDf7UW C4b/AGosFw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/wBqLBcN/tRYLhv9qLBc N/tRYLhv9qLBcN/tRYLhv9qLBcN/tRYLhv8AaiwXDf7UWC4b/aiwXDf7UWC4b/aiwXDf7UWC4b/a iwXDf7UWC4b/AGosFw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/2osFw3+1FguG/wBqLBcN/tRY Lhv9qLBcN/tRYLhv9qLBcN/tRYLhv9qLBcN/tRYLhv8AaiwXDf7UWC4b/aiwhQ/aiw7j99ILi76B jw9TYZIGzzQMlDdKllE6t7VLKROhxUtFosIfaoehSLSc9qls0SLKj2rNlpFpB7VLZaLSr6Cs2Wiw i9KluxaViwq+1S3YtImVahspInVaVyrEoHYUih4GOlS3cBcZpFWH4FAxaAOZ17xl4V8LtDFr2vWl pcznbDbPJmaY+iRDLsfYA10UMHXxV3Sg2lu+i9XsjkxGNw+Esq00m9l1fot2Y5+Imk+dDCba5ill G6OC5Ty55B6rBzIR7lRW39n1LN3Tt22+/b8TH+0qV0rNN9Ho/wDwHf8AA128VafFNHBdq9tPINyW 8vMzj1ES5fHuQKxWFm03HVd+n37G31ummlLRvp1+7cxLj4n+ErfUG0dbuS51tSA2mafGbu5iJ6eZ HFuMf1fbT+qVOXm6d9l973+QPGUubl69t39y2+Z02m6pqWoYkfQZ7K3PRr2RFcj/AHF3EfQ4rGUI x+1c3jOUvs2XmblQaEMzTKpMMSyH+6X25/SmrPdkybWxjT64toGN/YXNuo/5aFN6fiy5x+VbRo8/ wyT/AK8zCVfk+OLX5fgZN34ys7W1+2GEtaZx9pWQNCf+2q5Uf8CIrWGElKXLfXt1+7f7jGeNhCPN bTv0+/b77GJdfFDw7p5tzqwl0+GfBhubzCQTZ6bJ8mJs9hvya3jllad/Z+9bdLdeq3/Awnm1Cnb2 vup7N7P0lt+J0tr4p0O7lhtzfLBdTY8uK5/dmX/cJ4f/AICTXNLDVYJytdLt+vb5nTHF0ZtRvZvv pf07/I3WX2rG50NETL600yWiFl9qpMlq5Cy1aZLQzYfSi5NjyDea92x8+G80WAN5osAbzRYA3miw BvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5o sAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDe aLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA 3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80W AN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYBQxosFxQ 3cZpDuODeuaQJjwTSsO5IGyaLFXJQealq40yZWqS0WENSUiyh6VLNEWk7cVna5aLadqhmiLaD2rN losBlRGdiFVRkknoKlmi0PhWb/gol8DILieBdP8AEcqxyMgljs12uASNwy3Q9a9xcOYuSTuvvPAf E+Bi2tfuNnw5+378HPE+v6H4a0nRvEsmratdw2NtEbNcPLI4RQTv4GWGayq8P4qlB1JNWSvv2NKP EuDrTjTgnduy07jtZ/4KEfA7Qta1jRJ7TxDNNp13NaPNb2atHI0blCyHdypKnB7jFKHDuLqRU1az V9yqnE+CpTcJXunbYor/AMFHvgN1bT/Ew/7cFP8A7PT/ANWcZ3X3krivAef3HsviL9rv4PeEfh54 S+IXiLUL2yh8TWxu9L0VrfdfXUQJAfygflU8HcxA5HNcNLJ8VWrzoU1fl0b6L5no1s7wmHoQxFR2 UtUurPB9K/4KYfBq81OO01Dwp4p0/TXcKdQkhhlWMf3mRJC2PoCa9CfC2LjG8ZRb7a/5HmU+L8HO fLKMku+n+Z9T/FL9or4b/CfwF4c+I+t30994Z16WGPTpdKj883IkjaVXUZHy7Fzn3FePhMsxGMrS oQVpR3v5aHt4zNMPgqEcRUd4y2t56m58FvjP4Y+OnhW58ZeELLUoNFiu3s1fUoBC0roFLFRk5UFs Z9Qazx2BqZfU9lVava+hrgMfSzGl7Wina9tTqvHXxB8LfDrR31nxRqK28RyIYFG6W5b+7Gg5J/Qd yKMFgK+YVPZ0I3fV9F6sWYZjh8tpe1xErLour9EfLHiD4oeO/Fujv4q13WZPhv8ACuQkW5gUSazr I54hB+4CMfMBx1BI5r6fD5ZhcLU9hSh9Yr9ekI+vc+TxGa4zGUvrFaf1bD9La1J+nb1/Gxn6HpUO jaJceNdZaT4d+AZx/wAfEkhuvEmv5yR5ty+54g3UJH83oVFaVqrrVFhqX7+qum1KHpFWTt3enqZ4 eiqFJ4ur/s9F9d60/WTu1fstfQh8R/EfT/AGi2F1dWF54O0nW3CaR4X0SMXfirxZITgFmYlog2Rl iS4zy6niuZ0VVm4uSrTjvJ6UoeiW/wCC8mdUasqdNNRdCnLaK1rVPNt/Df5y80dv4I+EHj3xnaLq PxMuD4P8NXJEq+BPC1263E4IHOp6mD507nnckbKvOCXxXmYrMKcJWo+/JfaktF/hjsl8vuPXwmW1 JRvVXs4v7MXq/wDHPdv5n0/4d8L+G/COnQ6P4X0Ox0rTIhhLawgWJB3yQByc9zyTXj1KtStLmqSb fme1So06MeWnFJeRuVBoFABQAcHrQBymq+EdPvZJL3T5ptJ1hh/x/adhGf2kQgpKvs6n2wea6qWK nBcs1zR7P9HuvkcVXBwm3ODcJ91+q2fzTPnrxFp1z4b1F7XWpofC99qL+VB4i0+HzdD1dz0iv7Ny VikbpnjP8Mn8Ne/h6kcRDmpL2ijvFu1SPnCS1aX/AA8ep87iaUsLPlqv2TltNK9OT7Tg9E33+6XQ 82k0q80rWJPC1gLfwP43nG+LQbv/AEzwz4lGf+XdH4hJ4+VdpBOOeteiqsalP28r1qS+0tKsPVrf 53ueU6M6NV4eFqFZ/ZfvUan+FP4b9lZo6rwZ8S9csdafwdeq3hzxrbna3hfX52msb70+x3Ry8W7+ FWLJ2UVzYzLqU6f1iP7yk/txVpL/ABR2dutrPudmCzSrCr9Vn+7qr7EneL/wS3V+id12Po/w5400 /X55tLubWfTPEdv/AK/Sb4BZE91I4dfRlJFfPYjBzoL2kWpQezW3/Afkz6XDY6GIk6bTjNbxe/8A wV5o60jr6VyI7GQkdqpEslVBgfSi4I8K3mvorHzAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3m iwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN 5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFg DeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzR YA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgDeaLAG8 0WAN5osAbzRYA3miwBvNFgDeaLAG80WAN5osAbzRYA3miwBvNFgQbzSKuPDnAoFuxd5pWHcer8Ur AShzQ0XcmV+KljROrHgVDLRZRunvUstFpGOR71DNEy4hNQy0W4zWbNEXEJrNmiPFP2lfHUnw8+B3 xC8R2twIdR+wm0tH7iaciJSPcby3/Aa7Mtw/1nF04Pa938tTizbEvCYKpUT1tZer0Pwk+Cfjb4fe APFF3rXxE+HkHjLSXsnt4dKutnlxyMynzSHBGQFIH+8a+8x2HrYimoUanI77n5zluKoYSq6lenzq 236n6sfsran8C/jVrGua54V/Z10TwvP4ZMLwavHFC0izvvwIyqgqwVSc+4r5HN4YvAxjCpiHLm6a 7H2+S1sHmM5Tp4dQ5ba6bnzF+3J8GPgx8F9H8Eaf4B8OSWfifWLmaeeeW+uLhvs8agdHcj5ncc9f lNerkGOxWOlN1pXjG3RLU8XiXL8Hl8aaoRtKTberenzPUf2Pv2RfhT8SPg5a+NviV4buL/VNUvZz aut5PbhLZDsGBGwByyuc9elcedZzicLivZYeVkkr6J6nbkGQ4XF4NV8TC7bdtWtPkfGn7Vek+JPC fx41q08QaK8ejaUbe00Kzu1Y276XAqiCOMn70e3O7BzuZ88k17eTyp1sGnTeru5PrzPc8DPFVo45 xqR92NlFPblW3/BPXrL4q/sk/GjVPDGn/FP4Tz+ALu3T7L/angySKGzfdtAM6iMNgEcHDbQTziuK WDzPAxlLDVfaLe0t/lqd6x+U5jKEcVR9m1peNrfPS5a/bvuNF8HN8I/gP4Qvrifwn4S0n7XELmUT OzTMfLLOAA2I1446NS4ejKv7XG1V703b7v8AglcUTjQ9jgKTvGCv9+34H6N/s9x2nwT/AGU/AV1q sGLj+z/t5th8rTT3LNKifUh1yewBPavnMbTlmmaTpwfW1+yWjPqcvqRynKIVKm9r27t6pHm2h2M/ jC81n41fFVje6NpLbLLTHA8u6nz8kKKeBGCQT6nrnBr3q81hIwyzAaSlu+y6t+Z89QpvGSnmuYe9 GGy6N9EvL+n1NfwnbyeKtQ1b44fFFhc6NoZKabphUeU8v8EcaHjCkrj1bBP3TWWKl9VhHK8DpKfx Prbq2/P8jbCR+tznm2Yawh8K6X6JLy/P0OU8Z/EJfDPhfVv2j/irFHfS2khs/CXhmQ4hlu2J2kL/ AHVILFup2E9Qoo9ioSWVYLS+s5dbf8H+uonXcovOMer20px6X/4Hf/gHYfsj/C3xDrC3H7SfxhuG 1T4oeLYQ+n/a0GNH0852LCh4j3gg8dE2jqzZ8fOsXTg/qGFVqcN/N+fe35nt5DhKtRPMMY71J7eU elu1/wAj7prwLH0gUWAKLAFABQAUANJIoE1cytZ0bTPEOl32i6zZx3Wm3cZjmglGQyn+vfPY1rRr Tw9RVKbtJbGVehTxFOVKqrxe6PjK60N7fULz4F+P7xrnRpCsnhvXbgAy2L/8shv67T9w+h46EY+v hW5oLNMIrS+3FbPv/mfFTocs3lOMd4/8u5PddtfwMeHSr34iWt78LvHZVfiHoJf+xtYlx5k2wcwS P1YEAMG69+o52dSOXyWOwv8ABn8Ueiv1SMI0pZlF4DF/xofBLq7dG/yZ0Hw98Qap4uifwV4qkaPx 5o25tJ1SU7ZnKfehkbqSMde4yTnHOOPw8MI/rNBfup/EumvVG2BrVMcvqtd2rQ+GXXTo2e1/Dj4m R+J7i78N6ziDxPZlg0bfKZgpw3H94HqPxrxsxy54ZKtT1g/wPbyvM/rTdCtpUj+P/BPW27V5SPZJ R0H0oA+ft59a+msfKcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWi wcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiw cwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwc wbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcw bz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwb z60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz 60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz6 0WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60WDmDefWiwcwbz60 WDmDefWiwcwb/U0WGpCh+etFguODY70rBccGz3oHckDdBmpsO5IrcdaTRVydW6c1LRSZOre9Sy0y 0je9Q0WmW0b3rNotMtxt71DRqmXYz05rNqxomXI2HFZtGiZ+c/8AwUi8VS6f4A8AeEYnwus6lNdS DP3ltkUf+hXCmvouG6XNWnUfRW+//hj5fiuu40KdJfabf3f8OfCvwR/aA8J/CTw5qWjav8F9B8W3 95d/aDqOsMjNGu0KI1DRPgDBPB5Jr3cdl1TGTU41nBJbL/hz53Ls0pYGm4SoKbbvd/8ADM/VH9jv 4zWvxesfGtzo3wp0XwbomnTQIzaOygXk7KxO5VjQfKoXnn71fJZ1gng3BTqubd9+i+9n2uQZgsfG bhRVOKtt1f3I/PH9vvxi/i79oC50C0lMtt4dsoNNSNecTN+8cD3zIo/CvpOHqHscEpv7Tb/Q+V4o xHt8e6a+ykvnufr74c8J+Jfh3+z1p3hPwNFEvjPRvDXl2KTIGRr8QluV6HMxPB9a+Kq1qeJxzq1v glLX0v8A5H3tGhUwmXqlQ+OMdPW3+Z+UOl/tv+OX8QXeh/tD+A9H8W+GoUkt7jQ7rSobee2nBHzf OpwRggqQOueor7CWQ0eRTwM3CXe7asfEU+JK/tHDMaanHZppJp/M8b8OfDW7/aY+M1xD8Jvh4fDP gu7uozPHEzzWujwDaJHeQjAYjLCMdzhRiu2rillWE/2mpzTS+bf9dTz6ODecYx/VKXJBv5RXXX9C T4mD/hcv7Utz4c0Vml0671y28O2HO7bawFLZSD6bYy2felhf9hy5VJ7qLk/V6jxn/Cjmjpw2clFe i0P2Q+PUIig8JeFLBPL0yzg3pCvQAARoPwVT+dfMZDp7SvLd/wDDn13Ekreyw8dkr/ojF+Kun/2V 4X8A+DbNdtrBa/aplX+OVhjJ/Ev+dbZXU9rXrYmW7dl6f1Y5s4j7DD0MLHZK79f6uSfEXTHs/C/w 58CWQ2wmBbmZRwHlfgE/iz/nRl9RTr18VLvZeiHmkPZ4fD4OHa79X/TPhj9t3VrXWPjd8Ifgn9rS 08K6DDYwz+ZIEiSS5kUPIxPAxGF5PvXdkal9VrY1q85Nv7un3nn8QuLxmHwCdoQSX37v7j9Z7T4k /CiwtbaxtPiF4VitLeNYook1e1AjRRgKPn6AACvjHhcTJuTpy18mfeRxmEilFVY2X95f5lj/AIWp 8MP+ij+F/wDwcW3/AMXS+p4j/n3L7mV9ewv/AD9j/wCBL/MP+FqfDD/oo/hf/wAHFt/8XR9TxH/P uX3MPr2F/wCfsf8AwJf5h/wtT4Yf9FH8L/8Ag4tv/i6PqeI/59y+5h9ewv8Az9j/AOBL/MP+FqfD D/oo/hf/AMHFt/8AF0fU8R/z7l9zD69hf+fsf/Al/mH/AAtT4Yf9FH8L/wDg4tv/AIuj6niP+fcv uYfXsL/z9j/4Ev8AMQ/FT4YYP/Fx/C//AIOLb/4uhYPEf8+5fcxfXsL/AM/Y/wDgS/zGf8LU+GJ/ 5qP4X/8ABxbf/F0/qmI/59y+5/5B9dwv/P2P/gS/zD/hafwx/wCij+F//Bxbf/F0/qeI/wCfcv8A wFh9ew3/AD9j/wCBL/M8b+NY0DxboeheLPDOr2OpJZ3TWjXum3CTqCRu270JGQVzjr81e1kk6lCp OhUTV1ezPnuIY069KniKTTs7XTv/AFscd44W5N74B+IloCmp3NtG80i/xTwkAn8RgV3YLl5a2Dl8 Kbt6M87MJPmoY6PxNK/qib4maf8A2N470TxppC+U17HDfjZ2kGN35jGfqaWXVPbYWeGqdLorNY/V 8ZDFU9OZKXzPFP2gPFU3w1+M2keJ9Ik8k3tvb6qqA4DEkq4Ps2059cmvYyHCrMculRqa2bj/AJfc eNxFjXlmaQxFN25kpf5/efojpGq22t6Tpes2bZtL+2iuYjnOUdQw/Q18DVpOjUlTlvFtfcfo9GtG vSjVjtJJr56muCMD6VnY0R88Zr6c+SDNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAz QAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAz QAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAz QAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQAZoAM0AGaADNABmgAzQCYu73oHcduHqKQhd3v SGmPV+OtIolVxzQx3JlapZSZYRxxUFplpHFSy0y0j+9ZtGiZcRxUNGiZcjfpzWbRomXY36c1m0ap mH4i0CbXvsPk3NjCYN+TeadHeZ3bfu7iNvTnHXj0rSjVjSvzxbv2djKvSnWtySSt3Sf/AAxgp8Pr 0j/kJ6J/4T1v/wDFVo8VS/kf/gb/AMjFYOv/AM/F/wCAL/M2dP8ACviTTEaLTfE+n2cbtuZLbRIo wx9SFcc1nLEYeWsqTf8A28/8jaGGxMF7tZL/ALcX+ZFJ4C1S4uGu59a0aS7dt7TSeH4Gdm9SxbOe nNL61RSsqb/8Df8AkP6nXk7uqr/4F/mdCujeN/8AoeYP/BQn/wAcrF1sL/z5f/gT/wAjb2GM/wCf 6/8AAV/mclrXwgtfE14NR8R/8IxqmoDGLnUfC1rPJ/30zE1rDMIUlywhJLym/wDIxqZbUrPmqTi3 500/1Om0vwd4j0W0Sw0bxPpthYp923s9ChhRfoquBWU8Th6j5p0m3/if+RvDCYmmuWFZJeUF/mfN nx217xz8Fh4Z1zwzY+Fr77bLKkl1NoEcUlvKoBBVkcHkFufavocjwmCzd1Kdbmja20t180fM8Q4z H5IqdShySUr6uGz+TJb/AMX3/jLwP8OvG+uR251PULSWK6NuhRFmjlYEBSTjjBxnvTp4SGDxVfDU r8sWrX7NGGJxVTH4TDYyrbmkmnba6Z2nxUvYJ4vB+tKA1reWC7X7ZGCR/wCPVx5XBxdWl1TO3O2q io1ls4knj7U7cT/D7X9oa0ms4WD9sowJH60sBTlavR6pv8R5nNOWGr9Gl+By3xX/AGIvhf8AGbxx qnxD8ReIvEUOp6kkQaKxmhWJVRAq7Q0ZPQA9a5cHn2JwFFUIRVl3v/mejjuHMLmNd4mpKV3ba1vy POf+HZ/wT/6Gnxb/AOBFv/8AGq6v9asX/JH8f8zl/wBTsF/PL71/kH/Ds/4J/wDQ0+Lf/Ai3/wDj VH+tWL/kj+P+Yf6nYL+eX3r/ACD/AIdn/BP/AKGnxb/4EW//AMao/wBasX/JH8f8w/1OwX88vvX+ Qf8ADs/4J/8AQ0+Lf/Ai3/8AjVH+tWL/AJI/j/mL/U7Bfzy+9f5B/wAOz/gn/wBDT4t/8CLf/wCN Uf61Yv8Akj+P+Yf6nYL+eX3r/Ib/AMO0fgn/ANDT4t/8CLf/AONUf61Yv+SP4/5h/qdgv55fev8A IP8Ah2j8E/8AoafFv/gRb/8Axqj/AFqxf8sfx/zD/U7Bfzy+9f5B/wAO0fgn/wBDT4t/8CLf/wCN U/8AWnF/yx/H/MP9TsF/PL71/kfOv7Un7Gfwq+B3wk1Px1oHiDxBca4l5bWltBqE0LROZH+bIWNT kIrnr2r0spzzE5hiVRnFJWb0v/meRnXD2Fy3COvTlJyukr26/I9s/Zw0g+Ev2SvCJ1GMLNr+sT6j GrcZjO5VP5Rg/jWWJbr5tNx2jFI1oR9hklJS3lJv8z3zxddQWngjwBbTKPOlSaYIeysRj881zYWL liqzXkjbHWhgsPB76svfFK7gtbbwbYzKPtCWCllPbIUfzBqMsi5OrNbXNM5ajGhB7qJ7naaTpl5p mktqemWtxcJaxJuuIVkYfKOMkHjOa8WdWcKkuSTSu9mfSU6NOdKHtIptJbq5sKIoY44oo1SFAFSN BtCgDgAdhWV23d7m6tFWWxA2uafEzRSTqHQ7WG4cEU/ZSeqRm8RTWjkvvPBd49a+msfK3DePWiwX DePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiw XDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWi wXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePW iwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDeP WiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDe PWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXD ePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwXDePWiwX DePWiwXDePWiwXDePWiwXDePWiwXFDA96LFJih+ozSaBsdvFKwXHK4pWHckDYotcpMmDgEc1LRSZ MripaKUi0knvUNFqRZSQVDRopFxJR61DiWpF2OXpzWbRqpF1JBWbiaKRcSUcc1m0aqRdjkFZtWNF IuJJUNGikWkk6c1DRomWVk6VLRaZMrjrUNFJkysKmxRwvxL8D2fxD8I6h4eudq3DYmtpW/5ZTL90 /Q5IPsTXdl2NlgMRGtHbZ+hwZngYZjhpUZb7r1Pk/wAH+H79/DOvfCvUYTb63aXDX2lrL8uZwMSQ 5/2wMjtnmvqMXXgq8MdB3i1aXp0fyPkMHQlKhPLqitNO8fXqvn0LvhXU/wDhPPB+o/De7byfF+ju 9zpcc3ytLtz5kHPRuvH+BqMVT+o4mONjrTlpLy7M0wlT+0MLLAy0qQ1jfr3RJ4Uuz8QPBWp/D6Y+ X4x0J3u9Nhm+VplGfMh56EHPH09DSxUFgMTHFr+HPSXl2Y8JL+0cJLBS0qw1j590fRPwb8axeK/C sVlcsU17R8Wl5bycOu3hWI68gY+oNfP5vg3ha7lH4Japn0uS45YvDqEvjho0euV5J7FwoHcKAuFA rhQFwJ9TTsK40t6U0gGlvWmK5+Vv7V+r6j+0f8aPBH7NHgGbztP0e4N94g1CL5orR8YYuRx+6jLf V5AvWvrcnhHK8JPH1t5aRXf/AId/gj4nPKks3xlPLaD0i7yfb/hl+Lse630Fj4v8VeG/hj4KUR+C /ClslmbhMbIoowFkcnp0UKD3PPeroJ4DCzxVf+JUd7euy/UWIazHFwweH/h01a/Sy3f6FuS/s/iP 8Ry1rIkfgPwzEolumOI1gi56/wC0Rgewz2oVOWX4P3v4tR7dbv8AyCU4Zljrx/g01v0sv8/yM7TL y4+MXxRlu4I2Hh2zdWdiMBLdD8o/3nI6e59K0qQjlOBUW/ff5v8AyMqcpZzmDml7i/Jf5n2M0gAA HA7Cvk7XPs2yhfahbWFrdX97KsVnbRtNLIxwFRRkn8ga0hTc5KMVdswrVoUISq1HaMU232S1Z+Nn iT9obxfqPiHXtQ08qLC6vZ5oBuI/ds7Ff0Ir9lwvDmEp0IQqfEkk/W2p/NmNznEYnE1a6k1zSbtr pdt2+R+ju8V+fH7XcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN 4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAX DeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQ Fw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8 UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXDeKAuG8UBcN4oC4bxQFw3igLh vFAXDeKAuG8UBcN4oC4bxQFw3igLhvFAXF3j1oHe44Se9TYL2F3j1osO48SDpmk0FyQSAd+KLXKu TLJjFS0UmTrL71DRakWVmFS0WpFpJuetQ4lqRbjmHHNQ4mikXY5xxzWbiaKRdjnHHNZuJqpFyOcc c1m4mikXEn96zcTVSLiTdKhxLUi0kw45qHE0Uiys1S0WpE6yg1DRakTLL05qeUpSOG8Y+C7XxKi3 1lKtnr8IBiuwPvY6B+/0PUV24TGSw3uyV4PdHm4/LoYz34vlqLZ/5nyn488P3l3rEF7qMn/CLfEy 3cNb6sx8uy1dl+6TKOEl4+90P8QHWvp8FXjCm4wXtKD3X2o/LqvL7j5bHYecqilUfssQtpfZn8+j 8/vOavtTm8Sa/avqjjwT8cbIrJHPc4gs9cI4Vw4+VZG6bgSj9M+nTCksPSap/vsK+2sofLe34o5p 1pYmsvafucXHq9Iz+eyf4M9D0rX7zVvFUd/axR+EfjlbKI7zRdSBis/Ekf8Ast03NjgjPOOvUefV oRpUHGT9rhXtJaygejRxM62IU4r2WLW8XpGovL1Ppjwl8QtN8TSyaTeW82keLbdc3OhagAk0fq0f aWP0dCR64PFfOYrL54Ze0i+am9pLb59n5M+oweY08U3TknCot4vf5d15o77fXDY77ibx/eosFxC/ vRYLjS49TTC4nmD0oFchlnSJHlkdUiQFmdjgKB1JPpTSE5JK58SfFH9oTxL47vdU+F/7NMcepa5H mHWPHTsF0zw7Hj52E5+VpQM4xkDqAxHHv4PLIUEq+O0XSH2pfLsfN47NqmIbw2X6v7U/sx+fc84+ GXga08IeG9Y8IfCO7N1PqBL+LfitqpMSXLc70hkbnYCW6Ek5JJyd1ezWsqka+PWq+CktX5XX9foe HQT9nLD5c9H/ABKz0Xmk/wCv1OoOo6bB4Zu/C/w8vl0vwGG2654+1MGIX7DgxwD7z9wFXPpxyTap zddV8Wuar9imtbeb7erJdaCoPD4J8tH7dV6c3lHv6Iz9EsNe+JFhD4K+GemXGk/DSGXdea7frsk1 SQHl3/vdOI14HcjtpWnSy+bxONkpVntFfZ8v82Z0I1sygsLgIuFBbyf2n3ffyS+Z9f8AgzwhofgP RIdF0WI7Qd81xJ/rLiTHLMf5DoBxXymLxVXG1HUq/JdEfYYPCUsBS9lSXq+rZ0zziudROhyPiT9s L4yQ+HfDR+G+i3YOv60ga+Mbc2tp6HHQuRjHoCa+z4Syl4iv9dqr3Ibecv8AgH51x5nioYf+zaL9 +fxeUe3/AG9+Xqj8qpNctY5HjMigqSp+Ydq/ULSZ+TxwdSSTSP2z3e9fkR+4hu96ADd70AG73oAN 3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96A Dd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbve gA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG7 3oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9AB u96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQAbvegA3e9ABu96ADd70AG73oAN3vQ AbvegLhu96B3Hh896mwri7hRoO7HiTtSGmSBx+FFilImWXGOalopSJll96hopSLCTe9S4lqRaSYe tQ4lqRaSfpzUOJoplyOcDHNQ4mimXI7gDvWbiaKZcS4HrUOJqplyO5HrWbjY0Uy2lyPWocDRTLS3 A9ahxLUyylwPWocS1MsLcCpcS1MmW4HrU8pSmVNSsdM1qzm0/VrG3vLGUYeC5QOrfgaqnOdGSnTb T8iakIV4uFRJp9GeKeIvgdpd/YvYaLfr/ZJJZdC1yM31ohP/ADxYkSwHryj/AIV7GHzmcJc1Re9/ NH3ZfPpL5o8PFZFTqR5KUvd/ll70fl9qPyZ5pd/C3xlYWMWiXGnrq3h+I/utK1d21KC397W6XZdW /twwFejHM8NObqp8s31j7rf+KLvCX4HlzyrFU4Kk488FtGXvJf4ZK04/idNZ6L4vNraafq+iX+pa fbsDBb65uuJbQ+ttqEIWdMdvMjzjjdXNOth+ZzpzUW93HRP/ABQd4v5P5HXCjieVQqQcorZS1a/w zVpL5r5nqmjXfjSxVIozd3MAHFrrse6Qey3UQ+b/ALaID6k9a8ytDDTd3ZPvHb/wF/o/kerQqYum rK7XaW//AIEv1XzOzt/ElxnytS0LULWXoSkf2hPwZMn9BXHLDLeE0/w/M7o4qV7VINfivwN6O7SZ FkTcFPZ1KH8iAaxcLOx0KfNqiK5vYrWJ5pRIyL2ijaVvwVQSfypqF3oJ1LK55lrXj3xVL5tr4M+H uo391yBd6w4022X3O4GUj2EddVPC096tRL01f+X4nFUxlX4aNJt+ei/z/A8S8SfDT4j/ABJVl+KH iGfUNHJyfC+htLpWlEek7ruuroe2UU+gr06FbDYbWirPu7Sl8r2ivxPJxFDFYv8Aju6/lV4x+dry l+BZb4eGx0u00VPDTXehWeDb6Fb2x03SIGHc2sOZJznnMrc8kgV008ZBScozUW95X5pv/t52Ufkj lq4KbioTg5RW0bcsF/26ruX/AG8xuoeAvHfiz7Nb31nZjTYMeRbaviDTrUDp5enW5/eEdvOkx7Vp TxuFwt3Bvme7jrJ+s5bf9ur5mdTAYzF2U0uVbKWkF6U47/8Ab0vkdZp3wS8PSXdpqvjnU7vxVqVs NsEV+Fhs7UdhFaphFHsc1y1M4rKLp4WKpp721k/WT1Z108jouSqYuTqyW19Ir0itEeyI1vbRJb20 SRQRgKkUahVUegA6V5LTk7yd2eymorlirIie5HrVcpLmfOPx2/aH8P8Awi02WwtZIb/x1cR5tdMB yIc9JZ8fdUf3erdB3I97J8jq5nPmlpSW7/Ref5HzGf8AEtHKKbhD3qz2Xbzf+W79NV+PviHxLrHi fWdQ13Wbua/1u/lMksrZZpXJ4AHp0AUdOAK/UKVOnhaapUlyxiv6/wCCfjNWVXG1nVrO8pO7Z+wP g/8AY88GJ4S8LJrug2M2trp1sLyYop8yfyl8xundsmvyPF8U4uWIqSpVGouTsuyvp+B+44PgnBLD 01Wh7/Kr6ve2v4m1u969Gxw3Dd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwX Dd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bvei wXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bv eiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4 bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70W C4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd7 0WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwXD d70WC4bveiwXDd70WC4bveiwXDd70WC4bveiwKQu/wB6ViuYUSEdTRYLjt5pWC44SEd6VguSCSix XMSiUj2pOJSkSib3qXEakTLMfWpcS1IspOfWocS1MsLcEd6lxLUy2tz05qHAtTLKXPvUOBoqhcS6 96hwNFULKXfTmocC1ULa3fTmocDRVCyl10GahwLVQsLd+9Q4FqoWFu+2alwL9oSrd5/ipchXtCUX We9TyFe0JPtY9aTgP2g8XfqaXIP2gv2oetHIHtA+1D1o5GL2g03fvxRyD9oMN2Ofmp8hPtCNrrPG 6q5BOoRNd+9NQJdQha796pQJdQrvd9fmqlAh1Cu1371agQ6hyXinx14X8GWEmp+KvEFlplmg+9dy hC3so6knsK6KGEq4mXJSi5PyOTFY+hg489eaivP9Fuz4E+LP7bE91HcaL8KLV7eJgUbX7+PDkesM R+6f9p/yNfX5dwvGNqmNf/bq/V/5fefB5txjOonSwCt/ee/yXT5/cj4D1DWL3Uru61DUb2e71C4c yS3NzIZJJWPdmPJNfXR5acVCCsl0R8NNTqzc6ju3u2fRv7IXwzk+Kfxq0Bbm3aTw94dZdYv3wduY 2zChPq0gB9wjV87xPmX1HATSfvT91fPf8PzPreDcoePzKE5L3KfvP5bL7/wufv7jHA4Ffjp+8HxR v9q+/sfmfMg3+1Fg5kJJMkMZlndIoh1kkYKo/E8UWvsHMluZZ8Q6ACQ2v6UGHUG+hGP/AB6q9nLs yfaR7r7w/wCEi8P/APQwaT/4HQ//ABVHs5dmHtY9194f8JF4f/6GDSf/AAOh/wDiqPZy7MPax7r7 w/4SLw//ANDBpP8A4HQ//FUezl2Ye1j3X3lKbxp4Rt5Gim8VaOkq4ypvYuO/96mqU30YvbQWja+8 j/4TjwZ/0Nmj/wDgZH/jR7GfZh7an/Mg/wCE48HdvFmj/wDgZH/jR7GfZh7aHdC/8Jv4O/6GvSP/ AAMj/wAaPYz7MPbQ7oX/AITbwd/0Nekf+Bkf+NHsZ9mHtqf8yD/hNvB56eKtI/8AAyP/ABo9jPsw 9tT/AJkL/wAJr4Q/6GrSf/AuP/Gj2M+zD21P+ZCf8Jr4Q7eKdJ/8DI/8aPYz7MPbU/5kO/4TTwj/ ANDRpP8A4Fx/40exn2Ye2h/MvvD/AITPwl/0NGlf+Bcf+NHsZ9mHtqf8yD/hMvCXbxPpX/gXH/jR 7GfZh7an/Mhf+Ex8Kf8AQzaV/wCBcf8AjR7GfZh7an/MvvD/AITHwp28S6Ufpdx/40exn2Ye2h/M vvFHjDwsf+Zk0v8A8C0/xo9lLsw9tDuh3/CXeFv+hk0v/wACk/xo9lP+UPbQ7oP+Et8L9vEemf8A gUn+NL2U+zD20O6D/hLfDHbxFpn/AIFJ/jR7KfZh7WHcd/wlfhj/AKGLTf8AwJT/ABo9nLsw9rDu H/CV+Gu3iHTf/AlP8aPZS7MPaw7i/wDCU+G+3iDTv/AlP8aPZS7MPax7i/8ACUeHO2v6d/4Ep/jR 7KXZh7WPcP8AhJ/DvbXtP/8AAhP8afspdg9rHuL/AMJP4dPTXdP/APAhP8aXs5dmP2ke4v8Awk3h 7/oO6f8A+BCf40ezl2Ye0j3D/hJfD56a5Yf+BCf40ezl2D2se4v/AAkegHprdh/3/T/Gj2cuzD2s e4o8RaCf+Y1Y/wDf9f8AGj2cuwe0j3D/AISLQu2s2P8A3/X/ABo9nLsHtI9xf+Eh0P8A6DNl/wB/ 1/xp+zl2D2se4v8AwkGi/wDQXsv+/wCv+NL2cuwe1j3D+39F7avZf9/l/wAaPZy7B7SPcX+3tF/6 C1n/AN/l/wAaPZy7C9rHuKNd0c/8xWz/AO/y/wCNHs5dh+0j3F/tzSP+gpaf9/l/xo9nLsHtI9xf 7a0ntqlp/wB/l/xo9nLsL2se4f21pX/QStf+/q0ezl2H7WPcX+2NL/6CVr/39X/Gj2cuwvax7i/2 vpnbUbY/9tVo9nLsP2ke4v8Aa2m9tQtv+/go9nLsL2se4f2rp3/P/bf9/BR7OXYPax7jv7U07/n/ ALf/AL+Cj2cuwe1j3D+09PPS+t/+/go9nLsHtY9xf7Ssf+fyD/v4KXs5dh+1h3D+0bLteQH/AIGK PZy7C9rHuL/aFn/z9Q/99iq9nLsP2sO6FF/aH/l5i/77FT7OXYPaw7oX7ba9riL/AL7FP2cuwvaw 7oX7ZbHpPH/30Kfs5dg9rDug+1wf894/++hR7OXYPaw7ifbbYdbiP/voUezl2D2sO6D7da/8/MX/ AH0KPZy7B7WHdDft9p/z8w/99ij2cuw/aw7oP7Qs+93D/wB9ip9nLsL2se4f2jY/8/sH/fYo9nLs HtY9xP7SsO97AP8AtoKfs5dg9rHuN/tTT/8An9t/+/go9nLsHtY9w/tTTx1v7f8A7+Cj2cuw/aw7 if2tp3e/tv8Av4KPZy7C9rHuH9raZ31C2/7+ij2cuwe1j3G/2xpf/QRtfxlWj2cuw/aR7h/bOlDr qVr/AN/V/wAaPZy7B7SPcT+2tJ/6Cdr/AN/V/wAaPZy7C9rHuJ/bek99UtP+/wAv+NHs5dh+0j3D +3NH/wCgraf9/l/xo9nLsL2se4h13Rx/zFbP/v8AL/jR7OXYftI9w/t3Rv8AoLWf/f5f8aPZy7C9 rHuJ/b+i/wDQXs/+/wAv+NHs5dh+0j3GnxBog/5jFl/3/X/Gj2cuwe0j3Qf8JDof/QZsv+/6/wCN P2cuwe1j3E/4SLQv+g1Y/wDf9f8AGl7OXYPaR7h/wkegjrrVh/3/AF/xo9nLsHtI90J/wkmgf9By w/8AAhP8aPZy7MPaR7if8JLoHfXLD/wIT/Gn7OXYPax7h/wk3h7/AKDun/8AgQn+NL2cuzD2se4n /CT+HP8AoPaf/wCBCf40eyl2Ye0j3E/4Sjw5317Tv/AhP8aPZS7MXtY9xP8AhKfDf/Qf07/wJT/G j2UuzD2se4f8JT4b7+INO/8AAlP8aPZS7MftYd0J/wAJX4ZHXxDpv/gSn+NHs5dmL2sO4n/CWeGf +hi03/wJT/Gj2cuw/bR7oX/hLvDHbxHpn/gUn+NHspdmHtod0L/wl/hf/oY9M/8AApP8aXsZPow9 tD+ZC/8ACX+Fh/zMul/+BSf40eyn/Kx+3p90O/4TLwsP+Zl0v/wKT/Gj2M+zBV4d1948eM/CvbxL pf8A4Fx/40exn2Y/rFP+ZfePHjPwr/0Mulf+Bcf+NS6MuzGsRT/mX3kq+NfCn/QzaV/4Fx/41LoT 7Mf1mn/MvvJh428KDH/FTaX/AOBcf+NL2E/5WWsTT/mX3k6+N/Cn/Qz6V/4Fx/41LoT/AJWUsVS/ mX3k6+N/Cn/Qz6V/4Fx/41Lw8/5WUsXS/nX3lhPHHhT/AKGfS/8AwLj/AMal4ef8rKWMo/zr7ywn jnwp/wBDPpf/AIFx/wCNQ8NP+V/cUsbR/nX3osr458K/9DNpf/gXH/jUvDT/AJX9xax1D+dfeiwv jnwr/wBDNpf/AIFx/wCNS8NU/lf3FrH0P+fi+9FhfHXhX/oZtL/8C4/8al4Wp/K/uH/aGH/5+L70 TDxz4V/6GbS8f9fcf+NT9Wqfyv7iv7Qw6/5eR+9F238YeHrgN5HiDTZAvUrdx8frUvDTW8X9xpHH 0JfDUT+aLg8T6Memtaf/AOBUf/xVR9Xn2Zf1yl/OvvRKPE+j/wDQasP/AAKj/wAaX1efZj+uUv51 96FHibRv+g1Yf+BUf+NH1efZj+u0f5196H/8JNo3/QZ0/wD8Co/8aX1efZ/cH12j/OvvQn/CT6N/ 0GdP/wDAqP8Axo+rz7P7g+u0v5196GnxPo3/AEGrD/wKj/xp/V5dmDxtH+dfehp8T6N/0GtP/wDA qP8Axp/V5/ysn65R/nX3ohk8U6Iisz63p4VRkk3cfA/OmsPP+V/cJ42itXNfejm9R+KXgHS1Mmpe NtFtkHOZb2MY/WtoYGvUdoQb+TOaebYOHxVor/t5Hm2sftR/BHR42eTx7Z3m3jbpivdE/QIK7aeR 42o7Km166fmcVbiPL6O9S/om/wBLHjHiT9unwLZCSPw14Z1XVJRnZLcbbaJvrk7h+VejR4Yry1qz Ufxf+X4nkV+MaELqjTcn56L9T5s8Y/tnfFfxEstvojWHhy0fgGwTzpx/20fj/wAdr2cPw7g6OtS8 356L7l/meFiuKcfiLqlaC8lr97v+Fj5d1rxLrHiC+k1PXdWu9R1Fyc3F5M0rcnOASeB7DAr2qUad CPJTioryPnqkqteTnVk2/PUw3u+vNNzEqQyE3N7c29nZwSXF5cSLFDBCpZ5XY4VVA6kkgAVnOqoJ yk7JG9LDyqSUIq7Z/Qd+yZ8CV+B/wytbTVIoz411srfavKMExyFfkgB/uxr8vu2496/IM/zV5pin KL9yOkf8/mfufDeTRyfBqMl+8lrL/L5fnc+pa8Q+iPh9nCqWZgqqCSzHAA7knsK/QrH5fzHw18ZP 2wrLQbi68OfC6KDUdSjyk2tzjfbxN3ES/wDLQj+909M4r0cPgHNc1TRdjzMRmKg+Wnq+58E+J/iP 488Z3Mt14m8W6nfPJ1je4ZYwPQRrhcfhXpwo06ekUeVUxFSp8TOGMMTElo0JPUlRzWpnzy7ieRB/ zxT/AL5FAc8u4eRB/wA8U/75FAc8u4eRB/zxT/vkUBzy7kscUXaJMf7ooDmb6ltYYeP3Sf8AfIqe pV2TJDDn/VJ/3yKG2PoWFgg5/cp/3yKBdCZYIcj9yn/fIoETpBDn/Up/3yKAJhBBtP7lP++RQKyJ Vghyf3Kf98ihMViwsMOf9Un/AHyKLsdkTrBDgfuk/wC+RSuwsiZYYef3Sf8AfIouFkWFhhx/qU/7 5FFx2LEcMPH7pP8AvkUAkXEhiwf3Sf8AfIqS0kWRDFj/AFSf98il1KtoW44YuP3S/wDfIqRpFtIY sf6pP++RSuUiykMX/PJP++RQPqWY4ov+ea/kKm5SLaRRY/1Sf98igosLFFn/AFa/kKGBbjii4/dr +QpdCkTiKPcP3a/98ii+g7FpI4/+ea/kKALkcUef9Wv5ClcLFhYo8/6tfyFDYFqOKPA+RfyoAtLH Hu/1a9PSi7GiykacfIv5UMmxbSKP+4v5CkMsCNMj5F/KgLalpI48/cX8hSAtIkfHyL+Qo6gTpGn9 xfyp3YFxETJ+QflQgLKonHyj8qSC2pcVE4+UflQJFpETj5R+VFxltUT+6PyoJ6lqNE4+UflTCxaC J/dH5UkxNalpEXP3Rj6UNgXUVcjgUmMtIBnoPyoEy4oHHAoAtRqvHAoJaLiKuB8o/KgC7GB6CpuJ k7AY6UICo4HoKaGUpAvPA/KmBTkA9BQNIquBjoKAsU3UfMcDr6UMZUdVyfkFAym6J/dH5VSEVnRc fdH5UrsEVHRP7o/Ki7HYrOi4+6Pyo6DRTkRf7g/KhMZVkRMH5R+VMRVZEx9wflS6jSKkiLgfIufo KBlRo48n5F/KnfQSK7xx8/Iv5ChAVXjT+4v5UBYrvHHg/Iv5UAiq8aDPyL+VAFVo48f6tfypjS1K pjj/AOea/lQIqyRx8/u1/KgCuYo+f3a/kKbBIqvFHk/u1/IUrgVJI4/+ea/kKAK5iiwf3a/98inc Co8UXH7tfyFBLKzRRY/1a/kKYivJFFz+7T8hQJlR4os/6tfyFNEsrPDFn/VJ/wB8incRWkhi/wCe SfkKZLRUeKLP+qQ/8BFNMhorvHDx+7T/AL5FNMGis8UX/PFPrtFUmZtFdo4v+eSf98imQ0r7ETxw g58lP++RTuwsiEpBg/uU/wC+RTuyOUQpDkfuU/75FHMxOKG7Yef3Kf8AfIquZkuAwCDA/cx/98in zMjk8gPkZP7qP/vkVXO+4vZrsNzBz+5j/wC+RVKb7kumuwZgyP3Mf/fIqud9yHTQm6AZ/cp/3yKa qPuJ00NaSDn91H/3yKtVH3IlTGGWDj90mP8AdFWqj7kOmyEywE8xRn6qK0VV9zPkkuoCW34/cx/9 8in7V9yeWXdjxLb/APPGP/vkU/avuTyT7seJbf8A54x/98in7V9w5Jd2L5tv/wA8Y/8AvkU/avuL ll3Yebb/APPGP/vkUe1fcOWXdjTLBj/Ux/8AfIpe1fcfJPuxplt/+eMf/fIpe1fcfJPuxhlg7RRj /gIpe1fcrll3Y37RGp4VR9BS9ow9m+o03fX5qnnGqRE10T3qecpUiFrn3qXM0VMha596nnKVMjMz OVRQWdjhVUZLE9AB3NS59TSNJydkj9hf2Jf2Q7rw7Jpvxk+KWm+XrrKJdD0O5X5rIEf8fEynpIQf lX+EHJ56fn3EefqvfB4Z+79p9/JeR+n8LcNfVrY3FL3vsrt5v9PvP1Jr4w+9CgD8KP2u/jVc6VF/ wqzwzeGO7uYll1i5hbDRxNykAI6Fhhm/2SB/Ea/VsDh1L95L5H4zj8Tyr2UPmfnNwPpXqnkBQAUA FABQAUASJ3oAtL1FT1KLC9aGUWF70hdCZe1MROnWkBMPun60AyRetAFhetAE69B9aBEy96ARYX7o oGWY+1Jgi2vT8ak0RZH3aOo+haT+GpGi4nSkykWE6UdB9SzHUlIuL0oLJ160mBcj7UxonH3xS6DL Sf1pIC3H1NIZYHUU2ItR9qQFlfvfhQNFpP4aBFuOgCwOooDqWU/pSQFpO1HUCwlHUC5H1NCAsDt9 aEHUuL2oEi0nakMtr2p9iepaj7UwLQ6ikhdS0n3qTGW0/hpMC3H1pgXF7UCLUfagTLkfagRdj71P UCdulCAqP2poCm9MClJQNFV+lA+pTfv9aQyrJ2pgUmpoCu3SmPoVXoDoVX6VPQEU5KaGVZOhp9Q6 lY9DS6gupTfoPpT6gVW60ug0QP0oQim/9KOoEDdKYIqv1agbKp6GgEVTQIqyd6AK56GmwKr9WpDZ UkoEQHoaoEVH7UyWVW6UAQSd6BMpvTRDKz9aoRWkoJZTkoQitJ2poRWfjPNMhlVjirIa1IXbnrQF iEt1pk2Imbkc0gaI2c+uaYrEBfpxTuKwxpOtA7ERlPNO5PKM805HNVcXKhhmPNCYcqImmPrVJkuK IjcHPWmpEOJWM5z1q+Yh0xRcH+9RzC9mL9oJ70+cXsxftBo5xezHfaPcUc4ezENx7ijnD2Yn2g+t HOPkE+0UOYKmNNwfWlzj9mNM5PejmHyDTOaXMPkGGbPelzD5LDDMeeeKTZXIei/Df4TfEf4uasmj /D7wrearNuAkuI02W9uCcbpJT8qj8a48XmGHwUOevNL8/uO/BZXicwnyUIN/kvVn7Ofs1fsL+Evh LLp/jH4gSweI/iDFiSFNubPTH9Y1P33H99uh6Doa+AzfiOtjr0qHu0/xfr/kfpWS8LUMutWr+/U/ Bf5vzPv2vmj60KACgD+TLxd4jvPF/ifX/E+oMTdandSXLBudgZiQo9lGFHsK/aIRUIqK6H4JUm5z cn1OcqyQoA9S0/4G/GvVrCx1XSvg/wCN73S72FLi2vLTw/eyxXETqGSSN1jIZWUghgSCDmuOWYYO EnGVaKa3XMv8zthlmNqRU4UJtPVNRdmvuLn/AAz78e/+iIeP/wDwmr//AONVP9pYL/n/AA/8CX+Z X9k4/wD6B5/+Ay/yD/hn349/9EQ8f/8AhNX/AP8AGqP7SwX/AD/h/wCBL/MP7Jx//QPP/wABl/kX rH9mv9oTUXkjtfgn41DIMn7TotxbD8DKqg/hmplmuBhvXj96f5FwybMKm1CS9YtfoayfsrftID/m i3in/wABB/jUf2zgP+f0fvNf7BzH/nzL7mTj9ln9o4Yz8FfFPH/ToP8A4ql/bGA/5/R+8f8AYWY/ 8+ZfcTL+y3+0aDz8FvFP/gIP/iqP7YwH/P6P3j/sPMbfwJfcTj9l39oz/oi/in/wEH/xVH9sYD/n 9H7weR5j/wA+JfcSL+y9+0V3+DHij/wFH/xVH9sYD/n9H7xf2HmX/PiX3EqfswftFc5+DHigf9uo /wDiqP7XwH/P6P3i/sPMf+fEvuJR+zD+0SAQfg14o/8AAUf/ABVH9sYD/n9H7w/sPMv+fEvuJR+z H+0QP+aNeKP/AAFH/wAVQs3wH/P+P3i/sPMv+geX3Ew/Zl/aGz/yRrxP/wCAo/8AiqP7XwH/AD/j 94v7DzL/AKB5fcTL+zP+0LgD/hTfif8A8BR/8VR/a+A/5/x+8f8AYeZW/wB3l9xIP2aP2hBn/izn if8A8BR/8VR/a+A/5/x+8X9h5l/0Dy+4sL+zV+0FjB+Dvib/AMBh/wDFUf2vgP8An/H7x/2JmX/Q PL7iZP2bP2gR/wA0e8Tf+Ao/+Kpf2vgP+f0fvGskzL/oHl9xbX9m74/d/hB4l/8AAYf/ABVL+18B /wA/o/eUskzL/oHl9xOP2cPj7jH/AAqLxL/4DD/4qp/tbAf8/o/eV/YuY/8APiX3FlP2cvj0AM/C PxJ/4DD/AOKo/tbA/wDP6P3gslzH/nxL7iyn7Ovx4x/ySXxH/wCAw/8AiqTzbA/8/o/eV/YuY/8A PiX3E6fs7/Hfv8JvEY/7dh/8VR/auB/5/R+8f9i5j/z4l9xOn7PPx1HX4T+Iv/AYf/FVP9rYH/n9 H7x/2NmH/PiX3FpP2fPjlgf8Wp8Rf+A4/wAaP7VwP/P6P3l/2PmH/PiX3Ey/s+/HHP8AySrxD/4D D/Gj+1cD/wA/o/eH9j5h/wA+JfcWk/Z/+N46/CzxD/4Dj/Gl/auB/wCf0fvGsnzD/nxL7iYfAL42 5/5JZ4g/8Bx/jR/auB/5/R+8f9j5h/z4l9xYX4CfGsf80u8Qf+A4/wAaP7VwP/P6P3h/Y+P/AOfE vuLMfwG+NQJz8MNf/wDAcf40f2rgv+f0fvD+x8w/58S+4nX4D/GjPPwx17/wHH+NDzXA/wDP6P3i /sfMP+fEvuLCfAr4zAf8ky17/wABx/jS/tXA/wDP6P3j/sfH/wDPiX3FgfAz4yA5/wCFaa7j/rgP 8aP7VwP/AD+j94f2Pj7/AMCX3FhPgd8Yx1+Guu/9+B/jR/auB/5/R+8X9j5h/wA+JfcWU+CPxgHX 4ba5/wB+B/jS/tXBf8/o/eP+x8f/AM+JfcTj4J/F/wD6Jxrn/fgf40/7UwP/AD+j94v7Hx9/4Evu LC/BT4ujr8Otb/78D/Gl/auB/wCf0fvGsnx//PiX3Fhfgv8AFvAz8O9bH/bAf40f2rgv+f0fvH/Y +P8A+fEvuJl+DHxa7/DzWh/2wH+NH9q4L/n9H7xLJ8w/58S+4tL8G/iuCf8Ai32tf9+B/jR/auC/ 5/R+8P7Hx/8Az4l9xOPg78VuP+Lfaz/35H+NCzTA/wDP6P3h/Y+YX/gS+4tL8IPinx/xQGsf9+R/ jR/auC/5/R+8SyfMP+fEvuLKfCL4ojGfAWsf9+R/jS/tTBf8/o/eP+x8w/58S+4sr8JPieOvgTV/ +/I/xp/2rgv+f0fvJ/sfMP8AnxL7iwnwn+JoxnwLq/8A35H+NH9q4L/n9H7x/wBj5h/z4l9xY/4V R8TP+hH1b/v0P8aP7UwX/P6P3i/sfMP+fEvuLKfCv4lD/mSNW/79D/Gl/amC/wCf0fvD+x8w/wCf EvuLSfC74jjr4J1Qf9sh/jQ80wX/AD+j94f2PmH/AD4l9xYT4YfEUHnwXqn/AH6H+NH9qYL/AJ/R +8P7HzD/AJ8S+4tL8MviFxnwbqn/AH6H+NH9qYL/AJ/R+8X9jZh/z4l9xZT4a/EEdfB+p/8Afof4 0v7UwX/P6P3ieTZh/wA+JfcWU+G/j7A/4pDUv+/Q/wAaf9qYL/n9H7w/sbMP+fEvuLifDrx4OvhL Uv8Av0P8an+1MF/z+j94v7GzH/nxL7iZvh547P8AzKeo/wDfsf40f2pgv+fyD+xsw/58S+4qv8Of Hh6eEdS/79j/ABprNMF/z+j94/7GzD/nxL7io/w38fn/AJk/U/8Av0P8af8AamC/5/R+8P7GzD/n xL7iq/w0+IR6eDtT/wC/Q/xo/tTBf8/o/eCybMP+fEvuK7/DH4iEceDdU/79D/Gj+1MF/wA/o/eP +xsw/wCfEvuKzfC/4inOPBWqf9+h/jR/amC/5/R+8f8AY+Yf8+JfcVX+FnxHOf8AiidV/CIf40f2 pgv+f0fvD+x8w/58S+4qt8KviX28D6t/36H+NNZpgf8An9H7w/sfMP8AnxL7iBvhR8TMceBtW/78 j/Gj+1cF/wA/o/eCyfMP+fEvuKz/AAl+Jx6eBdX/AO/I/wAaP7VwX/P6P3h/Y+Yf8+JfcV2+EfxP OceA9X/78j/Gj+1MF/z+j941k+Yf8+JfcVX+EHxSPTwFrH/fkf40f2rgv+f0fvH/AGPmH/PiX3Fd /g/8VCDjwBrP/fkf40f2rgv+f0fvF/Y+Yf8APiX3Fdvg78Vu3w/1r/vyP8aP7VwP/P6P3jWT5h/z 4l9xWf4NfFg/8091r/vwP8aP7VwP/P6P3h/Y+P8A+fEvuKzfBf4tc4+Hetf9+B/jR/auC/5/R+8P 7HzD/nxL7iF/gt8Wz/zTrW/+/A/xo/tXA/8AP6P3j/sfH/8APiX3FZ/gn8Xj0+HOt/8Afgf40f2r gf8An9H7xf2PmH/PiX3EDfBL4v4/5Jxrn/fgf403mmB/5/R+8Fk+P/58S+4rt8D/AIwnOPhtrv8A 34H+NL+1cD/z+X3g8nzD/nxL7is3wN+Mf/RNNd/78D/Gn/auB/5/R+8Fk+Yf8+JfcQN8C/jKRx8N Ne/8Bx/jR/auB/5/R+8P7Hx//PiX3Fd/gT8ZznHwy17n/pgP8aP7VwP/AD+j94f2Pj/+fEvuK5+A /wAaecfDHX//AAHH+NP+1cD/AM/o/eH9j5h/z4l9xXb4C/Go5x8L/EH/AIDj/Gj+1cF/z+j94f2P mH/PiX3FaT4BfG09Phd4g/8AAcf40f2rgf8An9H7xf2PmH/PiX3EB+APxuIP/FrPEH/gOP8AGj+1 cD/z+j94/wCx8f8A8+JfcV3/AGfvjgcY+FfiH/wHH+NH9q4H/n9H7yf7HzD/AJ8S+4rn9nz45Hp8 KvEP/gOP8af9q4H/AJ/R+8P7HzD/AJ8S+4gf9nv46HP/ABajxF/4DD/4qj+1cD/z+j94v7GzD/nx L7is/wCzx8diePhP4i/8Bh/8VT/tbA/8/o/eS8mzH/nxL7iu37O3x3J4+EviP/wGH/xVP+1cD/z+ j94v7FzH/nxL7iB/2dPjyenwk8Sf+Aw/+Ko/tbA/8/o/eJ5LmP8Az4l9xVf9nH49knHwj8Sf+Aw/ +Kp/2tgf+f0fvJ/sXMf+fEvuK7/s3/H09PhD4l/8Bh/8VTWbYD/n9H7xPJcx/wCgeX3FeT9m34/n OPg/4lP/AG7D/wCKprN8B/z+j95LyTMv+fEvuKzfs1/tAnp8HvE3/gKP/iqf9r4D/n/H7yXkmZX/ AN3l9xC/7NX7QZ/5o54m/wDAYf8AxVP+18B/z/j94f2JmX/QPL7iBv2Z/wBoXnHwc8T/APgKP/iq P7XwH/P+P3i/sPMv+geX3EZ/Zn/aG/6I34n/APAUf/FUf2vgP+f8fvB5HmX/AEDy+4iP7M37Q/P/ ABZrxP8A+Ao/+Ko/tfAf8/4/eH9h5l/0Dy+4hP7Mn7RHb4M+KP8AwFH/AMVT/tjAf8/o/eH9hZl/ z4l9w1v2Y/2iT/zRnxR/4Cj/AOKpf2xgP+f0fvD+wsy/58S+4hP7MP7RRz/xZjxR/wCAo/8Aiqaz jAf8/o/eP+wsy/58S+4jb9mD9ovj/izPij/wFH/xVP8AtjAf8/4/eJZDmP8Az4l9xEf2X/2jDn/i y/ij/wABR/8AFUlnGA/5/R+8f9g5l/z4l9xG37Lv7Rxzj4L+KP8AwFH/AMVT/tnAf8/o/eH9g5i/ +XEvuIT+y3+0f/0RfxR/4Cj/AOKoWc4Bf8vo/eL+wMx/58S+4gP7LP7SH/RFvFP/AICD/wCKp/21 gP8An9H7xf6v5j/z5l9zD/hln9pH/oi3in/wEH/xVP8AtrAf8/o/eL/V7Mv+fMvuYf8ADLX7SP8A 0RbxT/4CD/Gj+2sB/wA/o/eH+r2Y/wDPmX3MX/hln9pD/oi3ij/wEH+NH9tYD/n9H7xf6vZl/wA+ Zfcw/wCGWv2kP+iLeKf/AAEH/wAVR/bWA/5/R+8f+r2Y/wDPmX3MP+GWv2kP+iLeKf8AwEH+NH9t YD/n9H7w/wBXsx/58y+5h/wyz+0h/wBEW8Uf+Ag/xo/trAf8/o/eL/V7Mv8AnzL7mJ/wy1+0j/0R bxR/4CD/AOKo/trAf8/o/eP/AFezH/nzL7mH/DLP7SP/AERbxT/4CD/4qj+2sB/z+j94f6vZj/z5 l9zE/wCGWf2kf+iLeKf/AAEH+NL+2sB/z+j94f6vZj/z5l9zNjRv2Pv2ltam8mL4T6tac436kUt1 7d2b3qKmfZfBX9qn6amtPhvMqjt7Fr10/M998I/8E1vjZrDo3ivXdA8PwAjegma8kI9tg25+pxXm V+LMJBfuouX4Hq4fgvGVH+9kor7/AMv8z7P+HP8AwTm+CnhKWC+8Y3eo+L76Mg+VesLe2z7xIctz 0y1eDiuKcZX92klBeWr+8+kwfCGBw75qrc356L+vmfdmg+HNA8K6ZBo3hrRrLS9KhGEtLCBYYx0G cKBzwMnqa+cqVZ1pc9STb8z6elRp0IKFKKiuy0NqoNQoAKACgD+Q+v2s/AgoAKAP6kv2ff8Akgnw Q/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj16uI9AKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ALFDRv8A0ihr8hzP/fa/+OX5s/bcp/3D D/4I/wDpKPXq4j0AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoA/qS/ Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/AII/+ko9eriPQCgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgD+pL9n3/kgnwQ/7FDRv/SKGvyHM/wDfa/8Ajl+b P23Kf9ww/wDgj/6Sj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/Ago AKAP6kv2ff8AkgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj16uI9AKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ALFDRv8A0ihr8hzP /fa/+OX5s/bcp/3DD/4I/wDpKPXq4j0AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5 D6/az8CCgAoA/qS/Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/AII/+ko9eriPQCgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgD+pL9n3/kgnwQ/7FDRv/SKG vyHM/wDfa/8Ajl+bP23Kf9ww/wDgj/6Sj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgD+Q+v2s/AgoAKAP6kv2ff8AkgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj 16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ ALFDRv8A0ihr8hzP/fa/+OX5s/bcp/3DD/4I/wDpKPXq4j0AoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKAP5D6/az8CCgAoA/qS/Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/ AII/+ko9eriPQCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgD+pL9n3 /kgnwQ/7FDRv/SKGvyHM/wDfa/8Ajl+bP23Kf9ww/wDgj/6Sj16uI9AKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff8AkgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP 23Kf9ww/+CP/AKSj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoA KAP6kv2ff+SCfBD/ALFDRv8A0ihr8hzP/fa/+OX5s/bcp/3DD/4I/wDpKPXq4j0AoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoA/qS/Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v /jl+bP23Kf8AcMP/AII/+ko9eriPQCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr 9rPwIKACgD+pL9n3/kgnwQ/7FDRv/SKGvyHM/wDfa/8Ajl+bP23Kf9ww/wDgj/6Sj16uI9AKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff8AkgnwQ/7FDRv/AEih r8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ALFDRv8A0ihr8hzP/fa/+OX5s/bcp/3DD/4I/wDpKPXq 4j0AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoA/qS/Z9/5IJ8EP+xQ 0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/AII/+ko9eriPQCgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoA/kPr9rPwIKACgD+pL9n3/kgnwQ/7FDRv/SKGvyHM/wDfa/8Ajl+bP23Kf9ww/wDg j/6Sj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff8A kgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj16uI9AKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ALFDRv8A0ihr8hzP/fa/+OX5s/bc p/3DD/4I/wDpKPXq4j0AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP5D6/az8CCgAoA /qS/Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/AII/+ko9eriPQCgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgD+pL9n3/kgnwQ/7FDRv/SKGvyHM/wDfa/8A jl+bP23Kf9ww/wDgj/6Sj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s /AgoAKAP6kv2ff8AkgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/AKSj16uI9AKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD+Q+v2s/AgoAKAP6kv2ff+SCfBD/ALFDRv8A0ihr 8hzP/fa/+OX5s/bcp/3DD/4I/wDpKPXq4j0AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KAP5D6/az8CCgAoA/qS/Z9/5IJ8EP+xQ0b/0ihr8hzP/AH2v/jl+bP23Kf8AcMP/AII/+ko9eriP QCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/kPr9rPwIKACgD+pL9n3/kgnwQ/7FDRv /SKGvyHM/wDfa/8Ajl+bP23Kf9ww/wDgj/6Sj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgD+Q+v2s/AgoAKAP6kv2ff8AkgnwQ/7FDRv/AEihr8hzP/fa/wDjl+bP23Kf9ww/+CP/ AKSj16uI9AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD//ZCmVuZHN0cmVhbQplbmRv YmoKMjggMCBvYmoKPDwvUjEzCjEzIDAgUi9SMjQKMjQgMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8 L1IyMQoyMSAwIFI+PgplbmRvYmoKMzUgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzYgMCBv YmoKPDwvUjIyCjIyIDAgUi9SMjAKMjAgMCBSPj4KZW5kb2JqCjM3IDAgb2JqCjw8L1IzMwozMyAw IFIvUjEzCjEzIDAgUi9SMjQKMjQgMCBSPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1IyMQoyMSAwIFI+ PgplbmRvYmoKNDIgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDMgMCBvYmoKPDwvUjIyCjIy IDAgUi9SMjAKMjAgMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAg Ui9SMjQKMjQgMCBSPj4KZW5kb2JqCjQ4IDAgb2JqCjw8L1IyMQoyMSAwIFI+PgplbmRvYmoKNDkg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNTAgMCBvYmoKPDwvUjIyCjIyIDAgUi9SMjAKMjAg MCBSPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUi9SMjQKMjQgMCBS Pj4KZW5kb2JqCjU3IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjU4IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjU5IDAgb2JqCjw8L1I1Ngo1NiAwIFIvUjExCjExIDAgUi9SMTMKMTMgMCBS L1IyNAoyNCAwIFI+PgplbmRvYmoKNjUgMCBvYmoKPDwvUjIxCjIxIDAgUj4+CmVuZG9iago2NiAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2NyAwIG9iago8PC9SMjIKMjIgMCBSL1I4CjggMCBS Pj4KZW5kb2JqCjY4IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUi9SMjQKMjQgMCBSL1I2 NAo2NCAwIFI+PgplbmRvYmoKNzIgMCBvYmoKPDwvUjIxCjIxIDAgUj4+CmVuZG9iago3MyAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iago3NCAwIG9iago8PC9SMjIKMjIgMCBSL1IyMAoyMCAwIFI+ PgplbmRvYmoKNzUgMCBvYmoKPDwvUjExCjExIDAgUi9SMTMKMTMgMCBSL1IyNAoyNCAwIFI+Pgpl bmRvYmoKNzkgMCBvYmoKPDwvUjIxCjIxIDAgUj4+CmVuZG9iago4MCAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iago4MSAwIG9iago8PC9SMjIKMjIgMCBSL1IyMAoyMCAwIFI+PgplbmRvYmoKODIg MCBvYmoKPDwvUjExCjExIDAgUi9SMTMKMTMgMCBSL1IyNAoyNCAwIFI+PgplbmRvYmoKODYgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKODcgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKODgg MCBvYmoKPDwvUjEzCjEzIDAgUi9SMjQKMjQgMCBSPj4KZW5kb2JqCjg5IDAgb2JqCjw8L0xlbmd0 aDEgMjAzNTYvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5MCAwIFI+PnN0cmVhbQp4nO2beXxU 1fXAz3tv9n3PMpCZ8EhYkhAgEBISyJBlSAiQhGRkJmwJSSAokBASBBSMW8G4VtC61K3uxtaXB9YA WhCx1gWt1mqroli1tdZYtNpWajK/c9+ZAKHan3/4+/z6+3XenfO+95x77n3nnnvfHUcNcABghm4Q oLqqNnsqKNfcvXg7p2ldY3tML8RbfdOmTv/+7S8+g/W3ANSuVe2r1931UfHDWD8BoHeuXrtlFfn7 5wPoRrW2NDa/f8XQbwGqUIfcVjSYH0z6HMCqQn1s67rOzeRfbgLQ+te2NTWSPr4VIOWVdY2b25Pe FS5G//Fs0PWN61pi8dyEt+T2to2dpFdlsvb2jpb2FU9Fj6N/OYCdxzFvBxjaBWde1XAubMT5dsP3 4GrYBQfhTVgJl2LtZrgT7oMHQYIn4Vl4Hb7Da2iLeh2YhMdAA06A6MnowNB9KP1qyxmWXag5Vf7T lqgt+slZtk+GdkVtQ/0aBxiUvmb+FbT+hRuMnuSLmB7NZTq/A+tWpcen2tuHHhm6f0Q482A+1EEI zoHFEIEqWIhSDTWwAJbBCmiEJmiGFlgFq6EV1mC+zoO1sA7Wo6yCNmiHDdCBOeyELtiE9c6YhfTN sAW2wrYYL4ALsb4F71uV2na4CDN/8SlecoqnLZfC5SiX4f17sAN2whVIdh9pG6n1wJVwFa7nNXDt qfq1X2tl9evgBpTvw/W46ruxfhOu/S1wK/xQse6CG+EHinYH/Ajbbxzhy9pO+98Gt6PXnXAXet6N u+f+s3yZ5x3wODyBe+rn8DPcbQexdhj2Yf0wvAPH4X34A3wIf+QyuFxuLnwGn8NLmP1VmHWW83bl vgbvq09l/HzM7XBmt2PGRuZhU6yN8nmJkqfhtvPRcweuxiVn9OlR1ml4LOY9PNaZ+WJzYjM6baMZ 7jplOT3vkb3I78ycjczgLYplZOvZmT2zftc3ttwN96Lcg3e2Dmdrw7UH8A1n8hD0wsNYo/tpfbj2 Y/gJPIJnQR/sgUfhp/AY9J/S96J2ul1WLMM+X2/fDweUXXAQDinr/xQcUWwHsbYv1now1rJfqR+G Z/AUeh5egKPwNO6dZxR5Hl7E/fEyvIKn1lvwdmwHvabsIJHLgF/Cy6p0+I3awqmFQ3CYXwibUX+d vxlXAtTvgyUQXLF82dIl9ZFwqK52UU111cIF8yvnVZTPDZaVlhTPCRTNnlVYMDM/b0bu9OxJWZnj 09PGimN8iS67zWo2GvQ6rUatEngOMsvEYINfSm+QVOlieXkW08VGNDSeYWiQ/GgKjvSR/A2Km3+k ZwA9V53lGSDPwClPzuYvhMKsTH+Z6JeOlor+fq6+Joz1q0vFiF8aUOoLlLoqXVHMqKSmYg9/WWJr qV/iGvxlUnBTa09ZQymO12c0lIglLYasTOgzGLFqxJo0Xmzv48bP5pQKP75sZh8POjN7rCSklTU2 S9U14bJSb2pqRLFBiTKWpCmRtMpY/jUsZrjS35d5qOeqfhusbMgwNYvNjUvDktCInXqEsp6eHZI9 Q5oglkoTtr6fiFNukTLF0jIpQ8TBKhedegAnqdNsor/nC8DgxYGPR1oaYxZNmu0LYFU2xVNpwvbh OmBsGCHOLzWVxXJlfwBWoiJ114RJ98NKrwyB7IyIxDewlkPDLe4Qa+kebjnVvUFMZUtV1hD7bGpN lLpX+rMyMfvKJw0/2O6XhPSGlU2tjI0tPWJpKeWtLiwFSrESaIzNtaxvcjb6NzbgJNawNNSEpWyx XXKJxeSABj9bgzW1YaVLrJvkKpGgoSnWS8ouK2Vx+ct6GkopQDaWWBPeBznR433T/N49OTANIiwO yVOCi5Je1hNuXiX5GrzNuD9X+cPeVCkQwfRFxHBLhK2SaJMmHMfHpSpPVHrh3M7yHnZmM9em6fxh 3itE2GqhwR/Em1hciA02XC5FZStaXOgPc14YdsOnxDxYbcQ4qAhpJeWsSWBdS8q9qZFUuv5FSN5Y TOo0SXfGWDY0nIqJnvONoZE3C2iCv6yl9IwARwyqjgUYG+3r4+RZLmIPxh46tpzlw01CGr65aONx GMXEVjHRL0G1Pyy2iBER91CgOszmxnKtrG9lrVhZUx9WVju2S+pGaNSeR5oEqdg8rPAluAeDGd7h ZVX0uYp+Si0/q7liuNnfoxMra3vY4GJsQPDjG4ST1qRXNF6Z55iGr2YQTzcx2Cj6bf5gT2N/tHtl T18g0NNe1tA6k40hVjT3iLXhQq8S66LwNu9W9igHVHKVdcVZmXj2FPeJ3M6avgC3s7Y+vM+G/6i7 sy4s8xxf0lAc6RuLbeF9foCAYuWZlRmZ4mcKG2kRKjrF37svANCttKoUg6I39XOg2HTDNg6a+nmy 2YZtPNpUZAsoNnbhIiW2YorxuC3zN7PluTDS2tMQYS8XeHAp8cNJnDgbJF6c3cfxGpNkEFuKJaNY zOxFzF5Edg2za3FjcB4Ok8POpJ4GEc8p3FBh8HK0FQU2pL8/Gq0Lpx71DkRScastRakPS/oMPPvV afPQby6TBjTPlbqbGlkcEAqzvtq0iqYIbtvhAdGlQtLjCPrYCOgRVPqw7YidmnBtcAGV/t2oSN0R KZLBHhpeE1G2s02CcnEmLjuNqU5nD8qO9DjEqcq7ia+CIW0Hgx5jg9owWbyo4sMilCStCSNvErGp qcGP2VZBUy1udTpLDV6ytOCRqEpvUcTgjTUCm5aQZjQbJP0kHBA/rG6cxF5JdZo2EqHgFW1HzAGf bZOMGFH6GamMdcDsYFMFiwU/OzBU5vokG6amHxaJm/FkYUErI2mxWTKnVTTi4U/9jWgR84Y769gZ YYyNcYSsWjZzE+ZdSKvrj94vbkk948rKFNmXA9uY4N2HGxsiPWcbpCUZWZm6s61mxdzTozN/fQfK l858imgE3Or4c2kIuCOGO09OO2k0uHTA3XLmDybuF8zH2sr5wQbvghZfBBtkQwP+6h2IRnFZuD69 0M9vlVNm+/r5LYTNcooRcT5hk5wyE9FF6CSXjXJKAaJDTilEbCC0E9rklFmI9YR11GEt4Tx59BzE uYQ18uhiRKs8ugSxmrCK0EJoJjRRh5XUoZHQQG0rCMvlUWWIZYSlhCWEekKEECYsJpxDCBHqCIsI NYRqQhVhoTyqFLGAtPmESsI8QgWhnDCXECSUEUplbwWiRPbOQxQT5hACsrcSUUSYLXvnI2YRCgkF hJmEWkI+jZlHmEGD5RKmE6bRmDmEqdRvCmEyIZswiZBFg2VS9wzqN5HaJhDGE8aRZzohjTqMJYjU bwx5phL8BB8hhTBaTl6IGEXwyslViGRCEiGR2hIIHjK6CS6Ck9ocBDsZbaRZCRYymgkmgpFgIOjl pGqETk6qQWgJGoKaoCIXgTSewBFAARclDBEGlQ7cV6T9g3CS8CXh74S/Ef4qJ9YiviB8LifWIf5C +IzwKeEEufyZ8AkZBwgfE/5E+Ihc/kj4kPAHavs94QPC+4T3yOV3hHfJeJzwDuFtwjE54RzEW4Q3 5YTFiDcIvyXjbwivk/E1wq8JrxJ+RS6vkPYyab8kvETGFwlHCS8Qnic8R57PEn5BxmcIPyc8TTgi e/Bc4p6SPUWIw4QnZc8SxCHCQcLPCE8QHiccIOynfvsI/WR8jPBTwqOEvYQ9BJnQR/0kiuUR0n5C +DG5PEzoJTxEeJDwAPW7nzrcR8Z7CfcQ7ib8iHAX4U7CHYTbZfdKxG2EH8ruJsStsrsZcYvsbkHc LLtXIW4i/IBwI+EGwm7CLsL1srsR8X0a8zoa81oa8xrC1TT0VdThSkIPeV5BLjtldwixgwb7Hg12 OeEy8ryURrmEul9M6CZcRNhO2Ea4kHABYavsxjOZ20JP2ExDn0/YRE/oolg6CRvpeR3UfQOhndBG WE9YR1hLOI+mci49bw2hVXbnIlYTVsmuSxAtsovt3WbZdRGiSXaxfivJ2Ci7AogGMq4g43LZtR2x THZdilgquy5HLJGd+CXM1cvOFESEEJadBsRiwjmyE7/muZDsxO93ro5QS1gkO/FrnquRnfjFzlUT qmQHi3qh7AgiFhDmk7GSMI+MFYRywlzZgd+bXJBcyshYSiiR7XMRxbKdvZRzZHsYEZDtEUSRbK9H zCbMku1stxYSCggzCfmyPQORJ9szETNkez4ilzBdtrMHTaMH5RCmynaWwSmEybKdJTKbMIliySJk UkgZFNJEwgQKaTxhHAWRTkgjjCWI1GEMeaZSSH4KwkfPSyGMJs9RBC91TyYkERLJM4HgoQDdBBfF 6aQHOQh26mcjWAkWgplcTKQZZdsyhEG2LUfoZdsKhI6gJWgIavJUkadARp7AESAQRUbRbwg5iPIV yj9QTqLtS+z4d6z/DeWvKF+gfG5d6fsLymfWJt+n1mbfCZQ/o3yCMoD2j1H+hG0fof5HlA9R/oDy e7R/gPI+1t9D/g7lXfQ7jvo7KG+jHEN5C+VNlDcsq32/tbT6foPyOsprKL9G26vIX6G8gvIy6r9E voTyIspRlBdQnkd5DuVZlF+Yz/M9Y17r+7l5ou9p5BFzpu8ptB3G+pPmdb5A9JD5XN9B8xrfz8yt view5XHzFN8BlP0o+0wbfP2mDt9jpo2+n5o6fY+i7EXZg7qM7EMfCeURlJ+g/BjlYZRelIdQHjRu 9z1g3Oq737jFdx/yXuOFvnuM23x3o/1HKHeh3IlyB8rtKLeh/BDlVpRbjFm+m1FuMtzv+4HhXt+N yBtQdqPsQrne0Or7vuES33WGW33XGm7zXWO4w3c12q9CuVxI810m5Pku5fJ8l4S6Qxf3docuCm0L be/dFjJu44zbvNsqt12wrXfbm9sCDo3hwtDW0AW9W0NbQueHNveeH9rPXwGr+J2BwtCm3q6QqsvV 1dklfN7F9XZxpV3c5C6Ohy5bl79LMHWGOkIbeztC0FHd0d0hdagKpI7jHTx0cIb+6KE9Hd6UIDJw YYfZFtwQagu197aF1q9aFzoXA1yTtzrU2rs6tCqvOdTS2xxqylsZasxrCK3IWxZa3rsstDSvPrSk tz4UyQuHFqP/OXl1oVBvXag2rya0qLcmVJW3MLQQ7QvyKkPzeytD8/LKQxW95aG5ecFQGU4eRtlG +UcJNhbAwlEYCf5+Lp7sDXiPe094VeCVvIe8gsOa7EvmJ1iTuJKqJK4t6aKka5MEa+JLiXwgcUJm 0JrwUsI7CX9OUDkDCRMmBcFj8/g9gpvNzbOgLqiwqJQ4Zboy1wUeMT1odXNWt8/Nl/ncHNiP20/Y BfdB20s23mrlrNaolQ9Y0d1q8Vl4dotahIBlyoyg1ewz8+wWNQuegBktbMRxpuq6oNXoM/KhImOV kQ8Yi0qCAWPW5CAInJ/jgLMhBB2LgnP7gvhe7/Fwag6/z/vqajMyKvu10UWVkq56icTtlNJq2T1Q Uy9pduIv9/ol4T6OuybSx/EldZKL/RsnRb/86quheHSlNLo2LN05OlIpdWMlwCpRrMDoPg8URzKW b+zamJHRuRxvyzd2Zigf1LgupmUwI/ts7ESdlS5Fh4x/eZEbYsVGvDqHjZ3/utf/2Yv73w7g3/xK XLEcANQAQxuFN9QWEEALBcp/Ya56NMuT5dEVzjFwA1ABWq4ZePBzV4EOOK454FDxaTM0Qo3XbG+v 4WpKtXwdFB17+9iyt48dRR7lso8NvDZgG3xtwJGfn509ZTJnT7Ur4rLwWq1GI46ZxM+YkZubkzN1 Nj992iReHGNBSZ8+bTY/Y7aQMzWFV1zJU7GiM7MKb3y1RKga1PAX+MrWLxzL+7wWl0nN+dW+BN2s qklOa+r08eMD2T6tQcOrdRrdhJmlY0qXz0weelTQGrUGv8eTbFGrtCad3p/kTLKohoJqy8nP1JZ/ lKjW/mO3MGXa6kW56psMOl6l0TzuTUgrCKYmZfidVqfNZFE7PQ6N1ukwps+aN3ilLiE5QWswaE02 gz4x0aPTGzQm22AeJqomOiC8KzwH6ZjNq/fzF/HdEM5gp0AovEc/WpeCP3P2po9LL9DhD53HwJrO OYX0Kf18SiDBCfqCcaPTNUJqxcQvk+fl/j1gWSDMH5+RWFSUvGCgaKDIkZDPZQ+8umL5smMDOfYc 24A9P38Knryeb9FxyuRI2nDqLUIssaqcqZ6EWHK12vR0XAiV25XCs4WZIWSqxk50JdtwWHPpso6C 6jWzE9zZledeFYlcNNWpSh/v8tpU3K+y15XmLi6Z4sODNDdjRlvDPEeS3aLSGvUP+ecHJuYt7ZyV d83uq9pKyouW2CyCzqT9uKwsp+68jvWZYlm+OGvt9WEALjpraJcwRb0Z9981Z+XMkWL3HeA+wGza uQ8CYkVheaCiIFDh8VQEClQw0fTewrkphe8V+MY6ystz3wuMrWLzZtM+gttv8EjRAJd9JAH3YXa2 HQ22gVNZc/73XTFpuBNVLFtsj2q1mC83M4gCyyEuYzplMZYyJ+1iVU5ObB8neDzCFF7Q6AwarXtU ekLGrMwUo/1Zo1ml0Rst2ud67TPr1pdl5WtVKkGFXlqt2eq2TZyVMdp0T7fBiJvYZDZsT7IVhtpK PJMn+DQajXqGyu5OcOEe1iXPqMuvt9qNiQlum+Grh+suqBln0ahNBpWTOQiCgA4FwlSzQ5eQ6HEY ty26oHqcWm/SqB3AQVH0pCCpN8Ac2DYy4wFxUtLYOUYwiMZE45xpKrXzy0D+PDHJAGMnaVImBFPm q2lvsW3F0qVsy+wjU+05R3Omsswmf+t+bFfSbpzhzM0dPgu0QszGURaZrqWq26XRYkYNbn9Sos+u 5trUWpM3wze9bUWlvZo3uFITk9DMcwZe705lLiquWm2xWjW20qVtBYH6/GSdNkln1KlUeOMzk+ck jp4sumav2x0a2jBsVufpTKxm0g2tSc6dPtkhVhZNTJtTP21sqQiUOe5TzJwb5p6VOZsbjAEDGNxG ldoWjE1XSU9yLDXGf27EHMw4a76///qZJP1zhCyea6Mn1YeFx6ESLhsZzz7I4h7amzLG6Zh8gPsK ZkIBd/lex0zHmOIDvBUP/0xuMOAIjJlbMb1iUqFTSBpXkTTffMYaFWHcCwZeHTj13tiODbBJ2L65 h/LGaLS4XrFDRuCGK8q7witvhdM9PFVWnS3E3hb1YbWQvmTd9nKt2zvGnSy69SVDL6ttyeNGjRqf ZFrBcTpnanKyz67hgioupDI4UhISfA4dN089aek5C/y8yT0mOdFnUwv3GhN069459usmo0nLq3QW A797sM1o1atYXVist2tMVr0gaM36wUS9nv9QZ9ahZtINenW68keefK5Rb9YKglrPsuse2i3cjdmd DK1nnUyiyznhAG/DRI7hBvckJoK+nxcDloBzUoWoc42ucFVaqmKpyc+nXB7Jzz59AJm+1u90BpXM pafnznCOyF1OLF8e4W6VOnVh65UNQ4MaR3Jakld08MbPb+B5LW4er8+u5br42c11c3280T3Wm5Ui 3GNMMCx5+vWPLh66Q2fSq9Qml4XLF9pMLq1RSYfFMDhm8d59TzTiFhNMOK8H4uU/vXAl32H56n++ 8Dd/6/Luv38RrjtdVJZ4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4iZd4OV2U Pwzk2d8F4uUCQWEmaCCR/cEgaLl6jufauPEgcE9yz4AKJqFdxf5WEOCENhrFO8fuqKvwNtJb+aND cOD4PLA/TtQB1NVNmV7aOXmy0gLcdez/tvuWl26kegJOREcYaA7A5jQs3EtxiUtc/hNFNRpq/h2F 3xCd/f9BcC5F37Vwr8XluxB1P1z7dSLsBnfsO/6bL/Y9qr69v096ZP8Ka+EXkERfvAf+dOELjE+P uan95LTB5w0u3Sj8Xtcr3+14/RfNtv4ICmVuZHN0cmVhbQplbmRvYmoKOTAgMCBvYmoKNTkwMgpl bmRvYmoKOTEgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA5MiAwIFI+PnN0cmVhbQp4nGVWeVRTVx5+MSQ8FbGVpiZjm5d2atGqp2rbcWktY1VQCoogYMGF JQEiWR7ZIDskZOPKloRdJEASSNhFKKBSwX3ttKd0te3RbtNlZtpOT2841z/mRaftOTP/vPPOfffe 9/2+77v3+9GwiAUYjUZ79IBQLJCve00q4u9R5IqE+eHBdaEVtNATC0JP0lEUyp0vmN/HeBJLal+8 BETRQVRE+xNR3mXw7qOwfymsewSj02hlzcEdUlItExYWKXir0lMzV69Zs/aPkQ1btmzh5al/+8Lb KZALCyW8Z6kXlUAkJcUCieJl3g5qtohCwCsUqckiOS+Xzxfww8syckWCYl68UCQkSamKt2rHat7G 9es3rKMeG/cKxXlKOS9VKs6V8PZKt/CSeMkCvlAp5j0s5/+/Yxj2J7UkX8onBTt3yeLlqQphmlJV LMoVr1rNW4dhWdg+bCeWgu3C9mPx2ErsWSwNi8UOYC9g6Vgi9iKWgWViSVgy9hq2F1uILcJoWDS2 guISi8CqaCyamvb2gpwFP9MP0j+IkEZcZSQx5ph85nDkssgRfBPevPDRhYcWzi1yLrq+mL6YufhJ WBMdSkG5MDLk8NOgDy6mt4SeZ7WDuiqn7URFW17rzn704onngAgoTHK1TCUlVRpQCcqcZqemSeZW A7xEXiI55icHZ2+O3pol4OPwBbgYVoAf8QFJ4JiYJEVyp7FbzW3X15uBAYjVufGIY3yfrYSLSmCE eirbWGhJtODRofPAQ4O/wih6qBiuYOUnG/QagJstzoYGZ1f7DDEEaW2TDROgm3OmxH+ooFBXIuUW FpXJd6+6AbPYr+tfLk9z4GTkWFWTFZSBcuMhIYoi17AlCGPAJcwpuH3o3rU7Hf5gZzvAm5rLK+wO s72COIC2arONqaCEU+BTjF0eG/jhEpcixHAjFN1Ps8LH4GoKEHwXPsXK3i1S5AA8Rzw0c8331dBN wjcV6A5QezVUVtgcFouJMGlt5cCIi73K/iFf7+nzh4f3oKfQM2gzenHj9eSv3hxv6x3g+jrbTg6e o8q1G3pDL/XS7BRZeRTrcDiUx0KxiIdeQK/85XbSN9Sfn4DPw21f7Lm+njBJWL3tysIEEXq8eBch SRZLigAuLuse+WgYPjt4jfBN9nb1gfCu88v9NBV8hB6Kg8tZ5BEZqQO41VJf7+68NwhjCEgPrd6n z6qMNXNIT6SvtUJtssgUmwh1gry7zC0BHBSNnkPpaMOOiYyr1yeHvrtImAvsOqDD+Z2KkbMTI1/M clE8vMTqrGpVASnIPYrYwiRplkQmATKg7qkerJkJfjN0s+/iUF/AEQaEcv1wyyANzsFH6V2hNawJ h9tGCWQy5RuyYu+z2dq9RkMewC0krPYzs45rXaAbNLn629929bBrmgfVTTYP4MAV8Gm4B26fy53a k3q0eHMKMQIjV2r5lkwLBzblsHyOVoWj2JZYHFuYKEo/Jj0GcKWmraPNFfB/TXR/2tDT1u091e/1 hRE9ELePVkc5Ne4bOnwHPs06FC9V5lLaKntm2qqbazuIf3ec7Tw3Odh3cgQM4tNHh/ZSMj6DNqEt m24k3ftg5tQ/r3BR1pesIcid/PAMwE+6jcq47MRXJUSlQ2ctt+HR8wXAKxsI/RhcFhqEsctjyG/n 2awWR7OjtqrP2mAGclBh05iL0ZL7qeyYYd1BrS7LgssiY0h4igldMBVug6UwDkX8hPYTaJwJFfEs p7+tkdIY0mdSKJGYQrQ4/VUiI25nwVqAF2gau5pq2tw+ovp4NeBGzz8P+uDlPtjRRwt9BjNYsrqi VJWMT3LS+AllL1GVqhu6nTWNdR1EdV11/XFXdT37AhRApiNQBuI5QF9Vbi/rsbLnoE9ae2hdiQGx j3OuQnnDYJP7NOC8B2Z0frJL7pSBZL+VPQ5TGfeHZcwWR5OjripoazQDFdDZFBYlWno/na3NMJZn mnFZaDoyOsQBHjgLCZr/DyfIhOixBKTGqVPaOtkyXtva92PrSO8Z30SntxnUgjqb09SqaTa3AXzA GxwbVfiEB/MOoo2vELegYJ+uzI6WVHDCBXvhrYcFN4VErDDs0nK0vOoh7Gb3aBj2tNYv6lDUkyDt N9iB32HbG00UbL1N/j+w4RlvZFqtzg2CgGLY5a12Hq8/Xj0DD7N/dQRKQcLvZFHFGQKh9f2qjmVT 353+fnnMBLwbymVJmOVldocOmICpWu3EYz5skBlqSldszXgjLr1FcmsbMXKkXQhkuFgmL1aoGju0 3FKvucs8Q9awlWgrw8+sbWpyNQMnaLQ3W7vNJ20dAP/8xsX3J2Rn024Sggl1EHTifR5P36SvcHMb 1+9gPCSDUt9PkSGCa+iQ/l/zhdWhzFcKjNZiq+ZhmZk6fdh68Kw3cn+t3gUCoKXO5w7OwnR2L/NX 9DkDHvEy0+oqXMrLm2EVe7bR29DnmR7onQYX8O+3TaGNXNTLhLI4lnvI7QoC/GJ/0b49kr05JFGi 4VcmV+HRMBhaM0aDA6F01g7mKbiSUcRM3/pG3itivGg6MgGZ9AcrjgANh99TMnZltP/nW1xlizCj hNQCjtnscra3vzcEo4l+uIjxGfPBXn6IwxU0KKIuZX1pCV+h0lEzK52u+vqBmibia3gv3birYpuF Q0aOt5lVZrvOpiH2o2Kz1CoFBk5BT8npK8PBX97hHg3NsopEoiJ+r3h4JBgYHi4OFhBUDqkH5qMH 5R3LfoJL4CNwyfKYD6vVrACzqddZfxI0gGZ7l/msZqBylDqLvC8/ho/cPXwbRf+dSJ7SdYIJ/Mbo 6RufnMpCC5u5fhsjZmIUHmaImSa13qyiPKCplYU90JJD1klXIOaLm9ACsk7p0hCduaePXjj60b7B Q+AwUFbKjUoFv6gsC2SCw17ZWFnQHLBdkVRTJjsf2t5Ba6USg4pJDqsoo1T1ICZd7gYAvN8RH0EP Ay1ipqF0yZ7UHSKBUlMKcH2l60Rrtat5nPgWXrVUWaq0ds52Q4o5O5yYk/YGK2UJrVVqkuQjDluf XVkI5HiWT3b2dsAHn/mZqz5gIYEUz/eUvnnl7OiXbz1ISA/tKxjxKVxIb6OOchC47fWGE8WNLwAe sAFtlcqGnmD7mDAGLpk6P/vJ6CXPDBjDB8V9IgkpFWuc+hOl3FZNXQWoAEVk3ioUYYMHLZdUn2QZ FbbNxnBumN9N8oRivcticqgkTGGd8jNiPOjVYCDj2opzYKj/3NfKRjZ5SKspo1LIOCiAmddn2W9f 8jRN1uNelC+LPOWgGgEtKBEUoGWr4NJQDvtVfab5FTNVseu4m7pY8J6WcoXJrreWETE5aP39GwwY HTbYA2Plp6ge8ErZqsU10PIWAVeGOl7SZFv+Wkn5qvF4fXgDPxWfBn1y6W5iOzqhjDPuB3JOoV8+ em0k+MvfKJLsKriUHoqHMay8AzqdFuCV1nq3t2Gs+w7xLixH9Ep1imla6cmhUncplboH0Pq48YM3 r04OU6lbzrfrgR4vCEiGp6ZO3bvIRfvhVVano1UNSJAiRAxBAplNdVdU/1XWFXyr/1+n54jA+f6g n4q4+ZPAE3rcTxuglHEx+1rMlPmE5FpiNzKFe6HzMHXk7oXbnd5eTzPAG9wVBp0x99hKIhHlM2AU 8zI8UN8+dH1sbnQs3N40VpRb7OU2A3EELVcm6ZOBlJPXrRy/Ntr/j0tcZbPVbK102DmKQpXSAHBT pdPZCIDnNjEBOa3jrhHg44weCx5NOJyP2Ju4J885faAHH5P5cqXicoWUWyAVCxJjb8Bs9us6lR1F mqjb4i78eH47C61FEfsSD/+Z3GdIBDsAevI0ov+IuF2t7APfa68BiAMY44Ws8e+H7gyfuTMXXkei BBZc+Pn0melPzt/xfQF+AO9pPxLNKS6oBjLfVejYMxvadwPEBIhTjNa+EVucKBLE7aIW1oT/uRXi NNgNB1nIwZQjnAGrmNGlHaH0Dniog+lfBKMW++ujojDsP4lYE8gKZW5kc3RyZWFtCmVuZG9iago5 MiAwIG9iagoyOTg1CmVuZG9iago5MyAwIG9iago8PC9MZW5ndGgxIDM0Mjc2L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggOTQgMCBSPj5zdHJlYW0KeJztnQlgVNX18O99b/Z9MvuWmclkZpJMMpM9 BELyyEYWAoEkkACBhB3FgkBEUJRacUFR675UsWprLS7DgBjFXdRaxbZK1WptbWtbtUZxayuayXfu OzNJQKzWLv//932ZmzO/d5d3373nnru+UQglhGjJNsKT9lkdsWIifgY2wtfcpaf0r0P/Rub//dLT NvpizWXNcP1rQmSKFetWnvL9d2rvhOs3CVGaVq7ZvALTB18hpHDOquX9y/4kSzYSsh3SkPJVEKDd mZFHiP7v4M9edcrG01PPew7CHl6zdmk/+ufmE5LZeEr/6evcRr6dEIMbAn3f6j9leSp9N3w5163d sBH92y9m8evWL1/39JGNUUhfRYjle4TIbyIkeQUZ+3wb3PfIbnIveYA8Rn5KXiQfURXpI9vJI+QP 5B3yIfmMEiqnFuqmueTf9kl+R3oK0fKPEhmxETJydOTt5B0jbxMi1Y0LuQJ8NkloLGQkY2To+LDk FcnB5PMyNTGI9xq4ZyH0CB0aOcrVMP9IOfNz57Nr8Y4j8puS9yR3HVOcdWQ9GSCnk81kCzmDbCVn kbPJd8h55HxyAbkQdHE2XF9ELiY7ySXkUnIZ+S65nFxBriRXkavJNeRach25ntwAeryR3ER2peKY /yZwV4uxLOYW8kNyB7kTeCu5jfyA3E5+BP4fg/bvJHdDGIag/y4IuZl8H0J/CKEsFQu7B1yc7CEJ spfsgzZDf9o3SB4l+8l9wPuhNQ+QB8lD5GFox0ehZR8Xw1hI2v/lKfH7CXKQPEmeIk+Tn5BnwDKe Jc+RQ+R58rNvFPPkaAjz/Zz8grwAtnaY/JK8RF4mvyKvkd+Q35I3yO/B6t79QvwrkOJVSPN6KtXv INUfyduQcghSYjpM82sx9i0xh8Nw7xvkTaogn1COfEZG4Iq13tViC10ntiNrPdY6t4l6Zu1xD/hZ C90+2jZ3gY7vgvZkPnZ9fao17oa0e0CDaf2dWGvPp1oH9f0gpGG6YDGHUrp4OtUSLJ+HR+99VoxL iPc9PprrmEaxhr8cp51fj9PhH8mfRM2g9jB2THssxZuQhmmZ5XGsbn8P96L22b0sfPw9LO5V8L8N o8O7oGnGv4gt8Rfy59HrP6fih8h75H3yifh9hHwA48lH5GPw/xVCjoDvi6HHh/wN3N/Jp+QotODn ZHicb/i4mGGShDYmlFKO8iQ5djUWKoqESqkMxjQFVVIV1VAt1VE9NUDIsTHq0RjjF2I0J4hTiiEZ 1ETNMF7aqJ06qQvGTQ/NpF7qp1nj4hyjMT6ICdBsGkzFWcU7HaP3eiGFbVzaXFpIN8F3hEZpDK6L aCktoxW0EkIKwF8M/skQVyiylrSTJWQNOSp9i3sO8jfDqLJHaFy8qHfhgvk93V2dHXNmt8+a2Taj taW5aXpjQ31d7TShpnpq1ZTJlZMqysti0YL8nFAwO5DltZuNBr1WrVIq5DKphOcoyW8INPb54qG+ uCQUaGoqYP5APwT0jwvoi/sgqPHYNHFfn5jMd2xKAVKuOC6lgCmF0ZTU4KsiVQX5voaAL36oPuAb pPNnd8P1zvpAjy8+JF63ideSkOjRgsfvhzt8DfZV9b447fM1xBtPW7Wjoa8e8tujVtUF6parCvLJ HpUaLtVwFc8JrNtDc6qpeMHlNEzewxGFlj02zgcb+pfF22d3N9S7/P4eMYzUiXnFZXVxuZiXbzUr M7nItyf/0R0XDxrIkr6IZllgWf/C7jjfDzft4Bt27Dg/bozEcwP18dwtb9qhysvj+YH6hngkAJm1 zhl9AI1Lg4aAb8cnBAofGHr32JD+VIgsaPiEsEtWxVE1QXz6mkDZoIRQP7+fleWiQYEsAU982+xu 9PvIEleCCLFIT5zrYzGPpmMsXSxmWzpm9Pa+gJ81VUNf6u+0Vfb4tiW+gnzQvvgXhD+I98X5UN+S pasY+5fvCNTXo946u+NCPVwI/am6NuwpjEH6/j6oxGqmhtnd8VhgXdwcqMUEEOBjbbC6o1u8JXVb 3FwXJ31LU3fFYw31rFy+hh199VhAlldgdvf9pGTkjT2lPtfeElJKelg54tY6aJRQw47uZSvi3j7X MrDPFb5ulz8u9ID6egLdy3tYKwUM8dw34HF+8YniXVC341KnE7Oay4MKXzfn4ntYa0GArxG+ArVV EGGA5hK9rEVrq3zd1EXSyeApqRTs6ph8wMMH65pYFM9urWty+Xv8+PkHRXKlyiQNxhXj8jJAwGiZ 8DlfWjRMzQqU62tYXj+ugMdkKk0VMJXbicvJMV2kHgx3KFhzNqWj+CD0XAjjIBsxiLWi3Rcn7b7u wPJATwBsSGjvZnVjuhbbt7Uj0Dp7frfY2ikr6TzGh/GT0BcnfohOe7g6sMHGiCvdrKJ/uugf9TYd F92cjvbtUARaO3awzAOpDIkPehBUWhZq7r9oUkYpdM1GGN0Cjf0Bn8HXuKN/cGTbkh17BGHHuoa+ VZNZHoHmZTsCHd1VLrGsc7q3urawR2WQVtraWVuQD2NP7Z4AvWD2HoFe0DG/+35Yy/ou6OxOcJSr 66vt2ZMNcd33+wgRxFCOhbJA5vExD8tpDngUYnrX/QIh28RYiRgg+pcOUiKGKdJhlCwd5DDMkA7j IEyCYYIYxj7QSPZVoGIYbht8y1jznNmzakdfD+tcxApNCX80TgPVJM4FqvdQTqaJqwLLa+PqQC0L r2HhNRguY+FyMAyYC0E5bEza0ReAcQoMqpu4KJoiz7L0DY6MdHb7D7mGevxgagtB5nfHlREY+6XB Fkg3nUkfBE+Pb1vaz8pBurrZvfJg89IeMNt0hpCkOa6EHJSpHCBFo3gPM0e4aSm0DTSgeP828MS3 9cR7Iuyh3at7RHM2xElTYDI0O+YpDbEHxXp2ZASKxb4JXUEVPJ9BCWUjHd0Y4gIvPKwHlSTXQMmX BiBqaZ8PtC0hSzvA1HEsVbkwZDkMiZLQclFUrlQkYdXig2qtKq6MQobwx67VUdYlpUF5Tw8WXvSd n0oAzzbE1VCi0DhVpm4A7UBUMysL/J0PRWVJH2PZzB4kcwKnw8jCCi3mJIfouDbY3A+DP96vhpDA pPTNCjZGqFN5HMRQOau5BvTOBzsHR24PbPaP+xTkB9jkwAyTuO4HwyY9O44PiC+IFOQrjg/VisE7 dii0J74B9aXQjhICCZg6bBGThB5U3fzZq0fPU77LQsZ/+PdYiD6L+mAn+RCRQ0cwkBjslYlm6cgI NAvdo+QHuU8TmR7vIPf3RGYE8LdEZj7gr4hPEB9j3Efo+xDxAeII4n3Ee5hyCPEuBv4F8Q7ibcRb iD8j/oT4I+LNRKYS8Af0/R7xu4QnA/BGwuMA/DbhiQF+g3gd8WvEa5jkVfT9CvEK4mXES4hfIg4j XkS8gPgF4ueInyGex0IcQjyHeBbxU3zsM5jyJ4inEU8hnkQcRDyBeBzxGOJRxCOY58OIhzDwQcQB xAOI+xGDiPsQ+xH3IvYh9iISiD0JdzEgjrgn4S4B3I24C3EnYjfixwl3EeAOxI/wvtsRP0T8AHEb 4lbELXj79xE3I3YhbkLciPgeZn0D4nq8/TrEtYhrEFcjrsL7rkRcgbgc8V3EZYhLEZdg1jvx9osR FyF2IC5EXIA3nI84D7EdcS7iO4hzEq5SwLcR2xBnI85CbEWciTgDsQWxGXE6YhPiNMQAYiNiA2I9 4lTEOsTahLMM8C3EKYg1iJMRJyFWI1YhViJWIJYjliGWIpYg+hF9iMWIRYhexELEAsR8RE/CUQHo RsxDzEV0IToRHYg5iNmIdsQsxExEG2IGohXRgmhGNCGmIxoRDYh6RB2iFjENISBqENWIqYgqxBTE ZERlwl4JmISoQJQjyhCliBJEMaIIUSiCpwl7FHwxDIwiChD5iAgiD5GLyEGEESFEMGGbAshGBBI2 ZtBZCdtkgB8DfQgvIhPhQbgRLoQT4UDYETaEFWHBJ5jxCSYMzEAYEQaEHqFDaBEahBqhQigxTwVC joEyhBQhQfAIDkERRAQdQSQRw4jPEZ8hjiI+Rfwd8TfxsfSvYo3oJxj4MeIjxIeIDxBHEO8j3kMM Id5F/AXxDuJtxFuIP+Pz/pSwBgB/RLyZsIKB0T8gfp+wTgL8DvFGwloH+G3CWg/4DeJ1xK8T1gbA awlrI+BVxK8Qr2DWLyNewsx+iZkdRryIeAEz+wXe93PEzxDPIw4hnkM8i/f9FLN+BvETLPzTiKfw eU8mrLWAg3jDE/igx7HUj2FmjyIeQTyMeAjxIOIA4gHM+n7MehCzvg+z3o+4F7EPH7QXkUDswcfG Efcg7sas70LcidiN+DHijoQFxl36o4RlGuB2xA8TljbADxKWmYDbEpZZgFsTljmAWxIWAfB9THIz JtmFSW7CJDdi3Pcw5Q3oux5TXoe4Fm+4BnF1wtIOuApvvxJxBeJyLNJ3MeVlmPJSxCUJy2zATkx5 MeIixI6EuRtwYcLcA7ggYV4IOD9h7gWclzC3ALYnzAsA52LcdzDlOZjk28I9wCP6Bu/7uibvG5qZ 3sdBHgN5FOQR9VxvAmQPSBzkHpC7Qe4CuRNkN8iPQe4A+RHI7SA/BPkByG0gt4LcAvJ9kJtBdoHc pFrlvR7kOpBrQa4BuRrkKpArQa4AuRzkuyCXKVd5LwW5BGQnyMUg05Tc59xRMpd4uc+Aq4iXnp0w se54ViKDmdZGxIaEkZnWesSpiHWItYhvIU5BrEGcjDgJUYWYkjAwTEZUIiYhKhDliDJEKaIEUZzQ MzstQhQiMhBGhAGhR+gQ2gQ0yiDVINQIFUKJUCDkCS1rapmwAPgeyBDIuyB/AXkH5G1ozt+C/Abk dZBfg7wG8irIr6BZXgF5GeRhkIdAHgQ5APIAyI3QFN8DGaTbUNNbEkZm8ptROacjNiFOQwwg6hC1 qIdpCAFRg6hGTMUqWxBmhInhfp7nuYTgve1hniP7QA6C8DzBspyB6MBWn4Mlm41oR8xCzES0IWYg WhEtiGZEE2I6ohHRgKhHZCH8WHgfwovIRHgQboQL4UQ4EHaspg1hFW4ADoN8DvIZyFGQT6GB/w7y N5C/gnwC8jHIR9CqH4J8APJnkD+B/BHkTZA/gPwe5HfQuodAngN5FuSnIM+A/ATkaZCnQJ4EOQjy BMggyH3Q4vtB7gXZB7IX5AbW+tww6ngr4kzE6oQRlkJ0FWIlqmUFYjliGWIpYgmiH9GHWIxYhOhF LEQsQMxH9CC6EfMQcxFdiE5EDBFFVRcg8hERRB4iF5GDCCNCiCC2TTYigJAiJAgewSEo9kgi3AIc AUmCvAWKfQnklyCHQV4EeQHkFyA/B/kZyPOg6PtBtvNB77l81PsdGvWe07St69u7t3Wd3bS166zd W7vUW6dsbd3Kq7e6AGds3b31ta2yM5u2dJ2xe0uXZIt5C6fa3LSp6/Tdm7rUm6jmtKaBrs6BNwc+ HuDNA50DywY2Dlw5cBgC5LcN7Bs4OMAPjjwqZAxMmtK4beCyAc4M8RwZoHoW7B9Q6xo3Nq3v2rB7 fZdkfel6bsrH6+kb6ylXuJ62r+9bz0GqveuzcxpZ6rL1VmejYX3hemE9f2rT2q51u9d2zVq7du3Z a3etfWSt9Oy1l67l7oErTlir1DZ+q+mUrt+eQsmD3AgxgDzKjSR41doDXJJQ8j6XFEboyaCAk0AR q6Mru1btXtm1Irqsa/nuZV1Lo0u6+qN9XYujvV2Ldvd2LYzO71qwe35XT7S7ax6knxvt7Ora3dnV EZ3dNWf37K5Z0ZldMyG8LdraNWN3a1dLtKmreXdTV3sTnR5t7Grgy70wg5BM+FuXuS3zSKZE3edZ 5+HWed7wHPHw69xH3NzZLqp3nu281Mnr4YvDL4fXcaljl+Meh1QvXvCadRnbMrh1xm1GrtAoGH9u fMMoIcabjZz+Uv0u/T16fpZ+sf59/Yheco+e3qN7RPczHT9Lt1i3VsfrdczPGwRdtKhRr/Vqhekx LV8V09ZoZ2n5S7VU0EaLGwVtdrixRjNLs1jD79JQQRPKbXxfNaLiBBVEvK8cUXIjSkp46qOUUAOA V7A2ohZvI9jjXiuVUlha7OnsiERaB+Ujc1rjivYFcXpBPNjBvoXZ8+OyC+Kka/6C7j2UXtKzh3J1 nXEzO3wW/dt37iS1nta4p6M7frOnpzW+DS4EdjECF8Szx0pqeyKLNgxs2LAxsiECXyCLNkDIxgH4 E0HhGziwkcVs3EAgSeRLPizFBoYBMdGGgcUDkAdEQPAGMZj5FolJviyP/+rnS2vy3/jQ/8mH///9 sS9eRKSEJDfwr0l1hCdyUknayEzS+SDR0huJjUymz+6rr1cUyB8GL0d89FmiIJTeKJgknNblqgmU yS7mZxuba+QXc52kZvg3rz8FX4cyKmOHaOz1oZeGDMNPGStjQ4eHigqp0W8Uxazj5HKZLJAV5crC ofKSkuJqrqw0FMjScWJYaXlFNV9SnMnx5nRINcf8lH/t81l8w3A2t9k/paNISiNBm9ekUPDeTG2w xKdvbQuU5zilEoWMlyrk4fLaQNemlqznVfaw2xO2q4AeN3D4canu6IdS3WfzJPWfPci9VdldnS3b rFVzUqXixpxMS3aRe2qrVq+V6lw2p1uuMOpUeU39w9c5gzaVyhZ0uoMsr+DwFNCIbeSo5AmpmWSR EPkdG3a6uu8n2SNv7VPr6YzA4MhbQia7Cmq0AbuWWKnOGlKrAlkq4pMEqDEQCsJULmQKaqKhGbxG E/ZkBwKZKq2VBLLs8gzPnIwuaRex19TUZNgqJxlLjKDZxYt6S5xtQ8XUEVvU67QfKi7Zev7Bg9R+ cFEvXhYVwuDkOrYY97KLf+VpRYWRSE/QasV2C/N+uY4PZIVC5RUUG8smD/B+yR6NzDqpqKQyUyOZ l3TOkWg9ZZFoqVmmoZfKDIHqkimNYaPscXofXbskO88i5ZUGLZUM60xqicyWF5CcabSoeV5tNT01 /CrY405CJOVgmZkkQiaRXWn9erkr7nWqLRY1YWe5+aESdrqpdoZhQbO3qEiePZiqeDYsggSlYXap nflK2XJJkHdCBaFCkZqhCFRvqJLGhopjQ2CkGZVgpK493zCbosIeMGxJwJ8VKjOWlpf4QSUWZumZ PC2NcoGAkZm5aexSUh6q61139szkj/wFBX7asOkHp1bZo3WRit6GnOSd9sLmqduvqKwvsNZlTp7f 9L2HK1orvPTchnVzq3NM4XzJqvxwzuwzO2Md9aUGVfGsk+hvw9W51mTcFasZ/rRgeqEzeZmtoI69 vZk18heJRhqAnn0R6i/hJpGHuaeJjthpP/GTUKqaIbamNXVIYMF6X1mhWNdCtugVlHPFug5HDg/V sC/Q2GEwMteD3zQD0FXQrMMBoDSjvBzMR2ZJ9XU2CljMmRxTETMriYaXqaw1Cwbqt790dXv3Ta9v L1/WVe9SyXiJSqfUR5uXN7Zt7sqPzTujrXFFc0yr0igkBx0BR4Yt22+dc+vHt/yAkrvnZ3hCrgx3 yJ2Z59QEIoGagR+uWn/7mjJ/jk9hjxDox8zSHgVLyyBecirq6RFi4m4ghDi5y4mS2FOVtMO6XFDq ZrvE+rnYml2QjjMGioMddL+vewdaDneM5UjH2cmjvXd/emfyWdFKZtz1wQ/mJo9EFl+1efuFa65c WsRdnxi+uRUNYvaud25deNPGaZ9fNunUH0HLQ534i6FO+SSONWK2zV0u6JUmn8kHdXLatVAi5wM0 l7Xhfi1tC4VkjrTZO8Rya2eHxXKH2X5EkB1r9hFWX+g4lbGYgQ0Rrv3/jizRPLgvdKWA33jcJVRP pVcOn8Z0w52n1KmkUjCKZDE9X6ln13plcjN9gV2vhAlAjWpSOcKZMA2okwfVNpgYQjZV8gq1Pcz6 SvPIO5IbpNmkhryGGtvrduvt7FUPCesPcNeRUtaqe/W0zQ5V2qsVeWSvhpGG92VlVcaqD9AYzKmq VI1VsAsUlJUdZrHGZrZfFGJz0zVmnYENskMwF4u9agg8aeP5zzwmbW3HdLXyCiOM5eI0K2rYyEay sYlXAkpRapXayX3buxddu2bylJOump8/N/hJhpmpm95rcJhUlml9K1eX3fDJj+f3xT+9rnPHynqX RtLgyXOosvOyp226ffnaO9ZPNptpfkG5O2RTq61e8/BwZoHTbVb13PHR9buG9yyy+UPuEma3I0fp VTCnWkheesQn3JX3CirDHJyeaAyqBWramw5IWwwrsjG1WLDQq7SZxeFQSaZW6y0OhYsztdkqg0om gy/JU+krse/DHM5DP3GTXLIt1VOyZQe4K4iReLjHBCUxBkW9wvQZ2SuTaQKDozMrjewTLLM1YimY rkUt09jhoVR/+OduTDdOwDhWG9H+JeMHBL7+nIe2rUlVTlOUQ4uiHRs3deYnhwob23LXnVbTVe7m t5/yow1VyaWjNb44FpPbqhefvaS+O0+dbM6a2gWarhl5G7pQkDSTA2lNT+OuuTe7OLtY42JzK9FE D9ACUkFUtGC/sQKctSpdh6pBWiBoprmkuR1WsZZWdrghSEfNDsaFoYgRBwfDEFOKOFIMiVNH9N+U 7Zg9S9LLRFxPRmUp//FTi4y/eMY5dy+t29A9xamWwOCgK2lf21w4o8xd2LZk1ZK2woaBXT3Rhe3V ZrmU4+VatbqwcWFFRIhYYrOWrVo2s5Ceu+L6laVWb5azKOrNc6r9OX5bXnUov6YoUji1a+Ps3p29 UZ0906yzBZyeHKfG7XdZgqWeCMZvAL1rRo7y74DFZZGulL0R2SB35V67UZaR1kMGdOl9gmeciRTT 2MHhQ2yN8g9Tjc4nY0bkT/dlcdB8RxwYH9RmloRY70g+qMKBU8VfxoZKyS2eXIfms6FR0zFpHLme zDyHWu3IY6NkZOSo3Az9s4qcjaUXlDGVhlQVFmqKB7k2QVWlsdm1wUBAkzXIXSVkCHZNxZy8OYUB NX/cGhO6siNmPwzFzqh0xCorMyrthsPidQZcw5rKJei/9FbW6dkalK1GA3zqisKKtFxcjppKTKmF aeoK1q5y6W9llrzaksqGnAzpz7iD0oxwXcVk8MiSryo5R2VJrMKt4v9A35VoveUFhZVeneRj7g+8 yl0ayy+y8so6u0cvleo9dr708+dsHoN4LVmdnWuV8mqL6XM//4rJrpVKtHbz5zn8rw02rVRqjQRh jJkOPe00/mVSQgSam1qHKW2lg9yCfSQcJpMHuQbBYORt9CMbtQ1qSunnpbSUnU8pNVpYc5ZGp+UN UrvgeiOL8luzdmZxQlZ7Vl8Wr8/yZnEaSVaWxDM48oag04BNeOwG2uY5Gm2ZyvYfSvBMfVPQtEmI PZaeaCO4su/tXdwrzgyR3lOHek+FKehgJZvJUfP/w6URB3W23QiFyspS20VmwyVlpdiXUyEScbSX Y++2ssmMP80cySvINVbsnDt907zCqZv3bZpnDE8rrFk6o8SgNqplKnfjorVTVl/Vl/+3vqlzyx3T a8p6ol6dQS436KZPqQ02r2mauaE1uzyvJs/sznLrnCGbN9sTyDTldp238NWM7BL/JKG8lM0dZ428 LSHSdSSPTCVXp9pV5S8/wPXB9BXhzoXJw6IqL/NLpIXpLgtr4lZBG2pxNRpmVIojXCU7xhekbekR roYthWyVqWmENcb+b5rHuOk+bPnCFGnEHiJNKVRutFrFGYaULrl0QcHM6Q3Z0OUzvbkOlcZTGAwW ejRZ9fVNOUt3zMtJfmbMqytxFJaUZ5b1lxXVF5jpu5sePq/JGJqc26/WqyQSlV4tDagMaplMbVAl TVmFXt2s8/YOVJ40p0iXVZ6TfKV+enH7ChhPmkbe4f38S6SM3Di6Qwk/zG0UdyheWJBnj23EvAlT i+QB2kSKwBrVatpWlC9WP5+97RCUbemNRmR0q3KwOLVV+ddyOmbPkp5XZDityMZvWKAqUrl9csu8 6MpdayrqTr9tSU5bXZlVKeXNBmOotKl4ySpnSVtJaeukkFapkUvizoBdb/M7DcLWfRvPe2JbNUwd Vr094JgcA9O75vKmb7UEvSGvypXH7K0VxpHnpKeQEOznrkppS+2qPMAtgp1KjFsvqEz+RnVl2CXR 5aWNBfpqs6C0t4zuX5v3Cbo26Yz0jIGWUiPuXLDrK79pHuMXYuP7bLHVNmp0fCg0fpNXwT+nsudm +nIc6oZrFq7Y2ZNTsuTyxa1bqtSiybk1R8uXlhdNj1gycutLnUUl5b6stHktbZkDFrWUmd3UKfQP aVsbLq1vKpqzvGzSSR3F+qyKHKa3FtDbfhh/I6SUSlNre5PJn89+nRMplQwyzfn5fFM+58p/QsKG Ohssu4nEIOFmtEv6JNzNkriEk0jcsUFcmTMKPkgTezPUYv8r0Rl0nJHXKe2wSlfaIYHyU8GdNqLI YRjehlIjXe+pi3ojQ4t62cHD66kFv6D87z5bHBZkAf84u7Uca92cJVwutpOc35+bPfw715TeabXL mgv1So2C5yQK7eT5G2s37T19SvVpd5y0bteKwo/5BYsLp8ccHD0aza/snZZlspnkGX6H1WvV6+w2 Y9WWB7ZuemR7Y+3AzYt8J23OntoRg77vGDnKXSs9HdYSG1KtYjUQWHou3luYF4RdjWdv+XRnaHDs hMG7Xyhs8s0wNIkLAXHBUwPd/GDJ8MGSg+LWSfU1bzp+J2RBLcjGr77Tu6KS9E6Iu1aiUMnkRkeW zRV2am5lCyaz6VaNuzg7u8ijXmcySSFobXbbptnhxhydUiL50BMwyeUKuTE4JTJHZcvxVMSGoyrc nqq4F2IVnhybqnXBhQuiWr3WESY8cSWv4G/hXyTVZCZZTLnUGmuWvlDOTwq0lLQ80cJ7W2jL757R UGhxzTMdNLOD2jtoxweHLNRmocRisHB6i6VvEv9pVVOeL7/2wVqO1NLaQ5Na9AuogV/wnOCbhRMF 2EbNUG9vRmWNOPOySRi8vS+JEOcPl9A1/snqFvrVDx97dlXtc7WcpJbq/+HzF42V4JgC9KZnMGgU qxXnr1BYBuOt1WbL5C3jzocrYJVQWi5+43jjL7bS0tDoqoCdvYXCYR2f8vG3WA2rrabS/gs7IzMt GlNJ9FczNs2OTN54z8D676+MGf2F3kisPBLIq1hywZy8Nj91GS3Jh9qbg5OCGe3TQ5OCpilNNXud XpNs+cLKmYVmvq8wap/qn7m5I2LRabOtniCn4IN1i6pqB+YWZws9Zf6qimKbbVZsSn84sKR55hld BSplfvLTpnZHpNJbP8ueVzE8t6CQk5oCvkxDcaktFGNr7bNgp/ACrC+KySnpHZqaW5wozjMPcn17 YVFuSJu5YZC2CUqhoCW70TEDB+b0zpKNNOKhVOLrpT92Oy3OcHLjFxcPuNC28C9o3EXZwSK3xpRd GSpcUpZeK6Q57fzmBVvbsrLSRk+Hp7WUeRrrhu9Jh4xfJwg1VasuWsrG7JNHjtKd0pmwkPKThvSZ nJV7BDbqFlhfqYiXnnGv4DA0Y+lfgsKPnb59Me6EhwQmNoczywGToVuOL7mpurNrytSuzqrRsvNb YN6BkkItCmdMntQ8Y0plqpUOQCuVkiXpchZBCbOIBr6tJMDt31tQYFUNcvcJOoFYs9TSnGZ3o3FU 7bDXgcWeuA2KDRmGi99k3U59omTjKhGmJ2iT1GE8DGNySq1W/oDaU5yTW+LPkCdfPr52VKEw+4tC wRKvRq9PfkajGrUfdoZSCTuUfymZ88XW+fwDulSTIYaq9Vmm5CvJArMH60+3QP0tpCY1Wum1FgqL KrWKaglVSwhYKzvAacSqpA5wxDV/r2tvOvjExzhfaJWsLxYMyyBTwgzfTnan9tSNJjaPZGYWq9jv iNurw2xVXkwM4zpAorVl/DF/GzTPtJbqxoJJzQUzHOP1Pu54t/Iwe1vATvzBzP6lzL6in31Zx7Ok dripppYpNe7CYKjQozYGyoIFC8tBT9lMT8as8uzowtHuqHLmen15NlXLFe0V3Q3Fxpy21tZwz5ZW 36g+OWPBcR3ziyH8memrle3ttkhVMFIdNlWt3NE2OlpBGxSTb6faIM/ElJ4pDlok08COMWGpLQ5C mvQgpIZBKM+R3TyqowzUUOocLa3of+bOrzeCWb5qBBtV2XUdXzGCHaMWUEc/jF9NsDeUgDZMJDz2 TsHMDcBKPRO+VbD4GT0WdwpKfUvAnjobdI/fyY1/p/B17xi3tkmv59KbvPS6WyKp2jJ4xqb4xklT t9x3xunxDZOSw5bijppJneUua1FndWVnuZO+vf7BC1pqzxo8bf1D57dMO2vw27Vr50RzZ62dDizI nbmW7YCTV0kI1HL8DthfrkrvgLf/ox1ws2HWv7wD/qo8xu+AT2ACX7YDhk3IovC0qVW+UVtw5Hoz YSccbp3ZEVvCdsBHjbl1xY4itgPuKy1qyLfQoU2PnNek90a9yYXpkUnym7RhrM6ZmmtuOy+xqXL1 nCI92wG/WtdcPHsF9hvugHg6tC7Vb0J6GDEFDXHqVV5VTMVreRVb/EMPgEVxh6ASIi0hvcXXbBHt Pj2mLGa7ioOpHqP66vTHLYFP1EVE/ci4A7DiVynMjswMS14BdJTjOkigetIktzbTZ1dLJRzfmh11 qtiSN7sqf/jwF7vI2uJpIT0vV6o0ljzxrcvb3IdQ+2by9tgpdHT0FLpegHlUEqXRNytgOlH92Vgh sIGgwlfB8eLRsb6KVsHAIrjE4+M32dFxi9XATqqIlRok1g9HjQL0kzo/7hUPkBf3RgxDvfB3zOG0 4PsPP+0bnFlzH1auuqSjeEFToVUjUWiU6ojQVZ5VFjYHp7bNbpsaLF50fmfeLCHfpJDwvFyjUIYq Wwuzin2GUPWs2bOqQzRzxsaZYb3NbinI9wQsckemU+fMcWZGfO6sfGF+jXDyjDxNhkWvt3htriyz 3GK36JwBszfP5/bnCz3QSraRd7lLJHvIZHIFttJ9RqN2Si4JFLDZ1aYtSPfMAthv7Q00ebTpAC07 bLE1FbHfpQrylHKgcx4Sh7aS4eKDxcb0e6+Cb5IJjvaSE2/Zjt3YWdPbXe4SdUYgVuFu/VZT1skm MzPLk9QenAUeV4m7uieiU8w+h1EuU8ukW/JjJlj4hWadPoc+g3u2p6GLS6XQxZ/GXV2yt7lZrpTL Ldmgrc3snIZ/CmbCk1M9Wh3GQxovt1jQmwqaw2qpoznbnl4sHHecwnqoOOyLOzDd10l+orOXsYVh +j3f6CnMc2xA8+faYXKbs3Brm1+sPHTpjCBMgf0V6dOXrPHz2qoLV3CjAUlFozgJcrPTIVBvK6wA 9kK989NvNhIGv3eQO3e/YPH7ZP7AINcraATi8+c0+9XOZnVqOGLvAZz218UVsNPwunOIbUJc9x2X KNVv5DR92D82u9lMtorUeT+/l/JSSfJjqTFcV15WFzJKkx/DaljtLgrmFns0kmdlsp/wWncsFIw5 Vfwuqc5o1X3+K6NFI5FqLAY+bPbpZFAZiVRp1Ayf6nBwl2qMsChW6dkKJzByVPoi1K+BXJPqBW5P RjQ/35A3yNUJao9hks4g4SdPNlQNchFBK/CGac0lzYZCtb5p8uDIz/cC84GCjl1MNvC2YLNthnJG +q1GJBI59p2I+B4k/VKEvSART+ZZnie4uwY1JJOn34bw4bHL9M74GF2Nu5S+KFO8JzX4pxYVVQcM kqs5bodEn11dVDwVfO8qpWAfwZxit5rfw3E/5LXOWDAYdan5BM/9mGML0GDMpeJvVvsyx3TJZSqV w78f06zHr4b9hUSiYorVaJhimZr1quE16pRPotQzK0pexe8DLWeTVajl/VSp1BEnzAa1+4Vsp0/l tA9yGwS9oHN6mx0qU7OqVTKLtKZX2ONUmLIm9os0pjrNCZOD2vw8dpkKUygUpqHScW+R2HGC1Szn vrNG2d6WU2jn5Ju0FmnykNZeGYsUu3XyF/hHZab8ikilS5E86LDKDXYjjcgcOr40ELQoeI3DNryb 63caFQpr0MGsqAG2t+/xj5IIuSW1X1Lpg9Sg11OjzDDI3b/fawZHQuy/yFUGjekx0DhIPYLK0aQf /f2EBxY8rakFT3GN+Ipw6BC+Gi0qJDABLeqFjeRo3v9UVuL+bFHv2G8xxGMW6h//QwHxF06UXXLv sXeFw/e7PLxSr6EzkwdNNimMkJxfZ9bKJQoYL/bRPiWsilZ6cu3K7NxohsflNnKSwjJP2KaSGdyW IrPX7TYMDyusYdDRycldnFt6GQmQrEeIkx6FodNAPyUywnMb91q86u2kJkZjwy8NvcR+WyiDAT7D ZjWnfp4W5cXComVzts658+bIrAU57hyXni9vL3O6ymeVcRp7ri87auel3U8k+199Lbn0KYPNoJDI 1fJVL7782qnrXnv58GqpQs7LdVYoTz+UJwPK4yfZ7PcIGxIZFukBKJaeeOlney1OFRaI/eZRLBHT DP5ErrSiPKOslAuHUt3PmsFlOMtmlfN6V447t8Aq65g3t0vKOwqC3hynml+1hnOe+trLL66CgkgU UKSDdNdrr9JdT2itOiiMQvpCsgPKcyUhfFxqI1Fyb8qGtMpcqsyhijClGbRQfF2n59qEQsqT3EHu 8r2ZdjW0/2/uhUCjKWOQbhWUgTm5egNVSw3sPywY/SkOtHtxzfAhGoscOljC3jjDyoX0UrZXF+y5 OTQXnjPuUewJXyc/UMriXsynd9Ss0i/1YJqV4RBVEUxtbI3iaB6XqXXK4XKFDmZhuPrg5zaPUcYp dBpqlertYW8oZle8qNSrpcvcYfb7TPG3nmq+ZYNaaswL2b1WnWKfRMpTWBUpP3uR/dCHkm7Q3YPS IKmmGSnd6ST5VBKhyslUWUnVAihvP6iJCNQ6yL23vyQIjlQ+wL1H1CPvQGeFKDXV8+q8Qbp6v3FS pc9X6Uqtz13pLuaCOEFbYpVFOwyjO5SecT94KsbFYUT87WHlEGXvQCNj3Rd0vqiXacslmI4pHZRK z/87n8waZlFv6mnHNkwF9KHj3rfKStI/bZSLPyd4UMo6vt3qMytlBof5jbo5UaMltzpvyoKGqFap VUh5mcpRt+Q0Yfk1y4rsM3asv4YmYQaQnezJdaoVtvyAPxYMWI40bljcnu2fku/IDHo17liWzWsz 2oMBe8mCrU01W3buPvUGjSMX2q6LvcmBtuum01IzsGI6VTVS9fx0o82nRYPcM4J2ZkdophCaOTMk 8DrXA9zbhIB+WAIde38iNqIONKlrOEDnkilESRftN04BZy1PKbQ8rdBy9l/oNHfkD1KJYPT5pM3s pym0bfT3KXPH/T6FLcZiQ5UGUb2jv31hTXs4MgSTdCwWg9XuWAO7BG2qAlBwPf+fL8xYa6d3ITLx /HN0E8IFxt61p0NO1PyWTJ7f33Lu4Cm1G3smZyjlvMGgKpqxYlpF5xRPoGH19HXaDA0skI2aUyfP n+qzRuqjpQubSzQKjULCyZTm6kVnNC367tKSzMnzKuvXtObQM/qvXlFmcmcazK5cWH26vC5nrC63 oKnELbeGvZ6gWeEqnh7xT4k4vEGf3BzKdPitBlMo25HfsXnGlBXtk3S8oqx9OeFINqxC35SaSR6M jh+lerhZHqXyCJW5qdxA5Toq01K1OEiqmSEUguqjfph7V+4LSySk4AFOCWvZDwUtRFpd0dFZcu4+ CdQyMkiX7xP8c1TpX92AlkuGIwdh+mUdOFYyVIzTZ0Q84WSNXB7W03CUhiM05KZhAw3raEhLT1Am sShf/4nYmqnHpD74wmT07UjZaGemYyOrlQaon3/TkrFBk1kYYu+ukkadVQ8TjFZFL5faI7WxkqaI eYPBllzNJXfTeXRjSdk76ZX+O3JHLOyLhbJM3JNKrVIC2yD1558UcecO34X/U5ib0NG2L3Xvc+eM c++i47efyEmajnPb/s1ueLyT3j/mZPavcIkJ92VOftOXOYWgeOmLTrkenar6BO4n/16nfv6LTjND dN//R07rF93SMacL6u4c7/TeL3GPMWcQ0BlNJ3A//iYuI3RCd7WpeZy7P+3MrRNuwk24/6i7wvza /7vOstk6z7banjvhJtyEm3ATbsJNuAk34SbchJtwE27CTbgJN+Em3ISbcBNuwn0zJ75H5lL/2oiZ 8Kl/kVJGFhL2G7pc4ibLyCISg5gwvZ5y9DTqpBfTXvoc3UokNIfeS9fSy2gmfYxk0KepnthpO51P DfRCOkAfpWvIRjKPf49/nz/CDxEjfxZ/NpGQ9ZC3hP2bJYQcyR0ZgW/KvsEvge9//xOJmHcG1JMj 7B9aURDS2VlU1rCxsFCMIfQy9n/o+5ofxbHeI+TIyDEBqX+5RaIbE/oz4K+I7Z+WM8lOSRWZdSKR qsnO8cL/+euL1EGa/5FwWWTn/2aR1H658D8hNSeUvxLNvyJygUQmZEL+WeE/ItP/WZG0krP4HtL0 dQTSth4jctLydYS7gDj+Nwv/LHF9HWG6Sgv9Gzn5mwr/Mug8JeA/ocjOGXvWCaUN2uOfkXH3cq8c K3wRaf46wj1FbP8tgXJu/rrCP0Os0r+SwImE/ymxfkGipGFCJmRCJmRCJuT/VuHOIieD9E/I/30C e/UrSTfpItmwgee/4hyA7fOlNw3uid/zwGJ91SfEgQcDB/5y5nOMT2Zdu/6zV4d3Kt+VPwlpleLZ A3z+Dwbx5yYKZW5kc3RyZWFtCmVuZG9iago5NCAwIG9iagoxMjQ2MQplbmRvYmoKOTUgMCBvYmoK PDwvTGVuZ3RoMSA0MzkwNC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk2IDAgUj4+c3RyZWFt Cnic7b0JfFRF1jZedW/v6+19S3pJp7uTdJLOvpM02UMSIAmBBAgQdlD2VUBBwQ3FFR1x13HHJQkg ARzFGRzHmcFtXMYZdfSdRccZHJ3FBUznf+rWrSQgzKvf9/2/931/H7l5+jxVd8mtU6dOnVoaEEYI 6dE2xKPJkzpieUj8uaMFPqbOW9a7kqb3fIwQrp+3fq2/745jr0PGuwjJkxauXLTsiy9adcC/Qkjt XnThRQvp9fmLEWosWrygd/6fQolxCO1thMyixZChf8Jci5DRCunUxcvWbpT+3gOQt+PCFfN6aXrz vQh565f1blwZqOF/AOdKINO/vHfZAun6HPhwr1yxZi1N700j51euXrDygqe4BFzfBY8XEFLejVDi ZjT2ZzJaitZAebehK9AudDN6Dv0WzUXbge1B96KH0KOoDz2PXkJvo/+DP4mL5MuQjj+IFMiC0PDJ 4ROJhwCDcsOYnJshZZH5R3OGheFPz8j7NHHzsJAYVJiRRrxXz70Ouf/AQ8MnuSqSHi4iae5K4Ebx js+VdyeeSjx8hg7a0HQ0A81EPWgO6oXyz0eL0RLQzAXoQrQMLRdTy+HcIvhcCKnZcNU8uIrw0atW oJWA1WgtWofWw7ES+BopRc6tEtPr0AY4NqKL0Ca0GW1BF0ufG8ScLXBmk5jeCLgEbYWauRRdJjIm ac52tANdDrV2JboKXf1vU1ePsJ3oGnQt1PN16Ppz8l2npW6A40Z0E9jDbnQLuhXdBnZxB7rzjNwf iPm3o7vRPWAz5NwtkHOPyMjZZ9BP0QH0JHoKPS3qch5ojWqE6WWhqMOVoIMtUMLtY96Y6m/DiLYu gbKTsu2USroR8i8bc8d6SY/kyu1wJX0KrQfylIvP0MQNUAbKR0tEU7eI5R/NHauVf5fL9HHnGM3c IaYIOzP3XPxWdBe0wPvgk2iVsPuBU3aPyMfm3z1y7b1i+ofoAfQg1MXDImOS5jwE/GH0CLTtx9Be 9Dgco3wso/JJ9IRYc32oHw2gfWg/1OTT6CAaFPP/3bmz5e+T8gdGcg6hw+gIWMiz6Ch4mh/DwXJ+ BHnPSbnHxDya/jH6CaTJVTT1U/QieKifo1+gX6JX0AuQeln8/BmkXkWvo1+ht7Ee2Gvoz/A5hF6V /wEZ0Hjw04dBz3eiWWhWvGH+7Fk9M2dM7+7qnNLR3jZ50sTWluYJTY0N9XW1NdXj41WV4yrKy0pL iosKY9lZmWnhUGowxee0mgSjXqtRq5QKuYznMMqsC9bP8feF5/TJwsHGxiySDvZCRu+YjDl9fsiq P/2aPv8c8TL/6VfG4cqFZ1wZp1fGR67Egr8CVWRl+uuC/r7jtUH/IJ7e1gV8V22w2993QuStIpeF xYQeEoEA3OGvcy6u9ffhOf66vvr1i3fWzamF5/VrNTXBmgWarEzUr9EC1QLrSwuu7MdplVgkXFpd WT+HVHryZ/v4UF3v/L7JbV11tZ5AoFvMQzXis/oUNX1K8Vn+JeSd0TX+/syjO68dFNDcOVHd/OD8 3pldfXwv3LSTr9u588o+U7QvPVjbl77pD04o8oK+zGBtXV80CA9rbh/5A7hPHhKC/p3/QvDywRN/ PT2nV8pRhIR/IUJJEUfUBOcZR/Bu8IZQvkCAvMs1g3E0FxJ929q6aNqP5noGUDwW7e7j5pAzR9kZ Wyc5s42dGbl9TjBAqqpujvS7frGzb9tcf1YmaF/8DcEvnPf38eE5c+ctJrJ3wc5gbS3V25Suvngt kHivVNa6/pwYXN87BwqxhKihrasvFlzZZw1W0wsgw0/qYElHl3iLdFuftaYPzZkn3dUXq6sl7+Wv 2zmnlr4geVawresQyh/+oL/A79mXjwpQN3mPPnsNVEq4bmfX/IV9vjme+WCfC/1dnkBfvBvU1x3s WtBNaiko9KV/AH8uIP5F8S4o2xlXs4tJyZUhlb+L8/DdpLYgw18PH8HqCjghQHWJSVKj1RX+LuxB 7DL4K9IVhJ32HEjwoZpGcoont9Y0egLdAfrzb17JI72TPNSnGvMsATJG3on+nXO+Gr2avFC6v25B 7ZgXPO2hcukFpaed/T05ogvpD8MdKlKdjewUH4KWC3kcPEbMIrXo9Pehyf6u4IJgdxBsKD65i5SN 6Fqs3+aOYHPb9C6xtiUrmXJaip4voak+FIDTLMHVgA3WRz2sWsV0g5geSTaecbqJnfbvVAWbO3aS hwelByI/tCAotCLc1HtNibkAmmY9eLdgfW/QL/jrd/YODm+bu7M/Ht+5sm7O4jLyjGDT/J3Bjq4K j/iu7V0XezaRP2VGzbh5SnVWJvie6v4gvqqtP46v6pjedQgCXP9VU7oGOMzVzKnu7k+Fc12H/AjF xVyO5JJMkvCTBHlSOyRU4vWeQ3GEtolnZWKGmJ43iJGYp2J5GM0b5GiewPI4yJPRvLiYR36gkpyL QcXgbuv880n1bOlevHNON2lcyA5VCb+4DwcrUR8XrOzHnELXpwkuqO7TBqtJfhXJr6L5CpKvBMPA dgzKIT5p55wg+CkwqC7kwdQUefJI/+Dw8JSuwHHPie4AmNpMwPSuPnUUfL88NAGuayCYA9kNfdvm 9ZL3QJ1d5F5lqGleN5gteyBc0tSnhieopSfAFfXiPcQc4aZ5UDdQgeL92yDRt627rztK/mjXkm7R nIU+1Bgsg2qnz5SHyR+Kde80B/PEtglNQRO6kgg1vBvq6KI5HkjCH+umSlLq4M3nBeHUvDl+0LYM zesAU6e+VOOhOQvAJcrCC0RoPNJJRIrFh7R6TZ86Gx4Iv4Rrs0mTlIeU3d305cXUldIF8LeFPi28 UXiMKqUbQDtwqom8C/xeCa9KLn2ePKZtELUHN4JnIS8tPkkJp/v0oaZecP70fi3kBEvYzSriI7TS M47RXCUpuQ70zoemDA4/HLwoMOYnKzNIOgdimMhzCAwbde88M6NvRjQrU3Vmrl7M3rlTpT/7DVRf Kv2IJJn+Oug14EIYEytQAuFjmntPnTx5r/qvJGfsD3+c5BhTsB8JEJspoT0IKIZgdGq6YXgYagcP qHn/ILdjv9qJJwDZzshljFzKyDZGtjJyCSMXM7KFkc2MbGLkIkY2MrKBkfWMrGNkLSNrGFnFyEpG VjCynJFljFzIyAWMLGVkCSOLGVnEyEJGFjAyn5F5jMxlpJeROYzMZmQWIz2MzGRkBiPTGelmpIuR aYxMZaSTkSmMdDDSzkgbI5MZmcTIREZaGWlhpJmRCYw0MdLISAMj9YzUMVLLSA0j1YyMZyTOSBUj lYyMY6SCkXJGyhgpZaSEkWJGihgpZKSAkXxG8hjJZSSHkRgj2YxkMZLJSJSRDEbSGUljJMJImJEQ I6mMBBlJYSTAiJ8RHyNeRpIZSWLEw4ibERcjTkYcjNgZsTFiZcTCiJkREyMCI0ZGDIzoGdExomVE w4iaERUjSkYUjMgZkTHCM8IxghlBEsHDjCQYGWLkG0ZOMXKSka8Z+YqRLxn5gpF/MfJPRv7ByN8Z +ZyRzxj5GyOfMnKCkb8y8hdGPmHkz4x8zMhHjPyJkT8y8gdGfs/IfzDyISMfMPI7Rt5n5D1G3mXk t4z8hpF3GPk1I28z8hYjbzLyBiO/YuR1Rl5j5FVGXmHkZUaOM/JLRn7ByM8ZeYmRnzHyIiM/ZeQF Ro4x8hNGfszI84wcZeQ5Rp5l5EeMPMPIEUYOM3KIkUFGDjLyNCMHGNnPyD5GBhjpZ6SPkacYeZKR Jxh5nJG9jDzGyKOMPMLIw4w8xMiDjDzAyA8ZuZ+R+xi5l5F7GLmbkbsYuZOROxi5nZE9jNzGyA8Y uZWRWxjZzcjNjNzEyI2M3MDI9Yxcx8guRq5l5BpGdjJyNSNXMXIlI1cwcjkjLOzBLOzBLOzBLOzB LOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBLOzBqxlh8Q9m8Q9m8Q9m8Q9m 8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m 8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9m8Q9mYQ9mYQ9mYQ9m0Q5m0Q5m0Q5m0Q5m0Q5m0Q5m0Q5m 0Q5m0Q6u2UcIRM0D3kofxMwDXhuIy2jq0gFvGYhtNLWViksGvDoQF9PUFio2U7GJiosGkseD2DiQ XANiAxXrqVhHz62lqTVUrKaZqwaSq0GspGIFFcvpJcuouJCKCwaS6kAspWIJFYupWETFwoGkWhAL aGo+FfOomEtFLxVzqJhNxSx6Xw9NzaRiBhXTqeimoouKaVRMpaKTiilUdFDRTkUbFZOpmETFRCpa qWihopmKCQOeJhBNVDQOeCaAaKCifsDTDKJuwNMCopaKGiqq6bnx9L44FVX0vkoqxlFRQa8sp6KM 3l5KRQkVxVQUUVFIH1ZART59Sh4VuVTk0IfFqMim92VRkUlFlIoMKtKpSKMiQh8dpiJEn5lKRZCK FProABV+ep+PCi8VyVQkUeGhwj3gngjCRYVzwD0JhIMKO820UWGlmRYqzFSY6DmBCiPNNFChp0JH z2mp0FChpudUVCipUAy4JoOQD7jaQMio4GkmR1OYCiQKPExFQrwED9HUN1ScouIkPfc1TX1FxZdU fEHFvwacU0D8c8DZAeIfNPV3Kj6n4jN67m809SkVJ6j4Kz33Fyo+oZl/puJjKj6i4k/0kj/S1B9o 6vc09R9UfEjFB/Tc76h4n2a+R8W7VPyWit/QS96hqV9T8faAYxqItwYcU0G8ScUbNPNXVLxOxWtU vEoveYWKl2nmcSp+ScUvqPg5veQlKn5GM1+k4qdUvEDFMSp+Qq/8MU09T8VRKp6j556l4kc08xkq jlBxmIpDVAzSKw/S1NNUHKBiPxX7BuxVIAYG7DNA9FPRR8VTVDxJxRNUPE7FXioeG7CDv8aP0qc8 QsXD9NxDVDxIxQNU/JCK+6m4j4p7qbiHPuxu+pS7qLiTnruDitup2EPFbfSGH9DUrVTcQsVueu5m +pSbqLiRnruBiuupuI6KXVRcS6+8hqZ2UnE1FVdRcSUVVwzYekFcPmCbC2IHFdsHbAtBXEbFpQO2 ThDbBmzgjPHWAVsRiEuouJjevoXet5mKTQO2+SAuordvpGIDFeupWEfFWirW0EevprevomLlgG0e iBX0YcvplcuouJCKC6hYSsUSet9iKhbRN1tIb19AxXx65Twq5lLRS8UcKmZTMYsWuoe+2UwqZtBC T6eP7qZ/qIuKafR1p9I/1EmfMoWKDiraqWgbsMZBTB6wkr8wacBKzHvigHU7iNYBaxaIFnpJMxUT BqwQF+AmmmqkooFm1g9YLwFRN2C9EkTtgHUriJoB6zYQ1QPmehDjqYhTUUVF5YAZ+nc8jqYqBkzd IMqpKBswEdMopaJkwNQAonjA1AWiaMA0HUQhPVdARf6AKRNEHr0yd8BECpYzYCJtM0ZFNr09i/6F TCqi9GEZVKTTh6VREaEiTEVowES0lEpFkD4zhT4zQB/mp0/xUeGl9yVTkUSFhwo3Fa4BoQeEc0CY BcIxIMwGYafCRoWVCgsVZnqDid4g0EwjFQYq9FTo6JVaeqWGZqqpUFGhpEJBr5TTK2U0k6eCowJT geLDxrk+goRxnm/ION/3DfBTgJOAryHvK8j7EvAF4F+Af0L+PwB/h3OfQ/ozwN8AnwJOQP5fAX+B c59A+s+AjwEfAf5kWOT7o2Gx7w+A3wP+A/Ah5H0A8neA9wHvQfpdkL8F/AbwDuDX+gt8b+tzfW+B fFN/oe8Nfdj3K8DrwF/TR32vAl4BvAznj0PeL/XLfL8A/nPgLwH/mX6p70X9Et9P9Yt9L+gX+Y7B vT+B5/0Y8DwgPnwUPp8DPAv4kW6V7xndat8R3RrfYd1a3yHAIOAg5D8NOADn9sO5fZA3AOgH9AGe 0l7ke1K7yfeEdovvce3Fvr3aS3yPAR4FPAJ4GPAQ4EFtlu8BkD8E3A/33AfyXu0FvnuA3w38LsCd wO+AZ90Oz9oDz7oN8n4AuBVwC2A34GbATXDfjfC8GzQTfddrJvmu0yzy7dI86LtW87Dvcj7k28GX +LbjEt9lnds6L927rXNr58Wdl+y9uFN7MdZe7Lm4+eLNF++9+LcXx80KzZbOTZ2b927qvKhzQ+fG vRs6D3NXoIXc5fGKzvV713XK1lnXrV3H/3Md3rsO167DOeswh9YJ6/zreN3aztWda/au7kSrJ6/e trpvtay8b/UHqzm0GmsGh4/uW+3x1oOMb1mtF+pXda7oXLl3Refyhcs6l8ILLilZ1Ll476LOhSXz Oxfsnd85r2RuZ2/JnM7ZJT2ds/b2dM4smd45Y+/0zu6Srs5pcP3UkimdnXundHaUtHW2723rnFQy sXMi5LeWNHe27G3unFDS2Nm0t7GzoaS+sw4Kj5KEJH8SL5AXmJgEb4I8uDrHE/d84PnMI0OePs9R D282un1uLt3owjWTXHiFa6vrehdvdL7i5OLO9Mx6o+MVx+8cf3PILHFHenY9sgt2v523kbLZW6fU i7KqlsrcQrGsrfZguN5ow0abz8bV+WwYmT4wfWbibc8Jrwic0YiNxmEjFzfC5UaDz8CRj2EDHzfk Ftcb9T49Rz6G9bw9rocc8sSIbvKUeqPWp+U6q7STtFxcW1VTH9dm5dQjHvsxRlgAwavIW2Cbrx7a 9T47lmPoz/undESjzYMq1N7cp5o8ow9f1RfqIJ/xtul9iqv6UOf0GV39GF/X3Y+5mil9VrLqK6Yv 37ULVSc39yV3dPXdm9zd3LcNSJyQYSAoud+Oqrujs9asWxONrp0FH7PWrI2Kv5DC60gqSjLJ75q1 kCbHOjGNov/2h14GYvYa+FnLMtf++7v+u//g/+oX+J//04/IRoXxw9wONJ/bDrgMcClgG2Ar4BLA xYAtgM2ATYCLABsBGwDrAesAawFrAKsAKwErAMsBywAXAi4ALAUsASwGLAIsBCwAzAfMA8wF9ALm AGYDZgF6ADMBMwDTAd2ALsA0wFRAJ2AKoAPQDmgDTAZMAkwEtAJaAM2ACYAmQCOgAVAPqAPUAmoA 1YDxgDigClAJGAeoAJQDygClgBJAMaAIUAgoAOQD8gC5gBxADJANyAJkAqKADEA6IA0QAYQBIUAq IAhIAQQAfoAP4AUkA5IAHoAb4AI4AQ6AHWADWAEWgBlgAggAI8AA0AN0AC1AA1ADVAAlQAGQA2Tj h+GTB3AADEBoPoY8nAAMAb4BnAKcBHwN+ArwJeALwL8A/wT8A/B3wOeAzwB/A3wKOAH4K+AvgE8A fwZ8DPgI8CfAHwF/APwe8B+ADwEfAH4HeB/wHuBdwG8BvwG8A/g14G3AW4A3AW8AfgV4HfAa4FXA K4CXAccBvwT8AvBzwEuAnwFeBPwU8ALgGOAngB8DngccBTwHeBbwI8AzgCOAw4BDgEHAQcDTgAOA /YB9gAFAP6AP8BTgScATgMcBewGPAR4FPAJ4GPAQ4EHAA4AfAu4H3Ae4F3AP4G7AXYA7AXcAbgfs AdwG+AHgVsAtgN2AmwE3AW4E3AC4HnAdYBfgWsA1gJ2AqwFXAa4EXAG4HM0fvw1D+8fQ/jG0fwzt H0P7x9D+MbR/DO0fQ/vH0P4xtH8M7R9D+8fQ/jG0fwztH0P7x9D+8WoA+AAMPgCDD8DgAzD4AAw+ AIMPwOADMPgADD4Agw/A4AMw+AAMPgCDD8DgAzD4AAw+AIMPwOADMPgADD4Agw/A4AMw+AAMPgCD D8DgAzD4AAw+AIMPwOADMLR/DO0fQ/vH0PYxtH0MbR9D28fQ9jG0fQxtH0Pbx9D2MbT9/2o//D/8 p/u/+gX+h/84Z89CcoQSa/jX5QbEIyUqRa1oIprxDNKDSdtRGT5wwFZbq8pSPgvmyiE/GLwKYVwT N8o4/UG3uyp4sFCxizc1weB9f5VyF7jyqqH3h16ODb1/wlwaO4Fj7334/ofC5y+bSmP5H77xYW4O NgVMIqwGTqm0KoIp2VxhJFyUn59XyRUWhIMpBk7MKygqruTz87wcb2U5lRxJY/71b6bzk4YU3CXB qqn5cq/baNUr5FyS05xVERI6ZoQqspOVvFLBy1XKtOLqlOYL61J+ozQl2+zJZpXKnGy3JZuUQ7+V G07+XW44VSO78NRuXlE+syqVv02j4mQKxaDX6cooDzRNNVoEmdYimOwqpdmkS6udOXSFLYk8I8lm o88aagW1BIdPyi6RW1EKCqO7DqHU4Y/36wTcEhyUSHhw+LP9WiBaRmBM9VncTVhIIJ968VMnfsbT cIicztTi1tRgOPRPnVbnTEkOavTYLtMhnaDjngo+F3wlyAd1QZ05ud3cKe9EVVVV5tLSWKynx+Qo NQE15Qsn8kz5oPFoD61uiNZDdrtCVHmED/AGPpgSDhcVY6pnhzLIB2TrVFgI+Xwhi1q2YuhPS3mN JZiUHDJiFR6Q6V0Rrz/DbZBtxr/DPx5n9xhkvFKnxuWJl9R6tUxu8NhlA1qDiudVRu2uoc0IbOpx hGQYrMuLoqgE/Szu9jkF3OoTjORDDx9OHXz4oaxkHSSe5rbF4bwtDudtNm0muTiTXJxJLs4kF2eS izMPQ9yDho8eAI7C+aDpfXAlyM/2GSWpF+UX+3Si/HiflkhOiOvv1R7Vclp35J+5ucpUcealrWAQ a/uVU1DViSrRbktxrOdDUWl5b0QpgexotJRyUKrVIAsGUsKFpoKi/ABoz0bs2cvjgmwuGDQRY7aM Uhn2lUyat6op8aQjPd2Bw2t3z8uzR8dnFM6sS0sMuUumTxg4VtNe5JoYarig7eWT5V01Ybxm3KL2 ygybLyK7LOLLnLKpNXtKQ4lZU9i+nMOxlsKkRE+wfNLQe2VdFb5ESVJxO8Kod/gzmU7uhVY8d18S Ko9KWolKWgH5V6IVkJ8SrUQlrUSfhTjSgJw4hgIojDMHLB2yIzgDFaIcnN2vngpN+o0TBDhGiy+8 dSw3J2Q1KMY0S4VNaqakAdusXo6Um5iVTMfJVdb47M1Nl/zi+taOW1/bWrJ0er1HJedlKq3KkDdp 1aSpu+YXF867YUbrmrYCo1Kj4A8KTrPBmh7xTHng87vu++apmTZ/hsdgcZutSRZ1JBapu+L5LZt/ tHV8OBZWmLzQAomVXQ9WZkY+tCGeXBXAFmI5FmI5FiuU2WKGAlucUFrLEWI5yE1145Z045Ysxi1Z jFvSjfsIxLZq0I1uwNDmGcThfjm1EqaLN5hF9BCPdppJKMcYwPVTH/zsocSnYvWHHvn4rrYDBSse u+Kp/i2PrS7lbn/k1IPttKKn/fDjPUsO7Jjwjaly2/NkxyeUjN8CJctE6/vdEalGI9JbR6S3jkhv HZHeOjLImeJqtcVv8cPLuwexKq7fFsZHw/jVMA6HFS4yCalvi4DoV4xYfc+q1VCsmOhGBMn6xXrm vmXpwYDpDMpvkWn0qqGbSQm5hSq9Si6Hj4QCD6jANcjUwCdyWKXXyBrMHrOKllZl9ljNHpMqsVQt JFnMbkGZyFWZPGK5h0/yU6DcETSzX2mRym2Rym2Rym2Rym2Rym2Bch/QJyNvshKKts9icSkGcdq+ lDYXcZBSjxQ7ZiodKR3+VmFYb8OKy0+BgikToD0lvLzI4yqr3+1MsaqgqPVi7jFLEpSiUSl4bBaP ST30R6VeKZfDh+xJUspkUqIZw5/KNsr9qArdH09OSjI6iYU6iYU6iW9zanSEQSmcpPb06LkI9kfi kTkRPmKUym+Uym+UWrJRaslGqfxGsgMyVoALnINYsz8lpTRWeQRroI/X4PSB0g7rIM7sj00l9Q2t 2UTVIfm5N3p6jo04Okkvp7XmomITsQLS2kVtmYgHHG3/MtlGmUqn1JXM2j79gsfWV9VtenRBxebC xBsmk0wNfcQdWrtZYy6bOXd+7q1//eHUnkdP3DDhsgV1bo1sliXZogpnhyfufHbFlqM7apOT8UUp qaBGlUpIMics7nByilPX8/hnu28/2dfrDqa7U6h9yCZDnxtDg/urcnFQJ6lIJ6lIJ5mITjIRnaQi HVFukiNVS7SvJdrXEu1rifa1xD9oSR/hQHEbdCxxC/kQTBDPx+E8cpCJOThB5NNwzpHRDh1IZtx4 VIdf1WHd6b0xNKgTVRh6jTeIWiWTG21YPaERUxtrddRr2iCPUdlklTXgdPutqqF9wFzE8lTWFKcr YFVxraItAnOD9sHkdCqucujHjMt+w9jQSU7BuNS+cBfoz4YmH6xyTHI85eCRpEIkqRBJKkSSCpGk QnQYfKJm+OhB0IRGaBeLC8UccYShbxUGd7H3VtsCDtfYtx19Q9bqv4K3ykdz46Zc0hhySJ3ECAto pPfTSO+nkd5PI72fRno/DalinS3SHtAInnZhNDqqYk4btA+f9D3D4Qg+i/qloMhmVSgxttv5r5TW FE8w065MpJ5ZB/jnCsERcLv9FqXenOjAL5uUScQBKgQNd+XQRSOuYLQunueq1DqlTA4ZerdjaHjo drdF8vXNUHo3ajyEbLSwNqmwNqmwNqmwNqmwNrKXF6mN7bZBHJWcOY4dZ5UxxnuPGBZxas3gkdVD xxzpI4V4lYRwzVaPRQ2++Un2qqfuU5uSpJpRRMEfV6DH48KcypWVnD4nxxGLabKdTvfgd+xMScV4 U3N1Og1pfRrS+jSk9WlI69OQmtYQ24K4Lu4ihpZa1KZ1OvQxZ262wpfW5utkjavKDEFuPhSURWcQ 6QojzFQ6LpafT2LfMbYYxCTehcgXB0/z8WLoi/NJfYv6UURVVp/LEbCouEQ+r7UlW21eq5ZLNGBo aS4nVHKmZ7E/J9Wpxhvk+Aqt2xd2LTN6LLpRk150ardSo+RlEMrA4GLPSP5DGak6d5rnm2n8Q94M l1ZtSbaRbywNn5B9LA8gC/R1W+JuK1GNlajGSgIXKwlcrEQ11kEuP672oxzxX0XwSjr3Sjr3Sl2C V+oSvJLOvUcguNMgF3QAxo4gsRH51NMDmJ4xMe1pAy0xfhkTzck+nnDz+7tvevOa2gm73999/Ru7 6g5EZty2cuVts9PD03+wetXts9K4W+/6pn/2tIe+uHfPyadmT33wH48u/9E1E6dce2TR6qPXtE65 /hkSq0EbfxEsKQmlo439qQqpIAqpIArJeBSS8SikgiiI8ThMyUQ9yUQ9yYJOj1uSyWggmWyvQqYQ 9Hr7FAodFFO7z9amG9Pp0zBNOL3fD57Z2cvGhGz8i/ENT2y8WW0JuEj7yHBjW0brkmUt6QfKp/Vk 3nPHxEX1qfzNvXcur0hkj9TwY2kpSkfVzIumTVpaYBj6Oq1hHhJreLz8SqjhCCpH18WTNQFzGilF GilFGqnkNFLJaaSS06AkcQ3yJ+UkbUvik/Ik5eRJysmTajlPquU8STl55DsQ5oBGnzWI0/c7OkKy YlLVelLVbxwnSigdre+Rfr40N0cuaSCiGBvMS6MZOT7DAqAUGp3C2r12R2XurfOYJVzzq+sbLemV GU3LG9OsqsTjZxrFaofPpAhUTa/wZk596Mt7b/+aWMbf72rbvWNlVkVNitES5D5Y/sw1Ezt2HV68 +rlrwUx+hKidyLRgJ0WoFt0Y9wrZpmIVFLWYaK1YrPtiosViorZiKP/BdDJyTK8yEV0BM0k6M0kG ZZIMyiTpzEQ2qyVlCxAdP70yjuNxxziwmwOBNofkZMSY+MSI4saMBEslxyoOpLP5bxmS3eHlpQGh w2K344JwJBxmQwGtwprqdQesWtkGW1bllPI1zMRgaGDJHe9uXjMxEqyeWeovyEqzrjWoEkO1k11V +Tc+Ujuv2gdORgXRtKDDuQXTqoJD74yYHgSacl5fMnVFzfhFk8qshmjFxNzE71OT+ctbljiUikRL oHwy+PGG4RP8PLDFJvTRITR++OP9RgG3jJdUNF5SnSh1ohRVNX6Qy4xH8+IWK27Ji5twa2peap7O 4yT3eogD9wgC+YBbPKQ6PIe5XOLF93nEqOHoPpckrVQ+bSQhlS77CI6gYghOw3GtyV+Mi+NaHW4x kZVSDWHFpmKTvQIi+QPjPfL0DjvYtuS9oApOmMg4JRrtEU4IpIGPxlhmeuIMtyZjtk0nmrIV5xi4 Kvh5NRvu6xm/Ylq5QwshrcqQP3nVhJKemtS89iXLF7fnly+5cUp0WmuFRSHjeIVWqY3V9pQVTS5w 53UsXb60Ix9fMOM6GN77U5whnz3ZrExJC3qLJ+cXTyzPza+csmpS29apWUaXz6I1OS1mGM8mBZOT c6pDRRMr8vLHdayCOjKCh3wbLD8FLTjojJOxgYlobT+Jxb6zuyQdqWn46AFi+QozGQYlSx4xD4K1 z0XlvBAVjkVHBkGj4SjzBGKo8LY4eNvNoh5g0uCO3yEO7cSxz6m7RwxxrsqUZLHQ6TESOTwG/dtF ENVE0Z548pws7Cet1k9asZ+Yjp/0/X5iNeTbSHHT2MgbLA3ZpQLbpQLbpQLbpQLbpQLbD3MCiUpJ fE62LMTV8AhNuF1o94zajRiOS34wOmoiPfjbAaDk8kZzZBfVbRtcd0HfJbV0+GdRZXasa2pe1xYV VROwqPH76w9tq6686OkNfJCp45u/T7+iOyuz67JpvGNspDsO4qkPQCsVaNG+cAUGR/5VvIYYfQiq R0VIWgyHBDEnhFOchKSnYKefkKxcnJWDs1JxVhAXt2e0B3O0/Nihh6O0qgpKBT9k8k86QiPxD89Y OFxUNCb+GcPsdoVSvl0mJKV7fdEkgyzxOXeSN7jT/YHMJCOfeEyBTWG/L9Wi5HAQYyuvtoa8SQGr msfpHE7mFZZgsjcoYHnYYCKjf5OBf+2bGOOyvQ63QcarDNpTx2RlWiN4NJVRe+qnsnINcLnB7SD+ fyZ4qir+5zAWiKO+uN9Y7auOVfNataNAB9VeQGyngJhNgUDcUMEg/jJuQJGIEWEdItaFyiQvVkYs RC9JLZWi2ysb5FRxq8nxAioQCrjyowUYwdi5IHt8xiD2xI2vpuCUFFnyJ9kTxr2ra5WhGJsnEYfO Patm9bAg6lh0Vk+pNGeSB53DLIg7SYcaDhcWjulY8wul/lTKkYl2paSOx06G2HyVkORx+wzlN7Y1 rGnLqlz7yJIt9tyJpeN6m3J1Kp1apvRUT11Y0HvVlPADu2rnV/u6J49fMc6p00HUo5teVR+qXzi+ ZeWEUH3B5EJPcjBZJbiMrmR3MNmS2XnJlGOOrKr0+o7qWtDuHtDum/JVKAONQ5cfgIahCRRJLapI amFFkr5IWtRX0SD+Ku6xRUm0EvWTmUSi/yhpz1FBnGDkNHE1smmKCgMyec4glj8dnuCpF1pKgfbL W8UWCCp0lLKALDqqs5E2GLF9uzFS42QBqdJkt4sh2pv5827oiTbV10dUZo/NmmRWKC1+p8tvVqU1 Nzamzb1mWtqTtoKpcX9lvC5Su6WmsqvYhT9ad2RHvSlclr4c2qNMBu1RXiL2qvAx9Mf0kqAwcXvf urrL5o8zZ1TnJfZ0TKuYtxla7HTQmJ9/CRWiq/uTxN6MjpU/kMbIH+8nQ5azTNF9evrU3PAndMqO 08b1MQM2uD7yxTX6Rl/qIOb2Wybwf8klvl6tb8zNHMSKfnUrmX+NnhA/RqZrjo1Mzp0xCaugXZli 7BQs7+fkSldFc1es99YFheNX7emOttUWOtUKzqw3Rio6yzZsDcR7KkqnVkV1ZOByv8ll0rtCyeb4 5n3rLn9uU7ngTnEaLE5zxBdICxx8ctr2rmhqNKiyJJN2Ogf0cqd8GQqjUnRN3FdVjrWeUtI6S4ln LyWRQSmxjlJiLKVH8NcIoRjVWkxSVkxSVkxqsTFJWTFiUBpLoF5bGvHIDBlkK6RzAjR12T5Dq7yF dGaiOVWdMRsr2tPI0G9sE4TQbMSq+HB4bHBbzN+pNCVZyQJPw54Z866dlpY398bZk7bHlVYfsSn1 QzUX11aBBYFFjQ+Mi9dHXMyANrRObd3eP3ftkR0NdTWclo34h+rAduZuiddetgBsqSaXaKsHtLUH vFoUFaAn4xmxoqqiFUW8hbQmi59MbVoCmSSOyiTaooseon8DW/j6QG30gShHpvMPkNZWIJOMTybZ mJjWipI6OBnRXyCQ+eI22Q0y7qgMvyrDMllS7N3wBOcncwwrDZxB/UmSaGA9Y+eAaaN8L0qNTVz5 EBuoIhgYY1a2042Ps0WKRIUq+T0R19CAt35lW3x+U0yn1Cp4jldqi6auiq94eHVZxap75y29ZU7W Q/xFG8bNrEzhOC4SaN44NdvmtikNLrPeYtRpXU5L5abBTWsPXVpXu+aOLstlu7NbFhSTnjM0fJK7 Qr4Res75A3aBNECx4Xkkr+Vh3sojuTOPZEwe8qWPnIzQ4PCrcTOZ0wtpThQ1uMMnchr9LUKjGPHn kXFx9Fj+57SN5R87YybUJs0JjY34g9KsaD6bCeWukMlVCqXNm+4JFfgNL6m0arnZ+JIKXJPTb1Ft FQTiarYGG5dNCFan6lS83GhxGORqrdqZ31Y2V2lyW1L93/xFpSU+Savibf5Ui9uk7Jl15dR0vVFn 8ZB1tcLEzfzV/M9QJZqIZqNX4zZzVgNpZQ0qKHKDX7Dglob8KogqiAqqpPYF8oOnyakq5SSgcb3R jFsmeWTGHD5fqSTWI4j6OhrXA8nKV3o8yvwsGdFxvIAouYv8iS6/ALd1ZYTiWpAhY46SL5nwG13H xzbbnBL+zxWNGf7qd0omzHjHP0laWqiik81vUdcfzT9OlOuAKJ3E6SbIFI5H4TfKPojWQcd2O+0K wjA6hQ7SIY2qmM0VQ/daUCR+0pYNAy9cEB7pTskSXDgSMfBSir/aYrw0mJTXs21i8TyP2TG+6C81 K9uzCy54aNWyPXMzhUCuPzeWF/KlFsy8tCW9wYcFkymRWNCT0xBzLJiR2xhzdMxu+7M/3anesb55 QaWHXxv0pU6LTdzYkZlsN2d7g9mchguM6y6vXNmZG4p3FwQqS/JdrpbMcXPCoZ7q1k1TstSqQOLz mYv8JU1p3Qt9xY1Ds8qqOJUrKz3NNr4mOaeS2PceiP7vhZ45D120v6oAZ4wubkiGPWbVQ1oFgW7Z 4aVT2OJktjiPLboNLTmnobPX3gwXDHYVB7MmpNa7WkT3KQ5ycUyavKWdcenpU7hib6I8ywwpDR1t /L0qM+1zndlNOZVbaiEpTpOxrrjhhqbpm1sCLmbPnLF1Vm1qV+fQNSxnbP/b3DRu4dW9xFNePnwS t8ljyIYC6NqDVcFJwRVB3i7FcqdF/xZRfnDGKIGOCo5wq1ASsp1r8lRSqQ3U9LTGR1adydcf9ruE JlE/b52ISt5Q6lnOPr9tId0uMUawQlx5pgIsmeVlUYIRFfA7lLTASpxTlpFeCoASD7+ZuBnPhxKn ohx0xb5JeWQfgBgsgPw7ee8Qc+xkgwApQIh8EzSqQ9J1Y2bqablGpuzB98U1LhfKyyZlzIYy7kvz NVmhJ+2Xi60USmrKz2fxLC0tlFV+2uDZfvqI6LRit3nj8xv8WU61DPNKtVIRdARiXgNzekQHGdHy 8gzj/M1ToiqN3mTWk/U+uTWrsYnf+2110HawBdpBAbolrqsqwum5ODduxq0QHr0qFi5X6v5ySel1 ohS7v9wjXATGzjpJB+deCYKm4bZnZSGiEtpE7ClaeVpTUr2JNQ9x4gyCLYjuxT4h7wNmBSNm8J2W D7aoLCluT9BpVCR2nGkfeIrK7EpxulJsar0xcRgv12vFaR5eqVfjvyf0324m37yO12v0ah46VbXO KSQOJ0Imm+Q7cCXozIbi4qrOCnFV5+yrOKM2gr/arxHqxRJLBnD2VZxvWbbr268mvYX8VYhxJqNP 4h4zWbsRV97D4mg2Ig5lV7bj+m+v3tLZpzGrvJ+M+Dev105mt715dK1AXDUQFwxEN6cB+z44mcwX TK789mI4fey3Fs2P4K/AyQpYMdA8AYJvRVw/fkJlfVZJU1aLa0z9j50sL5XmAE2lbL2LeEtxG/y/ c5nn8qE2afgtGYv8VepKLSprZm126Zo60nocAYvSnlmTXbp2xLMqzEkOe7KgbLm+qaS7NkfIamtu SJ22vsk36mODpWf42G/n8DsgMOF5tVa1oXOSOzY+Lbc2wwLOt4X1QVCDeWh33EhrkHxI3dGZtXSO tXgyWPRqBYH1SuJi65h1VvzVQaljIt1SXJM1IcOV2sRUT6KGkZ6JzdxL2v4O3ZPtP+ueRpT4g9b/ pHs6TVGgoDmkdyKjwfdBQ2TV5pF4UlU6TjPjdBMO63FYh8MqHFbiDHE25CwrNR+cdaWGBOvemAZr xiwB+U9fAjrMaci86kEjal0J1eQi3/8yTgjCyFEaXpMRoqSy2MjCTg/7+c9WePj3y9Y8sXrFg8uL Stc8vgZk8ZOeyqWTmpbUBjxVSyc1Lq314z8uP3RFc/Ul+1eDnAByS9Nlc0sLZl/WOuGy3tKCWZeR uYXEbv5N0A2ZW9hG5hYCRWdZq6XeZ3TRlgQxNjqtIE4wiLPLdIbhrPMKTcKkc84rnG1a4Sw2cu5p hZtmpdWOj6eOMRarzWNWpre0tmXN3UmmFfLFaYX6SO2mmsruYjf+8/pntjcIKQXBRCXzhbI/g83w PFjPRRmV6baWHU+tq7t0foUlvSY3cXtHV8X8LeL4GbR1p6StK+IeUJdPGyUNJqrRsSkW0clFydg5 A+VTsxmz1+0Taa8b2wPH9rrB2NkWatKOi/pkQjYZO7snlJCxs9BK+vyzj51P01mhic4UMntxFJ57 7KwmzcxnVaZPaGyKEBXlzbtxdlp9XUMG2S5pTTIpvzV+TuxnmsLH00uDRjaGNoXK05cx1SX+RQfR dEIGBtGid+IeFmcG5+1fWYjDRsmoRrfBSMZllKzOSIzLPGZSmVgZcoPNheLq6ISw0eZvshGvI7p7 scOPjsTCYweAZ3M0ohEpuIc5hVqlciSn2lw5hWXBM91MaHxZabI+kJqsk/GYn2v3mtRqtcqa3VI8 1PdtR7O9qDZi5FUajdog7oZqGz7BvQwlbkIvx3Wx5qrmSc1bm59qlo9ZuPlCWrARjWI8mZ6ynLGg Iy7k4HfjPrp6I67bEBOTFm/IEJn4HM9h/IW4BK8hYZEuLoZKkAzD86p0T+k4XfZ7xZq/mCab5phW mni6SPNbskIzwf4xbYwjyzPS4kwPmW4fszgzGkt/38UZ7uX8WZdNzJlWl2PXyMjiS7RqaklGbZ4n Ep/c2RaPpLdvbk9tLEu3KXmIjjQKdUpRUywjnm5Li7d3dsQj2FB3IdS3w2VN9Vkg/vT4PeZgUShc kOZLiVZOrSjsbcrUmW2CzmgXTC5BaXfZLcGcpEhhmj8lo2IKqYvA8N+4ZbInUBmauT8dmYJZks6z pLrIkuoiS2qQWZJVZhEj1Dn0WSeCjcn6E47GXBJ9K6nbPk7MLl+avTp+jE7tyc4+wXD6NISdTcdw y1SCPz3bUT8/nnyJ0UxWaC5mgdpHZO7YbPyouMGRmmRVydVy2YzkFMGgVoSa10zkDHSG4S2ljkzQ 64CIcxAJTc9stUYtNzhJuXeTeT7+GYgJbor7IBLQRogFRYgFRcjCbER0UhFBDLnw10/TluaTtOKT tALyK7FtErJP3PYrNVafZKM+MlZRW7KaIlq5qwkCM/noZN/YTTwjJnXWyb4zFnKKiken/e5UmpNt jmSTovVWsetXWukYxRFrzKncXKe0+qDlmtUjEcGGzokVi66ey6Ww1jn0z0mza0Jdndw6lkP0kwIx 02bQTyb6/SEUHIbejAS6PnEtJ+TDXkq82C6V0yZJ62j4K0rzyPr08GfxYrK4DVGFCUcEnCbHKWmQ MS4Fp6bgAKFVAZwawH4x149T/ThixOsDOEAmudQmW2PAD60WUh/H1WCKATLDSFKkJgLk+TqysSqt KaB1N2mpAxSXyKJkt3iPGDlE6S8m8QPVO1lNior790e21IzpIiyOYou0cX8z5ngucVymd6d5vWku gyzxskyOVRafIzloUcsSMv4Up7EEPA6vScnfI1NrdMpvHiX7x2Uqg4afpjOreRgTcvChHnLrdNyf 1DoVz6m0RNuFMMbYAdquQ+8fQg3gnsZB0UrI5Fd6CS4mMpSNwwEc9uOwD4e9OJyMI0k4TYbTeVxW jsvLcHkWriD/YrsNtwrS9AGRcQ2Yq+CHJwhGKZvIuI50JCTbOL5JvI4os0qYJKwQtgoyIW62Nwr5 TaGmshsycSY5l0m8pmCxNy7K3JDJ1UGuo0VNlPwm0WTPsaqq46BJqu8Y9YdIjNJG4jWqaMWInvmI csza3VlUPobKd8jkiS95vSPN68tw6fgfcdxTvN6d7vVFIJX4Wi6D0YUjKcWs4t/huBc5tRnM3mdW cW9z+C1ObQm4ncmkWpRW42ilcLvU6qE1o1VktCrVWqghGKkOudVqqCE9OF6yxc3JUpxKQ+orHVpH M9RXDF1xCOWCYkxkfp/4jWziMcqzsRPs8WmynufEDsk32FmWHauJtWaQcSu5pwLhkiAu0mKtnwwv SK1otbk56U1BrSm5yTQyhCitMpkxnb5GRLHEeKn9RkN2K/sqxOg3IUZXRC0WtgyK+RqVJeLzBm1a 2a/flmltKUnJIRNWY2fiSxW2RPzJQatGdvxVmcbk8ySHzJw68XWmwaKTw+hciRck7gDBy3UWAz6I HzZY9DJeoVEm+vEkBdkjprUaE7OI94AocAvoJxW1H0IeKGshafkenO7BTnHw7MRhQ5GBi6ixm3TJ ZW7sKiGKc2Ffk0tjadI0yyahZmnQSlZ/o7TRksYb4GlRiy1kt2O4YGTV1yLO6titSi5/oyI3z+03 cYotaoFPPKcSUr3eFKtajjH/lcKU4k9KNSkSBwSTXGc14FKZWcPPtDkNcl5l1A9lc29ZtHLoJ8xQ km4Iat/mD6IoKj+EBCiJnezVCYs7dmJwvkBdq+bUIRMMWva5Go0RcfACL04m3/MgVjjeQ3Znjmxc FGd68Wlbj8WtNZhQ7m2FyqAaesvmIfaIdyW2Chays5GTaU06JclLrMMPqfRqRb3FY1ImBVIMdrtL 4JYGQmZIKwx2k9/gdLiFoVuVAkRaHNYMf4Hflc9CNpSODAfkIU+rUA9Kfe/lMfvj+PDIBNgZX036 kZJ8NSjJrDRhlS2Y5AnaVAa1K83nS4f24Ez3+dJcaryORb38YZ1ZJ1foTLpTpYGoR6v1RAOBLJdW 68oCPWUk3sdr0AfIgzQDWkcSEt44TrcdKZXUBxRbRv7uGoXBYbparre4LCaHBssu1zpT3a5Uh/Z6 X0F2lutlpUYlNkts2ebxCwqF4CcjjyPDX+Jd/C3iGNbTj6yD3OaDGm8QRuDGRlR1vOo4CUnyvr0x 0HRmsXeRMvrTSBnT/KSMZ6Z5vz+TlC/Tn5JFZNZQWoBmQIHBtbuziI/4AbzPciixFjn6yUaXo0+T DS1qHhozvEr0eVL8MTOOy2OVFdkEyxpi2XUAUqar+A18tnwjaK0Y6fcrUux5Dagq/zgpxWlrB9KX y5RnyRXbw0NaR9DpTLFrFXqHcKVcZ3aZBbsGyxOOs5wAzyBruMTtNysUZr/bmw8qP67SKMm3o1SJ E+c4Qd42ym/gXht5W23EkT/ytiMVHQ4XjNa0/Kz1z71GXuYqmd7sJC/D79A4gi5H0K5N3D7mBLy+ TDxD3l4e8cHbOI+rtPA20MFi01Zo/QqFye8+1wmoIZz4iNfIn4XWoeoX5CgWy81xSC8jzXgqH5Hp rck2V8AsU3A9Mr3Fa4MAVCb/XG9UyZR6i16xWW9UQ/mtenheHd7PZXPjkBEZ9iOl9oQMkc2a0vpP gNa02M6zzabELDP84PuhNcvx1xGvLxz2KkxueMrliYfxP+TXoCBKidt40p3wZCDDiy6Ht/m0l6Oq GNgy3Q6mgMjZ7Bj5Ilw2L9Y8fXv8t9k9s2fIsSHZZXZbdHxRe0mSr7Q9H6uFJLsjSeDkc19KdL/1 dmL6L3QmrZxTqOQLX/v1e6tWvfvO64tkCgW4doFY8iZ4o4/gjQIo/xAy0zjPLI0TiDxA3swsboXT iiNR+obRvJEda0rWJxWZCwu4iORxHHYz/iippK2I11ncZneyHstnzpo1S8YJSQ5bkknFLVrHuVa9 9+vXFspVCk4OTvDn+OG338IPv6QWNPB2CtnxxCTEw/BOr9goz0Yrxf+haum+VdudoUG8LJ6brXNm laDNzk5nJ6qft/ZDX5ov95JPTdM/nTy5Wanbnr0qVW7ywTFr3KcX7mhr/tssqLCqN06IozqzozTP VBo7IX7vkAz7nj9Gsp8XXnsLBoMfmsi2SSyNaiKi1cjYJhhHMe2SlLyCjGdk0kaZ03Yx0OXmVDHu UYhtQZyDkEmre8VYsdEUrpy+oTW9viikTGturAtEq/NTnRqDv6RjdYu/vCjPbZIlhc0ug5zrFnJq 0qvzUuya2Ornblg/eO38ugy7Mv+SN+5rWj+tCMaNcg7LlLrS3ssmHkkM/bBR6yvp3vrE73Y98Lc7 W4aeCU/OhzFn0K4urHLmlVSFT33D49rrrtgwPd+SWhpKK00VTIGcisaM6Ir1q7qLjf6cQJfBIFNC t18wrSO9vmfRhXnT7trQUNC9dvvVW1dGVgxeMcFkMSmNDpPBbNRprFZD1wN/uq7gyj333HblgrJJ N7xyNF6bPr59aptvwmRTsDTCt0MdPjV8Qp4A30G892wUi7uaZjTNmDj1nVwfGOB+V+/Ed8oFDdbs D86BrmNo1Vsn6Kc4LgdPSgfaI9N/2MrRHUuQa6aVgc/5Db/Td5fMuuPlLYVlO36156qfXzG+8vLX +YLuJxMPPpp4tHPa3uFHnko80pZYzskVlpz45Kzuq2bGShfsnBxpGJfnUMo5GMOrTMH8puIL1njL p5bkTyhMNcDolO/teeB323a+vXti621/uO36d25s4i54NvGXA9Om7sVo72FsfXrGjCeHE2lGu0ln 9ntMJSvuW7rusWWFRqffrhPser3dpE4OJt9/R9v6SWFf2KcQ3KCxdhjBHhb3YRejBnzZIVREhp4m srEJCGmShYNSTiHLKWA5BSxHnHgzjU7ANYkbWrnWOU04h12Twwa1Y3PExamcQc4Vd1nTRN+UJg6Z Je6n27+dcbfXGPR6nWT6V/zwWr2aEvGaEjKssyXDQEe8UcokN5Yc5mqgVb+xD15E3JNkPH3HrbRX 6ai0EnRU3DJRTWJqDXlGdQ48tJq9dDV76WrppasHuZq4SUPiTk3hOHnWkKu7bkg+W1rdLx358s8b dIB42jZcEMKYOVkSmI78s0FjA4ti6ohHd5/zfMGIrTmKisjXadlafhF/uGLVQxfMv3t5WVrz8rqK mfFA7rw9C+de35NJNjI1rGiO/Dq5pKPwwhWe0mkVCy7MSKlbVFs1e5zv8h3btuOWKdunZ2e0b2wd t3Bqc4qvrm1mUe2GrvxY2/Kq/FlTmvzBCZ2zudkZtTmuuZ2RmopSX8ElQ/dnN48fF/BVVjdl9i69 AHruRrClF8VvbUTRJ3HXGZP/ITb5n0XGgCFiHVl4zLQ+WcuykpkTK6k8K/las/UIR/6PDz+dNPJL xuWXZnf90vQJyI9JVAQjffI/GMTVGvKFkDjixW+Uq8keKs0kDYfE8b/49RpqEGQ2D4gGabIyPeQf nTN2kG9LsC+DkFGSWFtkcCR82DN2zUWssn+zgiAbMxEs41+MLeu7dNPDC6M5F/Zt2wyyz+CJVrTm dC4dZ/eOX9BY0jkO4kJu5y1f9PdOe/TLe3d/KcrHe29f31nsmnztMxfe+IttZak1s1ZfDm7sSYT4 e+QOlI3+GE9N9eLUZJyahIMenOrGqS5MBkUOnC7q3kxGgjni3hWi7hyMiGpRujQLly4pNF2aj0qX FJouDTXTyddLDF4nucmpJZ9ak9SOQIrtyiS1ozH5R6UvFIDq4Y57TdhkMQ/iqn3B9nRhECvp97Hy qoaOi3Og5Oc42VbEdl/TxjA63u+RRj1s+zWMUBR0nF8cktYITaLLvUeh0SuHZip1WoVCrVdhw0my g4hXaNU4Q6aDYM8JIecnMPaQ15JZTqXgtpjdJjX/61s0Mr3XYXIKOsVzvEwGfZxWcep6NYRRoO3V oO07waYr0e64Pr0IR704PZnMncSJWh1ErXFsJ1ZsFz2P3S+O0bmsp/NDcKBSSdelh7mtSEuVoyUz JVqy8mcqKfX7S8H4sp/OtyuyO4TSQZzGNERnjGPUmYADOT7yJWRRR+KcyGnKIdMcZ2ynVYz4DqW4 cf1OudqoHio02IxKXmPUnZq2pNScVDi5QNxMC4NyGSdXOcu7Lyiftasn295wxYrjXL7KqJVPILvy lYLXbvU6HHqsmXnTxrnRaGtZSkpaisrstRntgsGWGnQWztxUV7n5+qdWv6U2i7P0i8An3AT668Ly Q2g6qCyJqGw6zlWBUnJJw88V9ZZL9JY7yBXGNRM7whMnOi24NU7m6MJwSZhMHcUhNxznDR6VwGbl xTs9fnEjGzVZD2j+gDgdIu4+Je3bIJmmQbJ2A6k4C1SDoZxsciiPi4PwciyarmTCtAcoN5Wb7EWD WBvXNHVk/sPvlzeRL1xoR75wETtRKox85wJcd4z6e8nXi5u5yMK4uXTUz0vOQiGO10bm9rng6Ibo MUHItyrRBj3ATZVrH7tg/KquMqNKwRv06sKOFbXV82tToh0XtW6GulIqtAb1quolTRF3QVthWW9L nobMtkBcbinrXBGfftWMLH/l9PKaFZOz8Oru6xcW25J9BgOMT1KT/CF/SmVnXnFXPAWah83iMipT 4t3FaU1FvmBaUG702Ek4ZoF6zp6yrmHckrZSLacsnEx8f87wSf5XcivKAL90Kl5GJhqzcCQTp0Zw ahiHknDYg4Oigwo5cciBw3YctuGwFYcFDFWcKsepMhz1YNFbmam3yrI7gdj9grSXie5h+uAg2eOU lJ0tDA5/E0+GKwTS/ARiEQKZfhdIJyKQIY9A/qWCCJJRXyWDDoBtCY1ryJ5QWU4s4skWK1gWDQiC JtCu6RRnfKHV5Z/Iy5NmyqLSKgT5IuVxUY62wDN+8OkbIUeaJh71VXYcxAH+V1bzTezbk0Of6AQ9 jJw0Svy63OLN9AZyvcJNJlviPi4xAz+MVwbCic/Y1DsWFILXafG6HHreTGZM5DD6++anQe7PQ2Wk xS2AFner3AAe6/m4PlKMI0Xi0jsveqynqcMqlrxSsfiPr5CvjZGvxqSB6tPIl/BIu0gzTMpbkbc1 j887+9cLD3P5EFx9LAVXRw+I+4Usg2QhnuzHsziLyLfAdZll//ST7wzIM9ucpzWdnhOk6cSiWHhL ajHHet6gjYcql2h3tLWcthRGQqDgaf/8AoyMpc13/K312/ovrLhwSpFRIed4GLJrMhqWNNasbMuO tG2ZOq4rnOT0JXPjVEaN3GpOJAebclY8tKIU37v4/hVlJpfToDO5zSaPSeVKdvtrF02onF3l07lD nDHgV4MTTE1L3CLnCnt3Dg+z2JlT8L+U/rOx++iBY+c8/sjNHXO8Qg+++SzHftmMkeMUOeT15zxe kL+gsIw5jo49lCXnOPqV/aoW1Zf0UL80emhypOPI2Q9ty/njnMepcx263Xr/WY6D9DB0neX47f/Z w/izbx9Ci3i8cPbD1CIefyKHOX30sGgsd4w9rOnnOI5aj9q6ba/Tw37btw+H9X/peOBsh3OGK3/k +Ik7beS48vxx/vh/9PjlWY8h95CnzrNozPFskv2cR+WYo/ccx2NJJ//XjuR3yeFd9//f4bvjf+/w TwzIAw+m7AnOSrWIh+f8cf44f5w/zh/nj/PH+eP8cf44f5w/zh/nj/PH+eP8cf44f5w/zh/nj+93 iOvIHMKitJJ9yfBzP1Kg6xBZ3a9G0zCHL8Yr4IwTe1ElPoBvxz34Bp78/1ACXodi/Fb+n3g6SkKz 8LX4RbQWX4iv5u/mP+X/yp/gu5AMT8ZHsRuZsRGn4fWoFv+S7+Rn8bPRYhRG01GE/4xfjX+Kn8dL +GmoGV+DKvi/8Rfyn6NMZELd/B38BCRDD8DbyOCA9/ysengYPjH5hLQMPv87vCMS38YMuuSAKZAK oSlTcgtr1ubkiGcQvoH8Tz/f8Ud1evIz9NnwaRm0vpDMMAr8Csj7UPB7Yzp6XFaLes+Kv8K5MeA/ /o54Aj0u16EZZ0L2DTxHAif7/pClUfA9Z4fi7XND3oLmfR/IUuBvAeRzgXcBHwMoX8NZ8SdkHAt5 Cnrs+0DpRePO4zy+L/g30czvC1kB2sPPRdO/C+DaOWPBn0I93wXcKhT67wz+GCr8LiC6YsBvocu/ Fz4ZfouB/yHoXAKcOysU80f/1llRAvXxfTB67xzu52jPWPAB1PZdwD2JAv+3AO+5+7uCvwulyAdR 4ZngN6B0/h6U8i2kQ299HudxHudxHv/PgLsDa74r8DDKIOBS0RFOjn5wNvDd6CpA9HvDgfDZwK1B dd8Ly9DlgE3/N6GMIMSgeAI99T8RME5u/988GtGTaDVahHLQAvFol+ZMzv1Dxuryuwf7+546PNtY 8S/kooP7I3/ZIu7jfyHltk2nTg5do/6r8mlIqsX5A/j5/wCexkJ1CmVuZHN0cmVhbQplbmRvYmoK OTYgMCBvYmoKMTgzOTIKZW5kb2JqCjk3IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggOTggMCBSPj5zdHJlYW0KeJxVUn1MU1cUv4/C4ynIBvUJAtIXjQ4s AkVAqymMMCuSVrDVEhgMK61QfUClFQaTZYtzH1w/tkRlHxgYxGl0m8AUJohDcSJuA6f48UCJa62b CHNhJueRyx97jC3L/jm599xzfud3fvdHIW8vRFHU3HQrX2F12grNMzelGEaJ4V7iIhl2ivVTOT6L kK7+8TzsL8P+3k3h3h1B8FkgvPMCVL6IZBT1+oFP08rsVeW2omInF7nFkB2lVEb/l1Gp1WpuW9W/ L9wrVoetqJRbJh0qrHyZvcRa6lzLpUnVPG8r5Ir4KnuxgzNbLFbLTJvJzFt3clobb7Pbyyq4yLQo Lj4uTrVCCvEbbSXbdjs4o7nUwek4g7VoN28u/18SIeQXp4o/sjIhMWnVajVCgSgIyZETzUcsWoCC UQhaiEKRv6QC8kY5qAY9RFNUNfW11xyvaq8vZEtlh+FUgNjjHBIFgWr3QItHBiemctgNOLN0e26+ 3hmNSTBD9o4QOUTD8gcghxqI2P1r3g8R27uzTqRjRuM91qkkBpKfvyIqJm8CTGDqHBtTSKC4cSqu gYI6twzqxAPs9AH3VM4mX55QlXtIeDWj852pcYnn7lGi2iMTD7rY6Tn04e9Pt7guPrsU8vuli0PY ha86Lptbza3Zx9KxCqfvtGSWW98q+CCNcdMHuz46WdfU1H7+eA9mRvoMKcYdr+qKFLHZJHLV1vS9 JG6hyNMBMAlp4g5WazRqtb3GG4NXegdubu5dN8PPKUDTHdhzL6jTDR97tJ5guQi7QGCP0i37feTP x7sLkuI3m2KVeV2T+xQr6UOGI9vrd55Z/3PxOGZg2RMXhHqKu5NOKuTiT8e/7L4ZCgFrhkgYWZKi Icr3I9z0/vZDzUc/b2jraL6MGaEz/+WcqhLLGwrH2/x7+lrmb4EgaljUSRqNSBqNQDJLkt2Q/Hx4 sbg1w5fcmTb4xPjCd8MsKaehHK77zJJ2CRDrosS1kmZ26aumvWjT9AKf+/TZC1/VS5PG+jIWL83S K5Pz2kYqJN51m46UNe76ZsstfkTiveTZn7AcuJinJDyn8M2SbYoTkOsDXfQs9DVhtPEXgep4BO0S +rtiI1sNTMoNgrAGr7OadQXaygRMWEz8jqWc07Ua+nlBwgwbfwYKCFH9RuTrNtuzrYr9kNr79A/c j9stn6xnSCBJZB/2ZEXHZ2asUesHH7v7rrlmDSJOSIvUzyxRmiDKaaIh+7Qk0kRqmCd0G1Q+gmxI ABszS+70bXAIQS2eDA/USiFYPimGiXNY+fhQR/OZgVCQJQgkiASu1BDZhuaiW69FyCfXWAqzNKFk wYQKOOAmPMAOF15Vt0UQBo5KjXe6CrQbcgtSU3M7BgYvdNxWkG5v+aS7z7h6VaZRlZh5ZXS0r9f9 j1cMAvTfo1o9M9L0QBJbT5i7WkBYwDdbz17/9kaDCwOLwa/qrvm65Yr+lAYzJGz5S0RBQjwxMH/g QvPl84pakmpULsN6vLWtZpCB+ZI1H/Svj03YqE9MMl0d8/T9eF8R4GwSGxtA36BrooW5o37Ch/7+ Dw/7z0PoL6xGRu8KZW5kc3RyZWFtCmVuZG9iago5OCAwIG9iagoxMTc1CmVuZG9iago5OSAwIG9i ago8PC9MZW5ndGgxIDM2MTY4L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTAwIDAgUj4+c3Ry ZWFtCnic7b0HYBzF9fg/u3u99zvd6XqVTtKp93LqkiXZlqWzJVfJBRdsY9ywDQbTgjEYAwYCJAGS EJpJfJaxkTEJhhgSCA6QGAgklCSELjAJpBh0+r3Zd6eGSQzf7/f/K39p9O6zMzu7O/PmzcybubVF GEKIkuwgHJk5oyuST/ifi56Hj9lL1vSvw/iFg/Bxesnmja7YCzN64PgPhIgePGfd8jXff7/uQULE OwmR6pev3noO5g/+k5DCD1cs61/61u8S5YTs1kBi8QpIUP4j7RAhmu9C3LdizcYtmH97iBD1U6vP W9KP8flvEeL4zZr+LevsEm4x5D8Gia61/WuWJcv3EHxY1523YSPGrz1Fz69bv2zdExdtg/Jp3iTE bIZy3UFIYi8Z+1lHLiXfJfvIIfIIeZw8Q35L/sbISB+5kjxG/kzeJ38lnzOEETNGJp3JIP9tP4nL hWuIkjtGRARKNXJ65L3E/SPvESJUjUvZCzGzIDCWMqIbGZqcltibGEz8WiQnGv5aDfsrSD3FDI2c ZmtofKSYxtmr6DF/xSnxHYn9iTsnFGcR1HgtOQ+0cT5ZTJZDbD3ZQraRC8l2cjG5BKzhctDIt8hV 5Gr4vJbsJteRPeQGciPZS24iN5NbyLfJreQ2cjv5Dmjze+QOSL8F4nfwZwl/5i7yA3IPuY88QB4k PyY/Id+H+A/J3eRH5F5IvR/S90H8Xj7HvmSeOyDlHki7P3nVfhInB5Ln8HiAHCQPQevtnxR/mAyS I+Rwko+Qo+RR8lPyM2jVY9DOTyQ/8cz49K++4lnyc3KcPEmeIr8gvyRPg638CtJOkF+T576Ufqa0 VN6vvsvz5AXyG7DAk+RF8hL5HXmFvEp+T14nb5A/gS2+RT7kc+DZP5DX4MybkPon8u6kK18evRZz vQH5/pi8x9vkHcj/HhkiH427BvP/AXK9S/5O/gE2L2GsjJ1RMXryGfknxJWMCc6cZqRw5GaCTDaT w0SYQqaIqWBqmTpmFsRyySpyLrke7OImaH20h9vBHi4AO7oa0qi1YIvfA73u/tFW3g/tRlvtO6Bz Gh7jNf/EGTR1Amp6H1x1gG/jL7fVE8krfgnnnwG7G5+LtuTPJ9yNavwBvgTUbh6BHMeSVz892hov wl1OTtDmn8hf4AzVGz3/O/7Mr3gtv8Fr+S04/zbfCjQX6vdlaN+XRu9wHMr7R7j2N9Auv+Fz0VZ7 BYTmeRpyPQjnX0+23LvkA2gt2mbvQ+wdOH6UH5n+AiWmbfnn5Lln4cwpGK8+hZb9mHwCR3+DYxoe h5S/gnwEqR/DE/4GQvN8AOU6BSX6ENr4r9Dq/4Az/4Ljv5MvIHwKJTpNPocjeuZVOPN3Pv45GSEJ MgKjIsOwDAfp9Jjw13wB9R+G0iQgZ4JhyDDDMQJGBOOnBCxHxsgZBdgPvZJPwbuAVbGQi56T8Cl8 fvLP0fxqRsNoGR2jZwwwDpvgripI0zGW5Blp6gxjhjTVuPxGQvi0NMYKRw7GxbjJr2Ekd5C/g32n g4W7GA+cZRk7tPOLjBcsO8RkMLlMAVMEV/gYPzyNWno1U8N4IcXPBJggMAz1A4tnKuFMLdPANMLZ ESaLKYb+UM00nWnMZ2+DHsD/wPj9O6GKEcL4/wQ7nWyB+Mtgg3eRmaSHLCSrhO+yz0abFi1cMH/e 3N6eWHfXrM6ZM6Z3tLdNa21pbmpsqK+rjdZUV1VWlJeVlhQXRXKys0IBv8/rcVoMWo1aKZdJJWKR UMCxDMlq9Db1ueKBvrgg4G1pyaZxbz8k9I9L6Iu7IKlpYp64q4/P5pqYMwo5z5mUM4o5o6M5GY2r klRmZ7kava74iQava5CZ29kDx7sbvL2u+BB/3MEfCwJ8RAkRtxuucDVaVjS44kyfqzHetHnFrsa+ BrjfAbms3lu/TJadRQ7I5HAoh6N4yLvuABOqZvgDNtRYfoAlEiV9bJzzN/Yvjc/s7GlssLndvXwa qefvFRfVx8X8vVwraZnJNa4DWcd2XTuoIYv7woql3qX983viXD9ctItr3LXrqrg2HM/wNsQztr1l gSovi2d5GxrjYS/crG3W6AOYuNCv8bp2fUag8N6hDyem9CdTRH7NZ4Qe0iqOqgnOp44JlA1KCPVz u2lZrhmMksUQie/o7MG4iyy2DZBoJNwbZ/vomWOpM8YYPbMjdWb08j6vmzZVY1/yd/MKS3zHYld2 Fmif//XDL5x3xblA3+IlKyj7l+3yNjSg3rp74tEGOIj2J+vaeCA3Avn7+6ASK6kaOnviEe+6uMFb hxkgwUXbYGVXD39J8rK4oT5O+pYkr4pHGhtouVyNu/oasID0Xt7OniOkYOTNA4Uu28ECUkh6aTni pnpolEDjrp6l58SdfbalYJ/nuHps7ni0F9TX6+1Z1ktbyauJZ7wJj3PzT+SvgrpNyp3KTGsu9ktc PayN66WtBQmuJvjw1lXCCQ00Fx+lLVpX6ephbCSVDZ6SzEGPJtwHIpy/voWe4uil9S02d68bf/5N kWzJMgn9ccm4e2kgYbRM+JyvLBrmpgXKcDUuaxhXwAk3FSYLmLzbmcvJUl0kHwxXSGhztqROcX7o uZDGwm34JNqKFleczHT1eJd5e71gQ9GZPbRuVNd8+7Z1eds65/bwrZ20ku4JMTxfirE4ccPpVISt BxtsCttSzcrHm/n4aLRl0unW1GnXLom3rWsXvbk3eUPigh4ElRYFWvuvKdUVQtdsgtHN29TvdWlc Tbv6B0d2LN51IBrdta6xb0U5vYe3dekub1dPpY0v66ye7bZt9FE60sa0dddlZ8HYU3fAy+zsPBBl dnbN7TkC/rZrZ3fPAMuw9X11vQd8cK7niIuQKJ/K0lSaSCMuGqF3mgURCZ/fdiRKyA7+rIBP4ONL BhnCp0lSaQxZMshimiaVxkKaANOifBr9gUayrAAVw3Db6FpKm+ei3hW7+npp5yImaEr4ZeKMt5rE WW/1AYYVKeIy77K6uNxbR9NraHoNpotouhgMA2ZdUA4dk3b1eWGcAoPqITYGTZGjt3QNjox097hP 2IZ63WBq80Hm9sSlYRj7hf5pkK+ZSh8kN8d3LOmn5SCxHnqt2N+6pBfMNnVDyNIal8IdpMk7QI4m /hpqjnDREmgbaED++h0Qie/ojfeG6UN7Vvby5qyJkxZvOTQ73lMYoA+K9O7SefP5vgldQea/ikIK ZSNdPZhigyg8rBeVJFZAyZd44dSSPhdoW0CWdIGp41gqs2HKMhgSBYFlvMhsyZOEVovzy5WyuDQH bgi/9FieQ7uk0C/u7cXC87Grkhng2Zq4HEoUGKfK5AWgHTjVSssCv1dBUWnWx+ltOgfJLO8WGFlo ofk7ieF0XOlv7YfBH6+XQ4q3NHWxhI4R8uQ9jmOqmNZcAXrn/N2DI/d6t7rH/WRneenkQA2T2I6A YZPeXZMT4vPC2VmSyalKPnnXLonyzBegviTKUUIioW6mCJxL5rjsrtNb/vWszCEhzO3jfSxuiOZR r2BcsNr9IxFDR9CQCKxnidIwMgLNwhyQcoPsDwdshc5B9jsD1iLAdYj1A2klgPMR6xDzByxlgHmI uQjvgLkC4EG4ES6EE+FA2BHpiDSEDWFBmAdMTc5B5o+INxFvIF5HvIb4A+L3iFcRryB+h3gZ8RLi t4gXEScRv0G8gHge8WvECcSziF8hnkE8jfgl4heIpxDHET9HPIF4HPHIgJHiuQFjDHAEMYh4GHF4 wLgUcAjxEOIgYgDxJA+ucMCZDShA5CPyELmICN+2XA7GlAOOCEDOg/18wJ4LOI34J+IfiL8jPkN8 ivgb4q+IVwfSCwCvIH6HeBnxIuIk4reII1gWBZrbw4jfIF5AHEY8hBhEU/wB4vuIuxCHEHcgXkJ8 F3EnWuu1iN2Iq9HAvoWxKxHnoQlfg7gKsQaxGnEuYhVeHkP0InoQcxCzEbsQXYhOxPcQ0xE7ETMR MxAdiHYenBpj0xBtCBNvRKwRsRYxC2FA6BE6hBahQagRKoQSoUDIETJEN0KKRnsMre4xtDoH2pId kY6wIdIQFoQAzY1Dc3sHzeZtxF8QbyF+gRbyFOJJxHG0gp8jfox4ELEPbcmKDV6M6ilCLOFLzZmw EEaEAaFH6BBahAbBYHEJFncEMYz4AvEnLO4fEW8i3kC8jngN8QfE7xFPYI0eRxxDPIb4GeKniEcR RxGPIO7HSt+HuBdxD+JHiLsRf0aF3Iy4CXEDYg9iL5r+jYhtiK2ILYgLENcjNiM2ITYiNiAWY+9Y hFiIWIDoRxRiqxQg8hF5iFxEHyKCyEFkI8KITEQGIoDwI3yIECKIHYhFE85CE/474lPE3xB/RXyC OIX4GPERYgjxIeIDxPuI9xDvIt5BvI34C+IzxFuIPyP+hPaZjVaXhQgjMhEZiBAiiPAjvAgPwo1w ImRowlKEBCFGiNCEP0GLPIX4GPERYgjxIeJ9xHuIdxHPoUX+GvEB4nnECcSzaIrPIJ5G/BI7bABj A2iKccR+xE8QtyNuQ9yK+BXiAR6cEI3vFsTliB2ISxGXIC5GLENTPIhYiViB9nIOYiniAKIR0YKo Q9QioogaxBWIyxDfRlQiqhEViHJEGaIV0YxoQpQiShASNGExogohQggRAgSHSNo8g2hA1CMI4kK0 wRFEAhOXY2wY8QXic8RpxL8Q/0T8DGeEnyIeRRxFHBgwXAOI82C3YwNcxINxRH+hqXP+Q9Xi/DvI Z8ppzj+B/BHkTcV055Mgx0F+DvIEyOMgx0Aek892/gzkIZCDIAMgB0DiIPtBfgLyY5AHQfaBPABy P8h9IPeC3APyI5C7QX4I8n3ZCuddIHeC3AHyPZDvgnwH5HaQ20BuBfk2yC0gN0svcN4Acj3IHpDr QI5wXdzMqGy2czdErpUuc9ZKuVncTLKCOLlOJPODAX0+VPr7iLsGdFQFdyJuQFw/oI0C9iCuQ+xG XIu4BrELcTViJ+IqxHRExwAod5BpR7QhpiFaES2IZkQTohHRMKBuBNQj6hB2RDrChrAi0hCWAWjL QcaMMCGMCANCj9ANQEsPMtroHOCnIH8D+SvIJyCnQD4G+Qha/A2Q10FeA/kDyO9BXgV5BVrvdyA/ BXkU5BGQIyA/gFa6CRpikLkNlX0rYiUqZgViOeIcxDLEUsQSxGJEP6IPUYQoRDUVIPIReYhcRASR g8hG/WQhxAgRQkhxhJvBTR+ocBY+xk0nDSDdINzIMUjMyGo6wh/oTE2DzI8H9Aa46MEBvQ2wD/HA gN4LuB9xH+JerPg9iB8h7kb8EPFtxC2ImxE3oT3uRdyIWIRYiPVfgJiPmIeYi+hF9CDmIGYjYohu RBdiFqITMRMxAxFGZKIWMxAhRBARQPgRPoQX4UG4UdEuhBMhQHAIFsEgSPRysNIRkATIMMgXIJ+D nAaz/BfIP0E+BPkA5H2Q90DeBXkH5G0wz7+AvAXyZ5DnQH4NcgLkWZBfgTwD8jTIL0F+AfIUyCDI w2DCh0EOgQwy+7FFfoK4A/E9xHexRb6DuB3xLcSVA9ocwBWovcsRlyEuRexAXIK4GLEdcRHiQsQ2 xFbEFsQFiM2ITYiNiA2I9YjzEesQ5yHWItYgViNqEVFstBpENaIKUYmoQJQjyhCliBJswmKEBqFG qBBKhAIhxxFJhpAiJNEIcAha5GWQl0BeBDkJ8luQ34C8API8tNJeGGxu5Aecc1H5q6JroR5Xcn7n FVyO83Imx3lZy47Ypft2xC5p2R67eN/2mHx7xfa27Zx8uw1w4fZ923+/XXRRy7bYhfu2xQTbDNtY 2daWC2Jb9l0Qk1/AKDa3bIp1b3pr06ebOMOm7k1LN23cdNOmk5AgvnvTQ5uOb+IGR45FdZtKK5p2 bLp+E2uA8yzZxKhpsmuTXNW0sWV9bMO+9THBet/67vVc2an1DBtdz/StX7eehUwH1/tCTTSzbb3J 2uRaH10/cz13fst5sXX7zoutbVkT+3gNo6mVcTHiAnkehCNqrpvs4bqjIyxZvW41K10FtV2Zszy2 Yt/y2Dk5S2PL9i2NLclZHOvP6YstylkQW7hvQWx+ztzYvH1zY705PbE5kH92Tncstq871pXTGZu1 rzM2I2d6bDqkd+S0xdr3tcWm5bTEWve1xGa2MM05TbFGrtgJMylxwO86xw7HKYdA3mdfZ2fX2d+0 n7Jz69JPpbOX2Bi19RLrHiunhg8WP9KcaXvS7kzbnyZU8wecYp1uh45dp92hZXO1Ue3z2je1AqK9 S8uq96jvVO9XczPUi9Qfq0fUgv1qZr/qMdVzKm6GapHqPBWnVtE4p4mqcvKa1Mpom1MZUXKVEWWN coaS26Nkosqc/Kao0hdsqlHMUCxScHcqmKgikNH0sWxExkZlcCIqDWTDh9nWRDjGxTCE0QA4CW0L xuiEQZ4cNDFCBnyCA91d4XDboHhkVltcMnNenNkZ93fRz2jn3LhoZ5zE5s7rOcAw1/UeYNj67riB 7uXz8St37yZ19ra4vasnfpe9ty2+Aw6i9GAEDoj9gInU9YYXbti0IRwObwhv2AifGxdugJSNm+CX BwOfwE0b6ZmNGwjNeOYfehpvFN6waRFczadtoPfdFKYxKvQZ/4f//J9WQuZ/dwH+f/1jWbSQECEh iQ3cm0IVDHtiUkFiZDaZcSjblG2SVNbK2HLSSsRMnLDExRIiIQxzIKoTsP4SEddpU2rXdTKdDWK2 m9S89vprC15/7QTwBBN5beilIc3wS0O6srJIJC+X0bq1vBhUrFgsEnk9OWxJSXFxQUF+NVtUmMN6 PSqQQFFhNVtSzRXkO1g+K+bkUyEzTeXe/GIG1zTsYze7Gla0OLhsv8mpEzNpQq9VHqkL6ZT2iDdQ nmEVScQCkUwsCZbUeRqXN3gSvxJIVFJV2JXu1YsEUrVcmeG2evTiRECoOv1XoerzOYKGzx/ltMXL pheItirlrFAquddtc+RWOAx+u1apVqpU4nRnulisU8u8VZ3Dd0jTXXaZUiXVGBVyu9MhUykkatOw m7Ajx0ZOC84VGoiHBMjgI1wT10x6wnT8ivUc9Ct8SljAR5XmgFzmtZg9xOczy+gWAjH7Yf6P2qNe j4WDOxOzIKRWOBWsklModPZZupgwFgpbampqdGURsmjhgrC5TGcus3YMMZGToOi0iK5MV1YAGrdo hrRlZXm5tiPE/83umJfb6zfRFslhg5xbrOKgbQLFJQw2jVnsZdyCc4SMrbo4kGuVMd6E9Vtinacs nFOgVerZjTKDv6agojGgYN9kEm8wqxf7Mo1CTqJRMYKESi8TiMyZXsFFWqOc4+Qm/VPDr9JvePpG PhBsFXpJKVk5SWd2O9EMcpLD2QKrwGqUUletsMsI/tvBaGg2rQCUuIZWORJhIkPHy8DgbIf+c16o JGNACwPzExgNDpaaY0G+yWhQSZKGJ6AVFmzV23VKX/nc+mnb+loiZm9dX2XzsuaIXikViCQypSk6 f2Pdmv3b6gIdm79/YnvT9gV+wQ3pC8vcAXdF/8U7rypvWtXkdfgceq043ZvhtZu8DmP55oELFjx9 7MFL2+259MUiUkmIwAW9MJvsmlj/qEZqNElMJkkoaFValSQItao4HAoHjUa3hLqT4U4T4GDU3T1a QWhQMAawjOO0ppoT+QWa7VcdP87bhPRsr+YVpBJ43Zyb18mEI9qD9dAp3fkCFyeSqY2KRH6U2alS 0IhBkdg6jTmpULBiiCiHN2usWpHgT9JiN3uFVfCuyOEPuU2J4wad2O4PuAyJvUaD2OEPuA1So9Mk WJEVBH0UjZzmToM+guTiSfpQ8fqQmNwupZK4QBvnPez2uUxGow0qtOFQ1NdpQ7uGytCqpDQBeijI H6+Hs7juTDqg3WG09ibuNMdXMtHbxFynUgjEchrZ1Mdq3IWBYF66jHuf1nuhVip4S+QMZHhNibtN OrHTnwEqsMs1MpFIppELbskKmqDWC0beF7qEPtJEHplY64cyw1nEBkPHoSzichH9IPvu4bKwRSy2 KI4yG0iUBJmyqDrdlpVOmPR0hnCF0S4LLGcORgtH7R46dyQSAePXDNEhAgYM7C+ak0Pbr1Lxajn0 X75lSmMTulVxiR6HdwFVmZgTicSoxWQXEwhdoEWVVqounn1RLHbdpt4qR1bX5ta8vozKTxUqAWhY J2cOudMlKwQKmXzmhuumXXNyz7TIgqsPvX5F62XLm8wSwRUyl9/v0HsyPXmxDVdc19ixcXrIYGDC eqPM5fWl67JCw6f1NrnC7TJFLxncsvr5o3durDW7A0Yr6L1w5DRbBGO2kTROsja1kchlRjmRCYSa WckBE2rNRJ4qyAeFReVfPkeHz5SR4JApZmrG7OEzmAoLAoE8u5T1yjQyoRA+BL9MHSXHAs4ApUkn syeVRmlJUxGl0qLiJPpZabAyPRiVdI9rDCZy4gRfroe/Og8t3lgfThaQ2jdn4HjrHd6vsUF//ZDR uAuCgfx0Kfs8c6tKfkDsDGV6TXwfvTVV3M8/MhHUn1gIvbWc/GhSiQsj8hxlljFbr1e65DJSbjK6 o67CzpxsuTEr4i6XBIjM5BLolRBsAeiBmtFZqYb3HnT8pFTDRKwwip0EgVRtAQaq/29wr/Ht42Xo FBAIcl5uXJPx05y+gEkeikU2TmHP9wdzrWL2N+zwIUVjTW0Zcyv7W1ZpzwvAJCjh3hYanSHz3VnV IaNgu5B51BDKq8x4JM1nFArGWtn++VtpWrNW4Pz8T6Npl6aFbCq1rzzjiwTHBsv8WpUtmJbUqbBL qAOfbMMknfpCGnl2dh6JVmgMTkfxLIeByLOz1JqQM69CkebpTIuJupMzO686MNWTVrCLlM7M/+mS pIbQAQgEgl7osOPHPdSPyWQuKC4eNSHBcoHZ6Tes8+W4rarHTH4tK7NqrmDVjojXm20Rc+9Jo6Gr 3RF3mvxxvVPLym2qC1mVPcfrzbFI2Plmn0Wu8lXnsnX1O+tn3NYxfK4Mx0aZ4NpIRA2dZ/hI6dqS ltta2MUytVQolKqhr7Bk0ch7wlqhn5hJhMyZqKfH4PzHxEJ88KkgdmbjgL4rg+8P4jFfAIbAk0P8 hPAVGcYNaCmHQFg4wWcQCGtdzRvveXPP1iOX1LpbN9/z+u6tRy6uTbxvq+xvmnPF4rqQ1lbV3zz7 in444hb0/PLJh66eVbzugQ0LTzw5sHNGyfkP7q5a0uCvX33Nnp0F1YvrfXXn7rpuJ9QNLEDQB73K CXW7bGLdjkDdPooqXPqQRBqEYNCHBpmqhw1mvVQiUQXh+FDU3Kk6w0T4VHISZCyaZMVDZ3NhSg3e SfOf2cEJYWALBOAM1YWgL62099IHNlzVxWo8hQE/HfHek1ZmMbbCWaGq/gZf4oOcXGOha+PsLWWd VWGbgnuhdNumlZ2RxGLsEmq5YHckIpYo8tuWLcxtUomFiVZbVmVdPUlq5DzQSB6pJvdM1Mhhs0mi EIbIICeKKvNDZXZHKYSMkLBskCmJqjKyFCGHSWqWiO12bym4UA9Hszq9MW1ygMCammlNyybqaFhb dhLH1ANf/1aoNVYMXQW6CzgQSac6h5usyKRV8UpkBed527fOya01FgmESk9FdmYBDML5EltmVeas JfxMEqB6/VBS4mPmzdu7ojTxtj6zPnJz6/a2FVE792n04nVzbfrzFyf+ZfIqZCqpQCjXKRhnfntB WkI3quZbs4KeplVb03O9+sQN4YYuwoyMjLzHPQa9aRq5eqJ2HyVa9n1SQ4rZT6Jaaw0E4tcWNzjF WeKsPAXdzmzoyhtk1h2MOif52VoYelOOKDgJdPyRnf2VE90JFnqcKKlFLtUbk4tIEV0nUl+Ce4wT SZUaqSqzalZhcVuu2VfZMaOj0td+zZNbatfGytMF1NWQaSNNffUVvZVOX0Xb9LYKX8uOgXPz504r NEgF+yQOn99pSLOnOfKqnL6SSFZuWVt/zcLvX9BgdLgdDonLH3QZnH6Xo7Axw18aycwtbVtcO/fW NVVqc7reCGP3zWCnl4OdekjfpLFbTiQSg1RvMeglBnA7o9KoVK9ypjoc1NjaMXycibx0gg7WmhPU 7P5NxjH/NGVM7jE/S3A5nc/BMz/6PIdTuQ2m8sTP1HJI1xgU3PUKpeAtMTilHtPnQ6PDrd6klziD GR4jP7NvhvG1A3yRMFkzqSbmMHG7jCa5LDCLuGQmo9wdloAfZBtkNh6MCse7iMkpKOkxqf9zflqt SR4UJ8KWHptu9qetuuPERVf8dK3LejurTrkqt2tURXNromu6K1TfYdVO6Cm5kMq8dtHRi2tqdzx+ CUdSFR0mHetavcG21Y2cKJVGa/wU+DKHoMaV5OFJNU6LyOV+pc+vkOXmkvxKkuezKPIUeZUW71G2 AWYgD/tc1Bm1lMzKnJUrr7RE/J58iV1GlGaBzzd5wY2uCPVrOoZeG9JA/0iLWMB/Rs9GcyJFqjH7 17njmHcDTg2TOgrwfYM1olMz5t7km0wisfA6mTWrvqC43q9iImziNpk5UFdY2RJUMk2MML0kP6PU JrayzCGJ3lOSk1OcLmHyWeZ+odZdmhXO0ynUtRa7SiBQWo1c1RfP8Mcqh1Ww3hXQC4VKk+4LP/eq 3qyEHBbDFyHubboHIDaFvTCeV4+8J0jjXiYB8HJufoRr4VrH1v1Su8QxyIYfgsmlQkJfjyGBvEH2 /qhCL60I2gUBwrlbM+mXbtZpxYNM96GoqoNrT01bNUO0i1CHeOjka0NUk8lNkaj8a1xNdZnarhq/ YDGZkxtSYgYmvnG7ByXcUkFJlTNoEbPp6rq5a8pnroraLPnT1+zu7dqRq4FzjpBZwiZe8MZKM5uK M2xKqSXkzJo/s0rlNuroxtQeV3N5oHTRtvqam2+6elVNY90Mo476OolPS0pC9T2L+jMcxZlpRfO2 NlJbrRh5n5vLvUSKyPkTtXcoPZ1oQ4VHGS8REhkTGohMcx1lfCSNGJiZB6P+DuxuwyeHakBg2YD7 Jo+SwrO7IjmxjS3zTGObJ6LUWo8OxnPlOptGnZ5RnVc4qypklTe3l84sy9DKpBKl1lbe3pu77wFz YdeWO5aH2qN54CUuMZcXei2OtJzWBYvmuDq77d50nVZbUJhtdVs1P76/6sa9u1ZFFcZ0s476AxUw Xz0N9pMDvfXQRA0czswvEQmIdJDdG5V6tQoHZzB4I4PsnmiQeLVaRf77mSVPhYhII4qKZor6RHHR MZHYBktTR+Y0xUjU0TE6ICV3x3CFSzc3+c4GMTNvUP5vfrOUFsG/nqBBduLymBUXUitjxTQH93Tt 1b+9cb5A0L2gbuWMQoVCJpJr5Yro3HXlfXv6ctNKe7bfvXLe5d0Z/6ipzJ9RGVZ2z1xd52BfbdnQ lWXO1nfO0pv1KrU2KxyQKSwGZWjWJXPqb7t55/LqcPO8+lCRr6orYvTlgS8wLbGXiwq3kBi5c1LP 1Dm0zqPsFuizWlCntrWyJdpaEW01mVqjFQKSCZN64OD0ZkflIBM6XOH06VpaimlS1DcjpYbj0L2G j1Pv+zi/g8DP9biHgDuXirO+xSQPQSwuSO7UoINFXdPxnsLYTkRBcqvZbDJxUU4okaskIr3FqXNF PBaJ+gdqBSdRqPTyu7+nrZh74fTCJplQAI6FXCUVQbKa5pJ+e51CyYllGr1yrV5TPe/C6dbCTJdI JBQWimwen1MvEot0wepwO92D8Psc+i9OdV0cC2skIpVSlO6GBJZj9aGabPaU1iJz+fx2/ZLuHbPD QqlCBAs/6N+BkdOwslxHaskVE9sgqslJ89XKicwrt8hrCwVC/SDTE9VFy6Z502TElyNyZDQ52oXt Y2s66pbS8TByHNaB6NAe/lqXjl82Fxentu1H14VMaqJWcWI8NBpg1bgSJuG8gC9ilbLnCkRSg8uU 0TujWtkJyfk+f8QmYRkxq3Ll+f0Rq4RtFirUarG+LraksGFhpU0i9sjUvLcqY83GIqPJb1MXzt1S n1ibShbC4louEsk1ssQtpvy8HJ0rWugONCws9TXT+QX0x2YJpxM9ySCrJmrwoQynwQGrBSYqlzkd DoMzQ+BLUw8yNx8WRn2tacm54PWOIS2q7eRQcvn88H/IO855SX6XMcmVYf1iS6g8nFlkE0hSR1zi H2MaOUB15ucPBc/4C5xKpbPA78t3qVSu/M8LU1XntoETD1VXy5KWwobBUoykebKlGIk8KiMyo1wg 1DQl25Wvk/VEcg/ryyfHNXaqYRkvrOXzfQHalOPbzPPltsDyiOwwMs+j67QJ5TE3ZGfnlJlNHvd0 z7x58OxSj7xrmjZErTA92jqtNMdtlhFTttwzb3pDmaqgurWgPX3UHpMGCT0f2oS3ZRg6jmsL8vn9 DajNwW9yr8m2HZhg2mdKSiolaermMYsX3smqQTW+XKuUA4v3Zodmz6ii9k4Tqe5WiYS+rFRiqskP skpb2OEMmsSs3djUu7K0PFZiF5ibe1eUNC0qt0ok4zqCOdscKS/svaA+sXpcYp45q2xiIrc9tVGy 19ta7neWTAv7Wsr9wcYFxd5mf3J0eQfaqJxsm9RGijyr1Rbg1AKVX22kyjREi6cJVDa/VZ0XkLjC ra526cQBYmxg4VvhCDGezVX4JczXUDT3jlR8XrJ7gC5XC4WB7MkDykRdzju3vGlRhZV92dvkH35l TGGWfH12+b9VWEbTAupjVIKPSkBLyR2m8XqiO0yP8DtMj/A7TJ4B/bSMQcZ7MCruOOMO0xkznMUO k4DYyuddcvfyZXsX544dJb7QBquy8mfW5DhUY0fs+pZbb7ikvzQy78rZLbdef2kfPVqeWZttCdbN 6VuSnVkHR/Vz+hcTduSNxM183TJhaT9plo8q3UXFCmWRssiiNFsI9bylYbOiuMgtEOeCxxxVBqaZ lRaXQGdr1c0og5TxleIbGCeck0MRfinDf8egZah1HP7atxmno+D4jZNxpiFMzUhikwl1xjvePaGm ilzdDGoefn8OmMdpQXG1MwheeLq6dt6a8o6VtfbEsDwtmJ49b2a1Mh0884zGEvDM2ctrb7np6hXV GnvQlFiTGtoEb6A/foO7uSJQNP+iBZ7SoIG64zt5/7yvP9mvFKDVArJ1kk71Ia3Wrksn9nT6TWxE wSk58JYWRTXR7Gm6dG3IHhSZPa3m0WGYKoH6i7R3je55U+/o318y2Sf6qlHLxCkEEoVaL5fqTFat p6OpRDFzrB8NsKpUP0q31DS3+9VOm1Ek4h4U+3ILstLFYnFh7PzqxHlf7j7XhVuKHDDbC0WgDRZ8 dDFoo4lcPlEbjxI1uxWcyEL25qjeVAGBeNWFUVvjO0LZe9FprkGGHM6M/Ctqm7j0OMOGkuIsL5u4 aqG7SYLRPbmJbiK4N4LkhhJVk1is0iuU3vz6bG+JT1/Q3tOeX37enUtz5zTmKiRiTixVqCQqT/GM ioyqkD5v2pxpecUrblqYOaMmIpNzFygiuV69WadzZlqcmf5Q5eza9ksXFqkMVrlEp5KmezzpWos9 Te/JSvNmBULls2ubt80rkOtMcn5mXzjyIfsXwQHSOHmFHLUXZ4VLwnUSaa20tkQaDueWmEvMJLeu paS2UpIFrvMhadhd3AKOyqyDUfe4NUjZUP6JMrotc4L/WqQs2T+PH9fgt6OHz/oWY9vCX72EGfW5 2VGfm/fSoVZianw/7+aEgQyLJ00nkcglSo1U6ssrTa+cV+1khUJuzmqlQqyx6s4N8cM+nVfZ0ONa BXezzOnz2fWJBeoMZcgvlorVWn1utl8q1SjEacXdlXK7y61kDmot2pKiwC+g/wqF0H9/we9qzYEx 3cI9BavGCyfp1Ca3kLzK/DyvL81C5BZfXn6lN00qLGl1tII65hyKajqEY/sEye/cCvKP854Ivx7U nN1l41yO0b2F4nHbXaLRPYXRtCUwsWU6aYfkbIameatKm/orbFLx2mSXpb4FdD+DE1zsmTWadkaT 6snuVMe8wdtc4QvWLyzxNPvZjFTq8LumXJMlmK4qWnDJNOay0a9XOFIw8qngX4ybn/uaSdljJJfT gtIs8OkjhNM+rChpd7bXh/X0DWxxeyilzHDN8PHjdHcLpj46+fknz2//Ic7MEykN9vJcX066Qqw0 OErzAhGblHlOpDA4ynO9kXS5WKl3lOUGwBr4VHvFWGoedVEfV0Xysx16hcWbps7NhSNlms90lmlg ISPnJ14Q+ITPgT/teZQY2duIHOb62w/KNMJQalcwzL9w8hpUTz/hFRmTySDeLDZ6clxZhWmMhLtH bHBHXOGiNGliWKmRCSWaNK1oj1KLR3QXh9nDNrML4FnWASLX/ZTJJBISSqkyQrdn8nJxn3dsd5dt hvWpxqRK9OnUrBiO1MxdejWbJ3b4/C6DMU3i9PqdOjO19t7EnewrwuuJn2QfIQbWNyATph9lCwgh ZnbbQ0K3+spxDUfr9NKQ5nWoFiOS0TESBsDUGAkNZE0ta9jnV904P4P2KY4z5oTSAxY56w0H5n9n k0hrz/H6ss2MsOe+xP7EscTLO3JWrV6RpTFrJAKxXLyBYW/YzuiYLKb+J1IlJKlMoPEnoJS1Y6X0 YykL+VJuhVJeqR4rZaRmrJRcsZV/iSwYSA3XOqNBxiZfWyosXrl3fibM3HJOYMrOSPcnS3n7JrHW nu3zZ5kTv7uPmcnUMqEdkVWrl2dpLBoxJ5GJNyQSN25PfJR4MfHoj6VKqUCiMpLkjqVF6CdOUkau mvydXMXIsahUzXZAi6o58gj7NHGNvPsQJLiyB9mnH1K7smVe+j64rQtcnzUHo7Kxbzz4SW3oZBgq RPeHbFEpf5N/fwU0EWTmR+Cxl+UEJSl/CDxpkVgl5Mfl4pJqocCisGWUt0eqf7Jt6TU9IYhUtOU6 pvWuqFy+e7Y/8Xlde2adzVmY6TDK69sy661w6DTKuDsKrrzlu3svi1RNK1524/y8K2+GSK6jwKsv Pef6Bf1zHVbX6suvu/xcR99cu9W55jI4BJtrguFhrdBMcsjuyVrKBS1ZqJZyoYKZhrDeZdAbiFWe 6ZcYDYPM9w76Z9EBpWrsvQVYoQ2f0NL3VY6fSH39n9KTDG/zH69N6so/vhsV6EFtAXzv0J8aZaED c2v5l3rkw0VKFb4Tceqedw1WlVCoMmuZKrEmLeQM5JgFzIsvKhXfFzv8PpfeZBLbvQGHgavZIBWK dWpVpCBL+pBAyDGcWCH9/Lf0P6UiMKFzn4D11E/+9vIIaUzZTiNUJzrInnhYpwuSIFFa6T+dLFXm HGUuhkHXyVwZlVr1NZykoEsXHWTOH1fTx+m8wm/nvoavXpZpUuZ0iL/t17jHRHUl53GmWjjxdc2U rdENN7GYvkNyISeRq/XKYYvBqhGJdH4Hk1fZWw1TlsJRlFHUN71Ewb9dCe6ionnJ1pqV187yqP11 y/b0DzJDOtUPxU5fwGkQqQwqdX5VjY2RFy+c2VSep9dnes1Ov9NilKR7/F67TBHwphV1LcvN6l20 /IKrZnzHQbWrB0/zbdDuXPLaZO3OT2l3Pu1Ug1wwqiSxDFKbQUhGLacupv++dKZacZTZSkykiSk7 XG2CYCujfa8tljfIqA/5/eK2Ltsgs3b86wG6sshQmQa/r6TeKP8yJr4UpRuvffrY//rdx/X3M/us rHd0d5NPCHz5zVreNzM6OO4eS8mci+9fndfb2WDTqTgRLARk8qzGvprm5Q1uc0lv/YUGLZiu2qhc V7+qNdgws7B/ZrlCIRfKwRWuX7y1du6VczIzOs5rqu0tTWPujZyzZG5DSK63aeTpJokDJh+91WUN 1szMcJdmWLRGscMD3pq/pitSUu8KuIw6WWZeRKEI+NKCzcuqo1sWt8DT8hpnwRgrg/XTB0IDjB35 5MnJLVkILZlLW7IQVJrnzHXlG/QRfVgizZRK9ZkRp9UVgXiEWHMjmZzBpYIBwZkPeo1Ko3op2FVM AtqN1ETwG9T846BkdOLQFZ7kDMN6dWyo0fLP/Fr3Hd9iXnHK30uOP2N7pjDmMF7Gzb2CHvGGCC5X qa+bk9Bb9XSVppOzHrE90hgpaM7Qst9dr1Qm3mcTVUwnE5fSXqN/P7UQe99olXrCUE4V+zSdumCO ln/xmYVdPHwYekka9BL6ZmU9efVMY5AyNQZVZFWGoaeIo2oSVmeRLFKgdpFKTlwzyJRG5f5QyJYV joDZVtB/WBXpTFq3bbwF06UX/bZER18hifDfmCRXbrRzjB/F5fwj/xvufxZdxEO/oEq9v5J8qRO3 ErgfO2sWX37vOeFYR32aWgHrOqVWLgvVzK1s3zAjqC+I1dUuz3ToJeskAQ+7TK2EZtEYlInCEm+h c+UtC7OYU7U7NixuyZBpzUqx0SB2BkMek8VmzmxdWpZeEDIr7EE2P+Q1GWWeUKbHlPiAE+TMXAcW 3wVehUHoIwVkGtk/uVXaoVUUtFXaQUXVWbbao+x+ooBl8zMPE2JTeDxBGEjKH66tzuIiEXGQ/vsx Y1fDIFM54T0m/ksr+sm/C5v6qiXla9Bbf90bTVI16FlEvxo1oU5Tew+o2dHNmdQyUcC9YMydsfVH q/u/1e2XWLKbz9k9uLFlQ9is5YQy0LrSU9AY6bxoXpWu8IpZsy9o9yROa9xFPlt5SaFFKWtuyGwo CqQpWEPulgs3zS8pXPStLu+2W+6759sbGgwaqVkvtnn8DoNSo6hY+q1p9kD29OWL03PcWqkuTVWz JDi/w5lf19hA54xVI6cFs/h3rM6frHc36F1P9e4G5QhFWqNGqBFxcu0gs+NQNL1TPvqOFG/WT/Gb 6Slr5i/5ytxjmmPFzOjaYfyrG7NEaqth+AapJVASLK62M3J27/A7KvqVlMao5Fi7QfBHVUF1g+uL AKwoOLEG1PaJ2SxxZ2T6TOBpcMRGv1mHuTCDVJFO8uzkunWl5sMuKGjhUfYnxECq2WdhVvSX1WsF EDMQReZRNk5cpIV95qDCrwXb2BSVZhbaqlvq68UR+s8NbV0dg4xmsnXQzlg2xPuzST9EZy7D6YtX z8P8Q7/BDb9scGzJWP/mJzaY1wpHN3fotjyNBlVcajHNPaqPTN/8w9VLb16clx27cHqsw5zXsea6 uefunuXOmrGqqmharumHKldxsLQjzyRNz88omlmcvkzlq8xq7Su1aIO1eVU9ZTZmh693Xqw+mNm+ Mlq7fslsf+GOjvCCOTMqPLltCyP16xd2OFy1zR3sDEPQqfMU1jksGaGQJa2oqm74e5acnIjVU1Nb 50vL8uhdJc2E/57qPYEEWquItJPbJ7fV9FT/n049wxx7Pfb/YlhREKKww/hY9lBOXp44g/47UuPs Jui3oMGuCRoc+nKvP8Tf7+yuTmpeP6Zq0RlG1xJcg/hTGxep3XzBLkPuzK13064ekKRlt67ae2xb sKE83whWK6JDrDJU1h6JXbqgSl9AO3ubhxHSzp5eBp1doWjhO7tFyZ4e19m3fvv+e27Z2ADTpURq 0ovSqb+h0qrKln6rLdndI8nuviwwf7qjoK4Juju5DwNT/2/Cz78c2LYzhKe4yyaFp/9dEHjGhWeF i8aFE2cOotk0iEXJ8MBYkKiTYeeZg7R6KnxleP2rg2zhVwe54gzh1//zQbGWD3/+z0EZHheGVddP CIkzB/X9NGhyk+H5Lwfttm8SdKqpMBWmwn85XHNW4fFx4ZMzB32D/tv/rwZD2HDYuMzUavqn+QnL JZYP0p6wbp4KU2EqTIWpMBWmwlSYClNhKkyFqTAVpsJUmApTYSpMhakwFf5vDfgHRunfvoIfA+F4 XkREZAWh77ZEICwkbYTjPuL+xn3IbGeuJY1kKfcpt577hPuYO8X9lRsiG5m5zHmMg7meuZrRMAuY EMMytzOb4R46IiBB5hDXy31G0kmAzCUNZA53ManmVnOXMJvg7MX0z5rSv69FyKnIyAh8MvQT4gL4 /J99OuGfo4P6s4T+gTAJId3deUVNG3Nz+TOEuZ7+76Zn+SOZGD1FTo1MSGCSf8NVNSbMc8BXRh7/ RhIgfWcj3Duk8qzkQVIkTCML/p2wHlL4TYVbDM84g4gSpFAY/QrpJYu+jgjqSOGoXDpRuCOEnFH+ Tm4eL8IysvnriLiWPDUlU/J1RVBGqr+JcG2k4hvJR2cn7M6Rtv8XRFBKAilh/vE/K6K1Y8/6Cqn8 WlI28mZK2BdIYLxwQcKejbBPkYX/XwmUec6UTMmUTMmUTMn/bhHGScF/l3BbR9afSdgN4Ct9HbmY 9LIXj/x8Sv7vElinV5MmIiN6kDTSRVYRGwnQPxn+H/YD6HpfeMfggfj+RxapKz8jabhBcPSDi56l fNJz63mntwzvljnEj8K9pPweBPz8L3SL96sKZW5kc3RyZWFtCmVuZG9iagoxMDAgMCBvYmoKMTM3 MDIKZW5kb2JqCjEwMSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwMiAwIFI+ PnN0cmVhbQp4nF2QMQ7CMAxF95wiN6hbIAEJeYGlAwgJLhBSB2VoGoV24PbUNTAwvEhP+Vb8Ux3a Y5viqKtLGfyVRh1i6go9h6l40nd6xKTqRnfRjx9bTt+7rKrDyeXbK5OeAxRULQk/dPTMzlNx6UFq D4D7EFBR6v6urAzcwzdZowBmi7M2KICpWVcogPGsaxTAGNYNCtAAq0EBrGW1KIDdLZt83+SluAtX ObuetJ9KoTQuhZeCXC0m+v1JHjJP6Rn1BmAiYBsKZW5kc3RyZWFtCmVuZG9iagoxMDIgMCBvYmoK MTkyCmVuZG9iagozMyAwIG9iago8PC9CYXNlRm9udC9MSVhEUEQrVFQxNUR0MDAvRm9udERlc2Ny aXB0b3IgMzIgMCBSL1RvVW5pY29kZSAxMDEgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFz dENoYXIgNy9XaWR0aHNbIDUxNCA1MTQgMjI5IDMwNSAyMjYgNzE1IDQ0N10KL0VuY29kaW5nIDEw MyAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iagoxMDMgMCBvYmoKPDwvVHlwZS9FbmNvZGlu Zy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2czNDYvZzI1OC9n MzY3L2cyOTYvZzMvZzQ0OS9nNDU1XT4+CmVuZG9iago1NiAwIG9iago8PC9CYXNlRm9udC9XQVJL VUsrVGltZXMtQm9sZEl0YWxpYy9Gb250RGVzY3JpcHRvciA1NSAwIFIvVHlwZS9Gb250Ci9GaXJz dENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRoc1sKMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAw IDAgMCAzMzMgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCA3MjIg NjY3IDY2NyAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNjY3IDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMAowIDUwMCAwIDQ0NCA1MDAgNDQ0IDAgMCAwIDI3OCAwIDUwMCAyNzggNzc4IDU1NiA1MDAK NTAwIDAgMzg5IDM4OSAyNzggNTU2IDQ0NCAwIDAgNDQ0XQovRW5jb2RpbmcvV2luQW5zaUVuY29k aW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTA0IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMTA1IDAgUj4+c3RyZWFtCnicXZJBboNADEX3nIIbxB5gppEib9JNFq0qtRcgwxCx CCCSLHr7+ttNF108lK8xxm/i3fH0epqne7372Jb8We71OM3DVm7LY8ulPpfLNFcc6mHK999kz3zt 12p3fOvXr++11FpQxoq9Ii9Dua19Lls/X0p1IJLDOEpV5uHfUZP8jfP4LGVxqO1EYxCHuhaxEYe6 BrEVh9o9YicOBUKM4lCbEJM4lKzVizgUGXEvDsWC2ItD0YrP4lAKiFkcivbdQRxKPWIRh+KIOIpD LT7EehdATyOiurL5JviyurL5xoyormy+Cb6srmy+0YrVlc03QZDVld3XitWV3RdDsrqy+0KB1ZXN t4UgqyubYLRWKscuaK1Ujl0QF8sqxy44IKocm2CCkd69oadnRJULJtihc1C54H8oWgWVC6bQYKqg 4wdTaHBXQccPptDaqY4fbGb9hWV6bg32CuuIbXzvr6XOj20r89121nYU2znN5W+t12XFW7VS/QAI V8DBCmVuZHN0cmVhbQplbmRvYmoKMTA1IDAgb2JqCjM3NwplbmRvYmoKMTEgMCBvYmoKPDwvQmFz ZUZvbnQvR0NDQkJZK1RUMTVFdDAwL0ZvbnREZXNjcmlwdG9yIDEwIDAgUi9Ub1VuaWNvZGUgMTA0 IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDQxL1dpZHRoc1sgNDg4IDQ5NSA0 NzMgMjY3IDIyNiA2MzcgMzQ3IDQ5NCA1MzcgNTM3IDM1NSAyNDYgMzk3IDUzOCA2MDYKMzE2IDUz NyAyNDYgMzk5IDUwMyA3NDUgNTI5IDQ3NCA1MzcgNjMwIDQ3NCA1MzcgNDE4IDUzNyA4MTMgNDcz CjQ4MCA5MDYgNTMyIDUwNyA1MDcgNTA3IDUwNyA1NjEgMzEyIDMxMl0KL0VuY29kaW5nIDEwNiAw IFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iagoxMDYgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9C YXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2cyOC9nMTAwL2c5NC9n NDcvZzMvZzM5L2c0MTAvZzI1OC9nMzc0L2cyODIvZzM5Ni9nMzQ5L2c0NjAvZzM4MS9nNC9nMjk2 L2c0MzcvZzM2Ny9nNDAwL2cyODYvZzQ0OS9nMTgvZzQ1NS9nMjcxL2cyNC9nMzM2L2czNDYvZzI3 Mi9nMzkzL2czNzMvZzQ0OC9nMzY0L2cxMTYvZzg3L2cxMDA2L2cxMDA3L2cxMDA4L2cxMDA1L2cx Ny9nODk0L2c4OTVdPj4KZW5kb2JqCjEwNyAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDEwOCAwIFI+PnN0cmVhbQp4nF3UMW7bQBAF0F6n4A20M0ORNmBsYzcuEgRILkCRS0OFKYGW i9w+//+JU6T4AkbcJfftkHt8fn153S737vhjv84/271bL9uyt4/r5z637tzeLtvBvFsu8/1vpd/5 fbodjs/fptuv37fWYUBbD5Yj5uvSPm7T3PZpe2uHp1Lq07rWQ9uW/y4Nfc44r19DrWbKqVSUXjNl MJZRM2VYWfY1U4aZ5almimvuUDOl71mONVOGE8uHmim95j7WTBl1daqZMmruuWbK8MhyrpkyBsul Zoo/sGw1U06au9ZMGTjYsBcMyoUlrCZvzzsbrCavq4TV5A3e2WC19KqE1eTtuWaD1eQ96UGwmryj s4TV5B11Z1hN3tPIElaTdzizhNXkHbmTBqvJO2kurCZv6M6wmoDBwdh7BYTGEjhPIDvowHk2lM91 4FzAcWAJnCeQW+fAeQIpcuBcwIHPdeA8G6q5wLmAg54LnAvYc58dOM+GTiyBcwGd3cfPky9ct6mE yLOD3FgHzgXs+SAoFVzlMgK4SCBF2BIFu0FCABcCOpeB/xQsgx0M4ELAUXOBiwRykQFcCBgqgYt8 Y/nyB3CRbyw3FkMUXGUHA7gQMLh1AWCog665sEZ2kMCANeTttSpYI70E9rD26eWD0EYFV9luDFFw Z9MX/vUp82PnGcEj4vv03rr5c9/bdtdBooODR8Zla//Omtv1xlkdcvgD76oZjQplbmRzdHJlYW0K ZW5kb2JqCjEwOCAwIG9iago1MzkKZW5kb2JqCjEzIDAgb2JqCjw8L0Jhc2VGb250L1dRSk9QTytU VDE1Q3QwMC9Gb250RGVzY3JpcHRvciAxMiAwIFIvVG9Vbmljb2RlIDEwNyAwIFIvVHlwZS9Gb250 Ci9GaXJzdENoYXIgMS9MYXN0Q2hhciA2Ni9XaWR0aHNbIDUxNyA0NzkgNTI3IDIyOSAyMjYgNjE1 IDQ5OCA0MjAgNTI1IDMzNSAyMjkgMzkxIDMwMyA0ODcgNDIzCjc5OSAyNTIgMzAzIDUwNyA1MjUg NDg4IDQ1OSAzNDkgNDUzIDg5MCA0NTUgNTI1IDgzNCA1MDcgNTA3IDUwNwoyNTIgNTc5IDQ3MSA0 NTIgNTI1IDUzMyA1MjUgMzA1IDUyNSA4NTUgMzk1IDI1MCA0MTggNDE4IDY0MiA0NTkKNTQzIDYz MSA1MDcgMzA2IDQzMyA3MTUgMjM5IDI2OCA2NjIgNTI1IDUyMCA1MDcgMzg2IDUwNyA2MjMgNTQ0 CjY3MyA4OTQgMzI2XQovRW5jb2RpbmcgMTA5IDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4KZW5kb2Jq CjEwOSAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv RGlmZmVyZW5jZXNbCjEvZzg3L2cyNTgvZzM4MS9nMzY3L2czL2cyNC9nMjg2L2c2Mi9nNDM3L2c0 MTAvZzM0OS9nNDAwL2c4OTQvZzEwMC9nMjcyL2czNzMvZzQ3L2c4OTUvZzEwMTIvZzM0Ni9nMjgv Zzk0L2czOTYvZzQ1NS9nMTE2L2czNjQvZzM5My9nOTI2L2cxMDA2L2cxMDA0L2cxMDA1L2c4NTYv ZzQvZzMzNi9nNDQ4L2cyODIvZzE4L2cyNzEvZzI5Ni9nMzc0L2c2OC9nNDYwL2c4NTMvZzg2Mi9n ODYzL2cxMDQvZzM4L2c5MC9nMzkvZzEwMDgvZzg4Mi9nNDU0L2c0NDkvZzM2MS9nODU1L2c3NS9n Mzk1L2c2MC9nMTAwNy9nODc2L2cxMDA5L2c0NC9nMTcvZzg5L2c5MjMvZzg0Ml0+PgplbmRvYmoK MjQgMCBvYmoKPDwvQmFzZUZvbnQvU1hHUUlZK0hlbHZldGljYS9Gb250RGVzY3JpcHRvciAyMyAw IFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNDgvTGFzdENoYXIgMTQ5L1dpZHRoc1sKNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAK MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMzUwXQovRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTEwIDAgb2JqCjw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMTExIDAgUj4+c3RyZWFtCnicXdNBTuQwEAXQfU6RG3RV2XFA ankDGxaDkOACacdBWZCOQrOY21P/G2Yxi4/0idP2s+PTw9Pj07be+tPLcS2v9dYv6zYf9fP6dZTa X+r7unVq/byW20/j3/Ix7d3p4c+0v/3da+8D6tJpG1Guc/3cp1KPaXuv3Vkkn5cld3Wb/3sUh/bG ZfkdqrlF4n32arlFhoAacovEBTXmFjFBHXKLBENNuUXCiDrmFgkcfJdbJPGn7nOLjHx3yi0SK+ol t8gQUUtukXCHOucWsRm15hYJA+qSzyqsIKjjlMCQUB2nBAZFdZwSOGDN6jglMGEidZwSmAqq45TA hInUcUrgyIkcpwSO8KrjlMDEp45TAhP2WR2nBCauynFKYOKqHKcEjuCr45TAhM1RABeuGcvwo2B8 6zCRudXageKnzK1GbwTQ3Gr0jnzXrYwYlmFutXagWKT/72wERg52nBE44MjMcUZgxCmY44zAAXxz nBFo2ElznBEYsZN+bow/xcdgjjMCjfM6zghMMz/i368V3zOuAW7B8/RR+/J1HHW78a7wbuBWrFv9 d5326463ek/3DYZ73EMKZW5kc3RyZWFtCmVuZG9iagoxMTEgMCBvYmoKNDMzCmVuZG9iago2NCAw IG9iago8PC9CYXNlRm9udC9VVkpFWUIrVFQxNUZ0MDAvRm9udERlc2NyaXB0b3IgNjMgMCBSL1Rv VW5pY29kZSAxMTAgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIgNDcvV2lkdGhz WyAyNjcgNDY1IDY2OCAyMjYgNTA3IDUwNyA1MDcgNTI3IDM1MiA2NTYgNDk1IDUwNyAzMDYgNTA3 IDUwNwo1MDcgNTA3IDUwNyA5MDcgNTI3IDI0NiA0OTEgMzk0IDUyOCA0MTIgMjQ2IDMxNiA1Mjgg MzQ3IDUyNyA2NTMKNTE5IDYwNiA2MzcgNTI3IDcxMSA1MDcgNDg4IDQ1OSA1NjMgODc0IDUzMiAz MTIgNDIzIDQzNCAzMTIgODA0XQovRW5jb2RpbmcgMTEyIDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4K ZW5kb2JqCjExMiAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvRGlmZmVyZW5jZXNbCjEvZzQ3L2c5NC9nNzUvZzMvZzEwMDYvZzEwMTEvZzEwMDQvZzM4 MS9nMzk2L2c2OS9nMTAwL2cxMDEyL2c4ODIvZzEwMDkvZzEwMDcvZzEwMDgvZzEwMTAvZzEwMDUv ZzExNi9nMzQ2L2czNjcvZzI4Ni9nNDAwL2czOTMvZzI3Mi9nMzQ5L2cyOTYvZzI1OC9nNDEwL2cz NzQvZzEwNC9nMTgvZzQvZzM5L2c0MzcvZzg1Ny9nMTAxMy9nMjgvZzM4L2c5MC9nNjgvZzg3L2c4 OTQvZzYyL2c4NzYvZzg5NS9nMzczXT4+CmVuZG9iagozMiAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL0xJWERQRCtUVDE1RHQwMC9Gb250QkJveFstOTUgLTE3OCA3MTkgNjgz XS9GbGFncyA0Ci9Bc2NlbnQgNjgzCi9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xNzgKL0l0YWxp Y0FuZ2xlIDAKL1N0ZW1WIDEwNwovTWlzc2luZ1dpZHRoIDUwNgovRm9udEZpbGUyIDg5IDAgUj4+ CmVuZG9iago1NSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1dBUktVSytU aW1lcy1Cb2xkSXRhbGljL0ZvbnRCQm94Wy0xMjAgLTIwNSA3MjIgNjk5XS9GbGFncyA0Ci9Bc2Nl bnQgNjk5Ci9DYXBIZWlnaHQgNjk5Ci9EZXNjZW50IC0yMDUKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1W IDEwOAovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgveS9uL2Mvby9kL3AvZS9EL0Uvci9GL3Mv Ui90L2kvUy91L3Yvay9sL2EvbS9wYXJlbmxlZnQvcGFyZW5yaWdodC9zcGFjZS9oeXBoZW4pL0Zv bnRGaWxlMyA5MSAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250TmFtZS9HQ0NCQlkrVFQxNUV0MDAvRm9udEJCb3hbMCAtMTc4IDg4NCA2OTVdL0ZsYWdzIDQK L0FzY2VudCA2OTUKL0NhcEhlaWdodCA2OTUKL0Rlc2NlbnQgLTE3OAovSXRhbGljQW5nbGUgMAov U3RlbVYgMTMyCi9NaXNzaW5nV2lkdGggNTA2Ci9Gb250RmlsZTIgOTMgMCBSPj4KZW5kb2JqCjEy IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvV1FKT1BPK1RUMTVDdDAwL0Zv bnRCQm94Wy0yMCAtMTc4IDg1OSA3MTddL0ZsYWdzIDQKL0FzY2VudCA3MTcKL0NhcEhlaWdodCA3 MTcKL0Rlc2NlbnQgLTE3OAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTI4Ci9NaXNzaW5nV2lkdGgg NTA2Ci9Gb250RmlsZTIgOTUgMCBSPj4KZW5kb2JqCjIzIDAgb2JqCjw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udE5hbWUvU1hHUUlZK0hlbHZldGljYS9Gb250QkJveFswIC0yMyA1MjAgNzA5XS9G bGFncyA0Ci9Bc2NlbnQgNzA5Ci9DYXBIZWlnaHQgNzA5Ci9EZXNjZW50IC0yMwovSXRhbGljQW5n bGUgMAovU3RlbVYgNzgKL01pc3NpbmdXaWR0aCAyNzgKL0NoYXJTZXQoL3R3by9idWxsZXQvdGhy ZWUvZm91ci9maXZlL3NpeC9zZXZlbi9laWdodC9uaW5lL3plcm8vb25lKS9Gb250RmlsZTMgOTcg MCBSPj4KZW5kb2JqCjYzIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVVZK RVlCK1RUMTVGdDAwL0ZvbnRCQm94Wy04OCAtMTc4IDk2MiA3MjZdL0ZsYWdzIDQKL0FzY2VudCA3 MjYKL0NhcEhlaWdodCA3MjYKL0Rlc2NlbnQgLTE3OAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQ0 Ci9NaXNzaW5nV2lkdGggNTA2Ci9Gb250RmlsZTIgOTkgMCBSPj4KZW5kb2JqCjIgMCBvYmoKPDwv UHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDguMTUpCi9DcmVhdGlvbkRhdGUoRDoyMDEzMDExNTEy MDUxMSkKL01vZERhdGUoRDoyMDEzMDExNTEyMDUxMSkKL1RpdGxlKE1pY3Jvc29mdCBQb3dlclBv aW50IC0gREVMVVRJSVMucHB0IFtDb21wYXRpYmlsaXR5IE1vZGVdKQovQ3JlYXRvcihQU2NyaXB0 NS5kbGwgVmVyc2lvbiA1LjIuMikKL0F1dGhvcihndWluZXQpPj5lbmRvYmoKeHJlZgowIDExMwow MDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwOTc3NTQgMDAwMDAgbiAKMDAwMDQwNjY4NCAwMDAwMCBu IAowMDAwMDk3NjIxIDAwMDAwIG4gCjAwMDAwOTU1NjQgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAw MCBuIAowMDAwMDAxMzE2IDAwMDAwIG4gCjAwMDAwOTc4MDIgMDAwMDAgbiAKMDAwMDI2MDkwNyAw MDAwMCBuIAowMDAwMDk3OTEyIDAwMDAwIG4gCjAwMDA0MDU4MDcgMDAwMDAgbiAKMDAwMDQwMTY2 NCAwMDAwMCBuIAowMDAwNDA2MDA5IDAwMDAwIG4gCjAwMDA0MDI5MDQgMDAwMDAgbiAKMDAwMDA5 Nzg0MyAwMDAwMCBuIAowMDAwMDk3ODczIDAwMDAwIG4gCjAwMDAzMTAxMDQgMDAwMDAgbiAKMDAw MDA5NTc0OSAwMDAwMCBuIAowMDAwMDAxMzM2IDAwMDAwIG4gCjAwMDAwMDk1MjMgMDAwMDAgbiAK MDAwMDMxMTMzOSAwMDAwMCBuIAowMDAwMzEwMTQ3IDAwMDAwIG4gCjAwMDAzMTAzOTIgMDAwMDAg biAKMDAwMDQwNjIxMyAwMDAwMCBuIAowMDAwNDAzNzMxIDAwMDAwIG4gCjAwMDAzMTAyODcgMDAw MDAgbiAKMDAwMDMxMDMxOSAwMDAwMCBuIAowMDAwMzEwMzQ5IDAwMDAwIG4gCjAwMDAzNDM3MTMg MDAwMDAgbiAKMDAwMDA5NTk2MyAwMDAwMCBuIAowMDAwMDA5NTQ0IDAwMDAwIG4gCjAwMDAwMTg0 MTIgMDAwMDAgbiAKMDAwMDQwNTMwMiAwMDAwMCBuIAowMDAwNDAwNDkzIDAwMDAwIG4gCjAwMDAz NDM3NTYgMDAwMDAgbiAKMDAwMDM0Mzc4OCAwMDAwMCBuIAowMDAwMzQzODE4IDAwMDAwIG4gCjAw MDAzNDM4NjEgMDAwMDAgbiAKMDAwMDA5NjE3NyAwMDAwMCBuIAowMDAwMDE4NDMzIDAwMDAwIG4g CjAwMDAwMjYwMDEgMDAwMDAgbiAKMDAwMDM0MzkxNSAwMDAwMCBuIAowMDAwMzQzOTQ3IDAwMDAw IG4gCjAwMDAzNDM5NzcgMDAwMDAgbiAKMDAwMDM0NDAyMCAwMDAwMCBuIAowMDAwMDk2MzkxIDAw MDAwIG4gCjAwMDAwMjYwMjIgMDAwMDAgbiAKMDAwMDAzMjk3NyAwMDAwMCBuIAowMDAwMzQ0MDc0 IDAwMDAwIG4gCjAwMDAzNDQxMDYgMDAwMDAgbiAKMDAwMDM0NDEzNiAwMDAwMCBuIAowMDAwMzQ0 MTc5IDAwMDAwIG4gCjAwMDAwOTY2MDUgMDAwMDAgbiAKMDAwMDAzMjk5OCAwMDAwMCBuIAowMDAw MDQ2Nzc5IDAwMDAwIG4gCjAwMDA0MDU1MDYgMDAwMDAgbiAKMDAwMDQwMDc5OSAwMDAwMCBuIAow MDAwMzQ0MjMzIDAwMDAwIG4gCjAwMDAzNDQyNjMgMDAwMDAgbiAKMDAwMDM0NDI5MyAwMDAwMCBu IAowMDAwMDk2NzkyIDAwMDAwIG4gCjAwMDAwNDY4MDEgMDAwMDAgbiAKMDAwMDA3NzgyMSAwMDAw MCBuIAowMDAwNDA2NDgwIDAwMDAwIG4gCjAwMDA0MDQ2MzkgMDAwMDAgbiAKMDAwMDM0NDM1OCAw MDAwMCBuIAowMDAwMzQ0MzkwIDAwMDAwIG4gCjAwMDAzNDQ0MjAgMDAwMDAgbiAKMDAwMDM0NDQ2 MSAwMDAwMCBuIAowMDAwMDk3MDA2IDAwMDAwIG4gCjAwMDAwNzc4NDMgMDAwMDAgbiAKMDAwMDA4 NTIwOCAwMDAwMCBuIAowMDAwMzQ0NTI2IDAwMDAwIG4gCjAwMDAzNDQ1NTggMDAwMDAgbiAKMDAw MDM0NDU4OCAwMDAwMCBuIAowMDAwMzQ0NjMxIDAwMDAwIG4gCjAwMDAwOTcyMjAgMDAwMDAgbiAK MDAwMDA4NTIyOSAwMDAwMCBuIAowMDAwMDkzNjYxIDAwMDAwIG4gCjAwMDAzNDQ2ODUgMDAwMDAg biAKMDAwMDM0NDcxNyAwMDAwMCBuIAowMDAwMzQ0NzQ3IDAwMDAwIG4gCjAwMDAzNDQ3OTAgMDAw MDAgbiAKMDAwMDA5NzQzNCAwMDAwMCBuIAowMDAwMDkzNjgyIDAwMDAwIG4gCjAwMDAwOTU1NDMg MDAwMDAgbiAKMDAwMDM0NDg0NCAwMDAwMCBuIAowMDAwMzQ0ODc0IDAwMDAwIG4gCjAwMDAzNDQ5 MDQgMDAwMDAgbiAKMDAwMDM0NDk0NyAwMDAwMCBuIAowMDAwMzUwOTM0IDAwMDAwIG4gCjAwMDAz NTA5NTUgMDAwMDAgbiAKMDAwMDM1NDAyNiAwMDAwMCBuIAowMDAwMzU0MDQ3IDAwMDAwIG4gCjAw MDAzNjY1OTMgMDAwMDAgbiAKMDAwMDM2NjYxNSAwMDAwMCBuIAowMDAwMzg1MDkyIDAwMDAwIG4g CjAwMDAzODUxMTQgMDAwMDAgbiAKMDAwMDM4NjM3NSAwMDAwMCBuIAowMDAwMzg2Mzk2IDAwMDAw IG4gCjAwMDA0MDAxODQgMDAwMDAgbiAKMDAwMDQwMDIwNyAwMDAwMCBuIAowMDAwNDAwNDcyIDAw MDAwIG4gCjAwMDA0MDA2ODUgMDAwMDAgbiAKMDAwMDQwMTE5MyAwMDAwMCBuIAowMDAwNDAxNjQz IDAwMDAwIG4gCjAwMDA0MDE5OTMgMDAwMDAgbiAKMDAwMDQwMjI3MSAwMDAwMCBuIAowMDAwNDAy ODgzIDAwMDAwIG4gCjAwMDA0MDMzMzMgMDAwMDAgbiAKMDAwMDQwNDExMiAwMDAwMCBuIAowMDAw NDA0NjE4IDAwMDAwIG4gCjAwMDA0MDQ5OTIgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMTMg L1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFsoe+/fyr0E4RFVXHLIJ7ya+b0pKHvv38q9BOER VVxyyCe8mvm9KV0KPj4Kc3RhcnR4cmVmCjQwNjkxMQolJUVPRgo= --_003_F5063677821E3B4F81ACFB7905573F24D625C2F1MX15Acorpemccom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Sat, 23 Feb 2013 14:27:21 GMT"; modification-date="Sat, 23 Feb 2013 14:27:21 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFp bGluZyBsaXN0DQpzYWNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhY20NCg== --_003_F5063677821E3B4F81ACFB7905573F24D625C2F1MX15Acorpemccom_-- From vesely@tana.it Sun Feb 24 05:56:46 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD321F8FF7; Sun, 24 Feb 2013 05:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQJJ8rU5rhXf; Sun, 24 Feb 2013 05:56:46 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A588221F8FEC; Sun, 24 Feb 2013 05:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1361714203; bh=VZw3M738BwZQh/SHY4AHA7G6ptV2LNHmaohutLVd80o=; l=768; h=Date:From:To:CC:References:In-Reply-To; b=eT59g/M2TeI0gZokgDbcK7TVuWpO9utCG9vRGYLL66uYs0GY0YKDGisYVFyC5HwRJ vK14cvAqWTpwROK7oT31Zr1Eusfiik9ZouFsfXsTru2/MEo2eKRRXWElRqZY4if02p ZN4qCscg6eb8qqRAnXdIhqzp3RxHtfQquWYQRPJ0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 24 Feb 2013 14:56:43 +0100 id 00000000005DC039.00000000512A1C1B.00002764 Message-ID: <512A1C1B.5060802@tana.it> Date: Sun, 24 Feb 2013 14:56:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: , In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Managed Incident Lightweight Exchange IODEF extensions and RID exchanges , "marf@ietf.org" Subject: Re: [mile] [marf] Including Mail fields in IODEF X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:56:46 -0000 Hi Kathleen, On Thu 21/Feb/2013 11:19:11 +0100 Moriarty, Kathleen wrote: > > Cross posting with MAIL and MARF - Hey, I never realized that meaning of pronouncing "mile", otherwise I wouldn't have unsubscribed :-) > There was a draft published last year (link included below) that > includes MARF in an IODEF extension. Yeah, that slavishly translated and ARF mail into XML. Its only practical trait is to represent header fields with a lowercase name, for example: QUALCOMM Windows Eudora That kind of thing can be useful to get a value quickly; that is, while parsing the XML. If the alternative is to extract the whole message (or header) and then parse that in turn, it might be worth to have it. From trammell@tik.ee.ethz.ch Mon Feb 25 09:53:22 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05621E805F for ; Mon, 25 Feb 2013 09:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT7jeHRaZQK7 for ; Mon, 25 Feb 2013 09:53:21 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C8DD521E8063 for ; Mon, 25 Feb 2013 09:53:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 30741D9308 for ; Mon, 25 Feb 2013 18:53:20 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xHZJ1Ar0-RKh for ; Mon, 25 Feb 2013 18:53:20 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 09A3CD9304 for ; Mon, 25 Feb 2013 18:53:20 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2013 18:53:19 +0100 Message-Id: To: "" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mile] DRAFT Agenda for IETF 86 Orlando X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:53:22 -0000 Greetings, all, The draft agenda for the MILE session at IETF 86 in Orlando has been = posted to: https://datatracker.ietf.org/meeting/86/agenda/mile/ Please direct comments or questions to mile-chairs@tools.ietf.org. Best regards, Brian=