From johnp.field@emc.com Thu Sep 6 08:11:22 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAAA21F86F9 for ; Thu, 6 Sep 2012 08:11:22 -0700 (PDT) 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 dw7BFu28Izgk for ; Thu, 6 Sep 2012 08:11:22 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E421F8720 for ; Thu, 6 Sep 2012 08:11:21 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q86FBKHY010380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 11:11:20 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 6 Sep 2012 11:10:57 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q86FAqC4018045 for ; Thu, 6 Sep 2012 11:10:56 -0400 Received: from mx14a.corp.emc.com ([169.254.1.151]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Thu, 6 Sep 2012 11:10:54 -0400 From: "Field, John" To: "sacm@ietf.org" Date: Thu, 6 Sep 2012 11:10:52 -0400 Thread-Topic: New draft for review and comment: draft-field-mile-rolie-00.txt Thread-Index: Ac2L0435yvJAa7AZSl2Jmq3LdSAuWgAaFVGwAADhXRA= 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: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:11:22 -0000 QWxsLA0KDQpDcm9zcyBwb3N0aW5nIHRoaXMgYW5ub3VuY2VtZW50IGZyb20gTUlMRSB0byBTQUNN LCBhcyBJIHRoaW5rIHRoaXMgbWF5IGJlIG9mIGludGVyZXN0IHdpdGhpbiB0aGUgU0NBUCBjb21t dW5pdHkgYXMgd2VsbC4gIA0KDQpUaGUgbmV3IGRyYWZ0IHJlZmVyZW5jZWQgYmVsb3cgZGVzY3Jp YmVzIGEgUkVTVGZ1bCBIVFRQIGJpbmRpbmcgZm9yIHNoYXJpbmcgaW5jaWRlbnQsIGluZGljYXRv ciwgYW5kIG90aGVyIGN5YmVyIHNlY3VyaXR5LXJlbGF0ZWQgaW5mb3JtYXRpb24uICBJbiBwYXJ0 aWN1bGFyLCB0aGUgZHJhZnQgaW5jbHVkZXMgYSBzdWdnZXN0ZWQgYXBwcm9hY2ggdG8gcmV0cmll dmluZyBhIHJlbGF0ZWQgYmVuY2htYXJrIHJlc291cmNlLiAgDQoNCkkgaG9wZSB5b3UnbGwgZmlu ZCB0aGlzIGRyYWZ0IHRvIGJlIG9mIGludGVyZXN0LiAgDQoNClBsZWFzZSBwb3N0IGFueSBxdWVz dGlvbnMgb3IgY29tbWVudHMgdG8gdGhlIE1JTEUgbGlzdC4NCg0KUmVnYXJkcywNCkpvaG4NCg0K Ly8gSm9obiBQLiBGaWVsZCANCi8vIFNlY3VyaXR5IEFyY2hpdGVjdCANCi8vIEVNQyBPZmZpY2Ug b2YgdGhlIENUTyANCg0KDQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEZpZWxkLCBKb2huIA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiAxMDo1MyBB TQ0KVG86IDxtaWxlQGlldGYub3JnPg0KU3ViamVjdDogTmV3IGRyYWZ0IGZvciByZXZpZXcgYW5k IGNvbW1lbnQ6IGRyYWZ0LWZpZWxkLW1pbGUtcm9saWUtMDAudHh0DQoNCkFsbCwNCg0KUGxlYXNl IG5vdGUgdGhhdCBJIGhhdmUganVzdCBwb3N0ZWQgYSBuZXcgZHJhZnQgZm9yIHJldmlldyBhbmQg Y29tbWVudC4gIEFzIHN0YXRlZCBpbiB0aGUgYWJzdHJhY3QsIHRoZSBkcmFmdCBkZXNjcmliZXMg YSBSRVNUZnVsIEhUVFAgYmluZGluZyBmb3Igc2hhcmluZyBpbmNpZGVudCwgaW5kaWNhdG9yLCBh bmQgb3RoZXIgY3liZXIgc2VjdXJpdHktcmVsYXRlZCBpbmZvcm1hdGlvbi4gIEkgaG9wZSB5b3Un bGwgZmluZCB0aGlzIGRvY3VtZW50IHRvIGJlIG9mIGludGVyZXN0LCBhbmQgSSBsb29rIGZvcndh cmQgdG8gZGlzY3Vzc2luZyBhbnkgcXVlc3Rpb25zIGFuZC9vciBjb21tZW50cyB0aGF0IHRoZSBn cm91cCBtYXkgaGF2ZS4NCg0KUmVnYXJkcywNCkpvaG4NCg0KLy8gSm9obiBQLiBGaWVsZCANCi8v IFNlY3VyaXR5IEFyY2hpdGVjdCANCi8vIEVNQyBPZmZpY2Ugb2YgdGhlIENUTyANCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt YmVyIDA1LCAyMDEyIDk6NTkgUE0NClRvOiBGaWVsZCwgSm9obg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maWVsZC1taWxlLXJvbGllLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1maWVsZC1taWxlLXJvbGllLTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIFAuIEZpZWxkIGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZmllbGQtbWlsZS1yb2xp ZQ0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUmVzb3VyY2UtT3JpZW50ZWQgTGlnaHR3ZWlnaHQg SW5kaWNhdG9yIEV4Y2hhbmdlDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wOS0wNQ0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQxDQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZpZWxkLW1pbGUt cm9saWUtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZmllbGQtbWlsZS1yb2xpZQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWVsZC1taWxlLXJvbGllLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSByZXNvdXJjZS1vcmllbnRlZCBhcHByb2FjaCB0 byBjeWJlciBzZWN1cml0eQ0KICAgaW5mb3JtYXRpb24gc2hhcmluZy4gIFVzaW5nIHRoaXMgYXBw cm9hY2gsIGEgQ1NJUlQgb3Igb3RoZXINCiAgIHN0YWtlaG9sZGVyIG1heSBzaGFyZSBhbmQgZXhj aGFuZ2UgcmVwcmVzZW50YXRpb25zIG9mIGN5YmVyIHNlY3VyaXR5DQogICBpbmNpZGVudHMsIGlu ZGljYXRvcnMsIGFuZCBvdGhlciByZWxhdGVkIGluZm9ybWF0aW9uIGFzIFdlYi0NCiAgIGFkZHJl c3NhYmxlIHJlc291cmNlcy4gIFRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgYmluZGluZyBpcyBzcGVj aWZpZWQNCiAgIGFzIEhUVFAoUykgd2l0aCBhIE1JTUUgbWVkaWEgdHlwZSBvZiBBdG9tK1hNTC4g IEFuIGFwcHJvcHJpYXRlIHNldCBvZg0KICAgbGluayByZWxhdGlvbiB0eXBlcyBzcGVjaWZpYyB0 byBjeWJlciBzZWN1cml0eSBpbmZvcm1hdGlvbiBzaGFyaW5nIGlzDQogICBkZWZpbmVkLiAgVGhl IHJlc291cmNlIHJlcHJlc2VudGF0aW9ucyBsZXZlcmFnZSB0aGUgZXhpc3RpbmcgSU9ERUYNCiAg IFtSRkM1MDcwXSBhbmQgUklEIFtSRkM2NTQ1XSBzcGVjaWZpY2F0aW9ucyBhcyBhcHByb3ByaWF0 ZS4NCiAgIENvZXhpc3RlbmNlIHdpdGggZGVwbG95bWVudHMgdGhhdCBjb25mb3JtIHRvIGV4aXN0 aW5nIHNwZWNpZmljYXRpb25zDQogICBpbmNsdWRpbmcgUklEIFtSRkM2NTQ1XSBhbmQgVHJhbnNw b3J0IG9mIFJlYWwtdGltZSBJbnRlci1uZXR3b3JrDQogICBEZWZlbnNlIChSSUQpIE1lc3NhZ2Vz IG92ZXIgSFRUUC9UTFMgW1JGQzY1NDZdIGlzIHN1cHBvcnRlZCB2aWENCiAgIGFwcHJvcHJpYXRl IHVzZSBvZiBIVFRQIHN0YXR1cyBjb2Rlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From lnunez@c3isecurity.com Thu Sep 6 08:36:32 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC32321F872A for ; Thu, 6 Sep 2012 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 uYgZlNYezNqP for ; Thu, 6 Sep 2012 08:36:32 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id DE32121F8722 for ; Thu, 6 Sep 2012 08:36:31 -0700 (PDT) Received: by yhfs35 with SMTP id s35so448598yhf.27 for ; Thu, 06 Sep 2012 08:36:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=euOO+15EX0mwU1wRvT4S+DJNuQ2exV9g9uJUSputhhg=; b=ZmWA2bwavQVCg4CKFe8LJmY5vMKdZ2gWI5FtwQnBdjfh7hboFodm6+KU8pReZsv/MN x/qjjd20ILj6X56D45OnnOyKRO/C8IfDKMbaN2Ooae8+D+IS8Z64O0LgmXdcxxeCTHrw f4YExyxvpxGYxao0GSaAkXQQjzwsA8HMgfnaVra+YzOALQuq0oyCi0witPE1AuYGvVEx +K9L+j37HO2hmXGONRNtI/dD+K9bEdN8VB6tfcMOd2ROhtY50lC8ZV4gCx2FEHtF313s AWMy5wQPmwiv74Ep3jL1cZlxn76tEqRL9jQR0l5sMeI9qupkELwmdhGtHqkFHbk4/igt TBDA== Received: by 10.236.197.5 with SMTP id s5mr2107493yhn.114.1346945791200; Thu, 06 Sep 2012 08:36:31 -0700 (PDT) Received: from [192.168.1.25] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id d66sm4335731yhe.1.2012.09.06.08.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 08:36:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Thu, 6 Sep 2012 11:36:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Field, John" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk1JyE8vE+VFUAugy7pLVBTHqhTbkLi4METjeYAWfZg/yCd1GpGm06SiGhEV71YhNdY+j6z Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:36:32 -0000 John, this definitely is of interest and could be related to past discussions = around content repositories. =20 I know of two publicly accessible (REST) repositories that could = potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out = issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, >=20 > Cross posting this announcement from MILE to SACM, as I think this may = be of interest within the SCAP community as well. =20 >=20 > The new draft referenced below describes a RESTful HTTP binding for = sharing incident, indicator, and other cyber security-related = information. In particular, the draft includes a suggested approach to = retrieving a related benchmark resource. =20 >=20 > I hope you'll find this draft to be of interest. =20 >=20 > Please post any questions or comments to the MILE list. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Field, John=20 > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: = draft-field-mile-rolie-00.txt >=20 > All, >=20 > Please note that I have just posted a new draft for review and = comment. As stated in the abstract, the draft describes a RESTful HTTP = binding for sharing incident, indicator, and other cyber = security-related information. I hope you'll find this document to be of = interest, and I look forward to discussing any questions and/or comments = that the group may have. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt >=20 >=20 > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. >=20 > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator = Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: = http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: = http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >=20 >=20 > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set = of > link relation types specific to cyber security information sharing = is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri Sep 7 12:52:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91D121F86BD for ; Fri, 7 Sep 2012 12:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvyvuv6zge0w for ; Fri, 7 Sep 2012 12:52:36 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2B53521F86C4 for ; Fri, 7 Sep 2012 12:52:36 -0700 (PDT) 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.1.379.0; Fri, 7 Sep 2012 15:52:26 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 7 Sep 2012 15:52:35 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Fri, 7 Sep 2012 15:52:34 -0400 Thread-Topic: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: Ac2NMb6bWaFSnpf1Sm6ZVfNB3r5xvgAADieQ 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 Cc: Adam Montville Subject: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:52:37 -0000 SSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVkIHVzZSBjYXNlcyBkb2N1bWVudCAoc2VlIGJlbG93KSB0 aGF0IHJlZHVjZXMgdGhlIHNjb3BlIHRvIFVDMS0zIGFuZCBhZGRzIGEgbG90IG9mIG5ldyBjb250 ZW50LiAgTWFueSB0aGFua3MgdG8gQWRhbSBNb250dmlsbGUgZm9yIGFsbCBoaXMgaGFyZCB3b3Jr IG9uIHRoaXMgcmV2aXNpb24uDQoNCkNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KU2luY2Vy ZWx5LA0KRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6 IEZyaWRheSwgU2VwdGVtYmVyIDA3LCAyMDEyIDM6NDkgUE0NClRvOiBXYWx0ZXJtaXJlLCBEYXZp ZCBBLg0KQ2M6IGFtb250dmlsbGVAdHJpcHdpcmUuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMt MDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIFdhbHRlcm1p cmUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIEFuYWx5 c2lzIG9mIFNlY3VyaXR5IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyAoU0FD TSkgVXNlIENhc2VzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wOS0wNw0KV0cgSUQ6CQkgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIzDQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11 c2UtY2FzZXMtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcw0KSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNh c2VzLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDINCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGlkZW50aWZpZXMgZm91bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBmdW5j dGlvbmFsDQogICBjYXBhYmlsaXRpZXMgYW5kIHJlcXVpcmVtZW50cywgYXJjaGl0ZWN0dXJhbCBj b21wb25lbnRzLCBhbmQgdGhlDQogICBzdXBwb3J0aW5nIHN0YW5kYXJkcyBuZWVkZWQgdG8gZGVm aW5lIGFuIGludGVyb3BlcmFibGUsDQogICBhdXRvbWF0aW9uXGluZnJhc3RydWN0dXJlIHJlcXVp cmVkIHRvIHN1cHBvcnQgdGltZWx5LCBhY2N1cmF0ZSBhbmQNCiAgIGFjdGlvbmFibGUgc2l0dWF0 aW9uYWwgYXdhcmVuZXNzIG92ZXIgYW4gb3JnYW5pemF0aW9uJ3MgSVQgc3lzdGVtcy4NCiAgIEF1 dG9tYXRpb24gdG9vbHMgaW1wbGVtZW50aW5nIGEgY29udGludW91cyBtb25pdG9yaW5nIGFwcHJv YWNoIHdpbGwNCiAgIHV0aWxpemUgdGhpcyBpbmZyYXN0cnVjdHVyZSB0b2dldGhlciB3aXRoIGV4 aXN0aW5nIGFuZCBlbWVyZ2luZw0KICAgZXZlbnQsIGluY2lkZW50IGFuZCBuZXR3b3JrIG1hbmFn ZW1lbnQgc3RhbmRhcmRzIHRvIHByb3ZpZGUNCiAgIHZpc2liaWxpdHkgaW50byB0aGUgc3RhdGUg b2YgYXNzZXRzLCB1c2VyIGFjdGl2aXRpZXMgYW5kIG5ldHdvcmsNCiAgIFxiZWhhdmlvci4gIFN0 YWtlaG9sZGVycyB3aWxsIGJlIGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZQ0K ICAgYW5kIGFuYWx5emUgcmVsZXZhbnQgc2VjdXJpdHkgYW5kIG9wZXJhdGlvbmFsIGRhdGEgdG8g dW5kZXJzdGFuZCB0aGUNCiAgIG9yZ2FuaXphdGlvbnMgc2VjdXJpdHkgcG9zdHVyZSwgcXVhbnRp ZnkgYnVzaW5lc3MgcmlzaywgYW5kIG1ha2UNCiAgIGluZm9ybWVkIGRlY2lzaW9ucyB0aGF0IHN1 cHBvcnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGlsZQ0KICAgcHJvdGVjdGluZyBjcml0 aWNhbCBpbmZvcm1hdGlvbi4gIE9yZ2FuaXphdGlvbnMgd2lsbCBiZSBhYmxlIHRvIHVzZQ0KICAg dGhlc2UgdG9vbHMgdG8gYXVnbWVudCBhbmQgYXV0b21hdGUgaW5mb3JtYXRpb24gc2hhcmluZyBh Y3Rpdml0aWVzIHRvDQogICBjb2xsYWJvcmF0ZSB3aXRoIHBhcnRuZXJzIHRvIGlkZW50aWZ5IGFu ZCBtaXRpZ2F0ZSB0aHJlYXRzLiAgT3RoZXINCiAgIGF1dG9tYXRpb24gdG9vbHMgd2lsbCBiZSBh YmxlIHRvIGludGVncmF0ZSB3aXRoIHRoZXNlIGNhcGFiaWxpdGllcyB0bw0KICAgZW5mb3JjZSBw b2xpY2llcyBiYXNlZCBvbiBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVuIHN5c3RlbXMsIHByZXZl bnQNCiAgIG1pc3VzZSBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFjayBzdXJmYWNlLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From david.oliva@verizon.net Mon Sep 10 06:42:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2B521F8681 for ; Mon, 10 Sep 2012 06:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNlETerwcLHg for ; Mon, 10 Sep 2012 06:42:18 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28B21F84DF for ; Mon, 10 Sep 2012 06:42:17 -0700 (PDT) Received: from vznit170136pub.verizon.net ([unknown] [192.168.1.3]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MA400A40ZE1Q3E0@vms173005.mailsrvcs.net> for sacm@ietf.org; Mon, 10 Sep 2012 08:42:02 -0500 (CDT) Received: from 96.241.166.234 ([96.241.166.234]) by vznit170136 (Verizon Webmail) with HTTP; Mon, 10 Sep 2012 08:42:01 -0500 (CDT) Date: Mon, 10 Sep 2012 08:42:01 -0500 (CDT) From: david.oliva@verizon.net To: david.waltermire@nist.gov, sacm@ietf.org Message-id: <110204.2574544.1347284521924.JavaMail.root@vznit170136> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.241.166.234] Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:42:18 -0000

To all:

 

The document appears very good to me.<= /FONT>

<= FONT size=3D3 face=3DCalibri> 

Comments:<= o:p>

3.3.1.  Goal =E2=80=9C   Continuous assessment of= the implementation and effectiveness of

   security controls ba= sed on machine processable content.=E2=80=9D  PHENOMENAL!

 =

 

Paragraph= 9. Acknowledgementss:  Mispe= lled word =E2=80=9Cthier=E2=80=9D change to =E2=80=9Ctheir=E2=80=9D.

 

 

Suggestions:

 

The mature = state of automation makes it worthwhile to introduce new associated terms t= o address future situations.

 =

Automatable (adverb):  The condition of a process that can be implemented= with security automation mechanisms.&nbs= p; For instance, =E2=80=9Cconfiguration compliance is an automatable= process=E2=80=9D

 

Non-automatable (adverb):  The condition of a process that cannot be implemented wit= h security automation mechanisms.  <= /SPAN>For instance, =E2=80=9Cconflicting =  policy resolution is a non-automatable process=E2=80=9D.<= /o:p>

 

Sem= i-automatable (adverb):  The = condition of a process which can be partially implemented or supported with= security automation mechanisms.  For example =E2=80=9CSome semi-automatable processes can be supported = with SCAM specifications such as the Open Checklist Interactive Language (O= CIL)=E2=80=9D.

 

A few questions come to mind (perhaps due to my lack of familiar= ity with the modus operandi of the IETF).

1.       What happens with the document at the end of= March 2013?

2.  &nbs= p;    Where does the model in Figure 1 come from?

=

3.       Why are only other RFCs acceptable ref= erences?

4.   &nb= sp;   Wh= y are acronyms without definitions used (ORM, IRM)?

David Oliva

 
=  
 
On 09/07/12, Waltermire, David A.<david.waltermire@= nist.gov> wrote:
 
I just posted an updated use case= s document (see below) that reduces the scope to UC1-3 and adds a lot of ne= w content. Many thanks to Adam Montville for all his hard work on this revi= sion.

Comments are appreciated.

Sincerely,
Dave

---= --Original Message-----
From: internet-drafts@ietf.org [mai= lto:internet-drafts@ietf.org]
Sent: Friday, September 07, 2012 3:49= PM
To: Waltermire, David A.
Cc: amontville@tripwire.com
S= ubject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt=


A new version of I-D, draft-waltermire-sacm-use-cases-02.txthas been successfully submitted by David Waltermire and posted to the IETF= repository.

Filename: draft-waltermire-sacm-use-cases
Revision: = 02
Title: Analysis of Security Automation and Continuous Monitoring (SAC= M) Use Cases
Creation date: 2012-09-07
WG ID: Individual SubmissionNumber of pages: 23
URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-02.tx= t
Status: http://datatracker.iet= f.org/doc/draft-waltermire-sacm-use-cases
Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-use-case= s-02
Diff: http://www.ietf= .org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-02

Abstract:=
This document identifies foundational use cases, derived functional
= capabilities and requirements, architectural components, and the
support= ing standards needed to define an interoperable,
automation\infrastructu= re required to support timely, accurate and
actionable situational aware= ness over an organization's IT systems.
Automation tools implementing a = continuous monitoring approach will
utilize this infrastructure together= with existing and emerging
event, incident and network management stand= ards to provide
visibility into the state of assets, user activities and= network
\behavior. Stakeholders will be able to use these tools to aggr= egate
and analyze relevant security and operational data to understand t= he
organizations security posture, quantify business risk, and make
i= nformed decisions that support organizational objectives while
protectin= g critical information. Organizations will be able to use
these tools to= augment and automate information sharing activities to
collaborate with= partners to identify and mitigate threats. Other
automation tools will = be able to integrate with these capabilities to
enforce policies based o= n human decisions to harden systems, prevent
misuse and reduce the overa= ll attack surface.




The IETF Secretariat

_________= ______________________________________
sacm mailing list
sacm@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/sacm
<= /div> From amontville@tripwire.com Mon Sep 10 06:58:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612BA21F85E7 for ; Mon, 10 Sep 2012 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 mUGtTKdrurbi for ; Mon, 10 Sep 2012 06:58:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4D11721F8593 for ; Mon, 10 Sep 2012 06:58:40 -0700 (PDT) Received: from mail30-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 13:58:39 +0000 Received: from mail30-va3 (localhost [127.0.0.1]) by mail30-va3-R.bigfish.com (Postfix) with ESMTP id 371263200E2 for ; Mon, 10 Sep 2012 13:58:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371I936eI103dKc85eh542M1a09Jzz1202h1d1ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5hbe3k1155h) Received: from mail30-va3 (localhost.localdomain [127.0.0.1]) by mail30-va3 (MessageSwitch) id 1347285515621136_19423; Mon, 10 Sep 2012 13:58:35 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.251]) by mail30-va3.bigfish.com (Postfix) with ESMTP id 880E9300049 for ; Mon, 10 Sep 2012 13:58:35 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 13:58:34 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id E88CD232122A for ; Mon, 10 Sep 2012 06:54:56 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 380BC232121B; Mon, 10 Sep 2012 06:54:56 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 10 Sep 2012 07:00:48 -0700 Received: from PDXMB03.tripwire.com ([fe80::284f:fde0:d82f:4223]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 10 Sep 2012 06:58:31 -0700 From: Adam Montville To: "david.oliva@verizon.net" , "david.waltermire@nist.gov" , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: AQHNj1oq8aMEV8nqh0SKhkV1wNdDKZeDmgiA Date: Mon, 10 Sep 2012 13:58:30 +0000 Message-ID: In-Reply-To: <110204.2574544.1347284521924.JavaMail.root@vznit170136> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC733CFE10A6Damontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 6f78cb4e-463f-4d05-90f0-697ff13593ba X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:58:42 -0000 --_000_CC733CFE10A6Damontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable David, Thank you for the comments! I made most of these changes to the document s= o far, so I think I can address many of your questions =96 inline. Regards, Adam From: "david.oliva@verizon.net" > Date: Monday, September 10, 2012 6:42 AM To: "david.waltermire@nist.gov" >, "sacm@ietf.org" > Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-= use-cases-02.txt To all: The document appears very good to me. Thanks! Comments: 3.3.1. Goal =93 Continuous assessment of the implementation and effectiv= eness of security controls based on machine processable content.=94 PHENOMENAL! Paragraph 9. Acknowledgementss: Mispelled word =93thier=94 change to =93th= eir=94. Good catch, thank you. I need to run a spell-check ;-) Suggestions: So, these are suggestions for the (presently incomplete) terms and definiti= ons section. Excellent! I might suggest some rewording. The mature state of automation makes it worthwhile to introduce new associa= ted terms to address future situations. Automatable (adverb): The condition of a process that can be implemented w= ith security automation mechanisms. For instance, =93configuration complia= nce is an automatable process=94 I'm not sure I understand the choice of the word "condition" in this contex= t (this comment applies to the following suggestions as well). Would "step= s" be more appropriate? Also, I might argue in favor of removing "security= " from the definition. In our context we're looking at security automation= mechanisms, but the term "automatable" is applicable beyond our domain =96= in fact, this term is already defined abstractly as "to make automatic." Non-automatable (adverb): The condition of a process that cannot be implem= ented with security automation mechanisms. For instance, =93conflicting p= olicy resolution is a non-automatable process=94. Semi-automatable (adverb): The condition of a process which can be partial= ly implemented or supported with security automation mechanisms. For examp= le =93Some semi-automatable processes can be supported with SCAM specificat= ions such as the Open Checklist Interactive Language (OCIL)=94. Also, because "security automation" is used, we'll want to define that as w= ell. I'm not sure that it has been defined anywhere at this point. Any su= ggestions? A few questions come to mind (perhaps due to my lack of familiarity with th= e modus operandi of the IETF). 1. What happens with the document at the end of March 2013? I don't know. One of the more experienced IETFers needs to answer that que= stion. I imagine that we can update or, perhaps, resubmit this document, o= r let it be, as it's informational. 2. Where does the model in Figure 1 come from? This is my doing and it comes from no official source. It does, however, r= epresent a useful perspective for SACM and other security automation effort= s. 3. Why are only other RFCs acceptable references? I don't know that only RFCs are acceptable. We should be able to reference= anything, but only certain sources would be considered normative rather th= an informative. 4. Why are acronyms without definitions used (ORM, IRM)? My mistake. They are abbreviations of Operational Risk Management and Info= rmation Risk Management respectively, which are introduced in Figure 1. I = can either update the figure or spell it out in the prose of the document, = or both. David Oliva On 09/07/12, Waltermire, David A.> wrote: I just posted an updated use cases document (see below) that reduces the sc= ope to UC1-3 and adds a lot of new content. Many thanks to Adam Montville f= or all his hard work on this revision. Comments are appreciated. Sincerely, Dave -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Friday, September 07, 2012 3:49 PM To: Waltermire, David A. Cc: amontville@tripwire.com Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.tx= t A new version of I-D, draft-waltermire-sacm-use-cases-02.txt has been successfully submitted by David Waltermire and posted to the IETF = repository. Filename: draft-waltermire-sacm-use-cases Revision: 02 Title: Analysis of Security Automation and Continuous Monitoring (SACM) Use= Cases Creation date: 2012-09-07 WG ID: Individual Submission Number of pages: 23 URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-02= .txt Status: http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-02 Abstract: This document identifies foundational use cases, derived functional capabilities and requirements, architectural components, and the supporting standards needed to define an interoperable, automation\infrastructure required to support timely, accurate and actionable situational awareness over an organization's IT systems. Automation tools implementing a continuous monitoring approach will utilize this infrastructure together with existing and emerging event, incident and network management standards to provide visibility into the state of assets, user activities and network \behavior. Stakeholders will be able to use these tools to aggregate and analyze relevant security and operational data to understand the organizations security posture, quantify business risk, and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use these tools to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. The IETF Secretariat _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC733CFE10A6Damontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8FFBA0C0698BAD45B36D6811F0D75796@tripwire.com> Content-Transfer-Encoding: quoted-printable
David, 

Thank you for the comments!  I made most of these changes to the = document so far, so I think I can address many of your questions =96 inline= .

Regards,

Adam

From: "david.oliva@verizon.net" <david.oliva@verizon.net>
Date: Monday, September 10, 2012 6:= 42 AM
To: "david.waltermire@nist.gov" <david.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] FW: New Version= Notification for draft-waltermire-sacm-use-cases-02.txt

To all:

 

The document appears very good to me.

Thanks!

 

Comments:

3.3.1.&= nbsp; Goal =93   Continuous assessment of the implementation and effectiveness of

   security controls based on machine processable content.=94  PHENOMENAL!

 

 

Paragraph 9. = Acknowledgementss:  Mispelled word =93thier=94 change to =93their=94.


Good catch, thank you.  I need to run a spell-check ;-)


&= nbsp;

 

Suggestions:<= /span>

So, these are suggestions for the (presently incomplete) terms and def= initions section.  Excellent!  I might suggest some rewording.


 

The mature st= ate of automation makes it worthwhile to introduce new associated terms to = address future situations.

 

Automatable (= adverb):  The condition of a process that can be implemented with security aut= omation mechanisms.  For instance, =93configuration compliance is an automatable process= =94

I'm not sure I understand the choice of the word "condition"= in this context (this comment applies to the following suggestions as well= ).  Would "steps" be more appropriate?  Also, I might a= rgue in favor of removing "security" from the definition.  I= n our context we're looking at security automation mechanisms, but the term = "automatable" is applicable beyond our domain =96 in fact, this t= erm is already defined abstractly as "to make automatic."  <= /div>


 

Non-automatab= le (adverb):  The condition of a process that cannot be implemented with security = automation mechanisms.  For instance, =93conflicting  = ;policy resolution is a non-automatable process=94.

 

Semi-automata= ble (adverb):  The condition of a process which can be partially implemented or sup= ported with security automation mechanisms.

 

A few questions come to mind (perhaps due to my lack of = familiarity with the modus operandi of the IETF).<= /p>

1.<= /font>


2.<= /font>


4.<= /font> Automation tools implementing a continuous monitoring approach will
utilize this infrastructure together with existing and emerging
event, incident and network management standards to provide
visibility into the state of assets, user activities and network
\behavior. Stakeholders will be able to use these tools to aggregate
and analyze relevant security and operational data to understand the
organizations security posture, quantify business risk, and make
informed decisions that support organizational objectives while
protecting critical information. Organizations will be able to use
these tools to augment and automate information sharing activities to
collaborate with partners to identify and mitigate threats. Other
automation tools will be able to integrate with these capabilities to
enforce policies based on human decisions to harden systems, prevent
misuse and reduce the overall attack surface.




The IETF Secretariat

_______________________________________________
sacm mailing list
sa= cm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


--_000_CC733CFE10A6Damontvilletripwirecom_-- From kathleen.moriarty@emc.com Mon Sep 10 07:02:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DFE21F86EC for ; Mon, 10 Sep 2012 07:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHB7WC4597PA for ; Mon, 10 Sep 2012 07:02:23 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 12D1821F86EF for ; Mon, 10 Sep 2012 07:02:22 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8AE2Ldw001619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 10:02:22 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 10 Sep 2012 10:02:10 -0400 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 q8AE2AH1010009; Mon, 10 Sep 2012 10:02:10 -0400 Received: from mx15a.corp.emc.com ([169.254.2.46]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Mon, 10 Sep 2012 10:02:10 -0400 From: "Moriarty, Kathleen" To: "david.oliva@verizon.net" Date: Mon, 10 Sep 2012 10:01:59 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: Ac2PXN2j1hF5lhFBT9WF9pU/biZWuA== Message-ID: References: <110204.2574544.1347284521924.JavaMail.root@vznit170136> In-Reply-To: <110204.2574544.1347284521924.JavaMail.root@vznit170136> 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_D28C611D52FB4AC79FE4826E33303ACFemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "david.waltermire@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:02:24 -0000 --_000_D28C611D52FB4AC79FE4826E33303ACFemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCkdyZWF0IHF1ZXN0aW9ucyAmIHRoYW5rcyBmb3IgdGhlIHJldmlldyEgIEkn bGwgc3RhcnQgd2l0aCAjNCwgYnV0IGFtIGxpbWl0ZWQgdG8gYW4gaVBob25lIGF0IHRoZSBtb21l bnQuDQoNClN0YW5kYXJkcyBkZXZlbG9wbWVudCBvcmdhbml6YXRpb25zIChTRE9zKSBoYXZlIHJl cXVpcmVtZW50cyB0byBlbnN1cmUgdGhlIHN0YWJpbGl0eSBvZiBkb2N1bWVudHMgZm9yICJub3Jt YXRpdmUgcmVmZXJlbmNlcyIuICBPdGhlciBTRE9zIGFyZSB2YWxpZCBsb2NhdGlvbnMgZm9yIG5v cm1hdGl2ZSByZWZlcmVuY2VzIGFzIHRoZSByZWZlcmVuY2UgaXMgdG8gYSBkb2N1bWVudCBhcyBv cHBvc2VkIHRvIGEgbGluay4gIEEgbGluayBjYW4gY2hhbmdlL2Rpc2FwcGVhciwgdGhlIGNvbnRl bnQgY2FuIGNoYW5nZSwgYW5kIHRoZXJlZm9yZSB0aGUgZG9jdW1lbnQgbWF5IG5vdCBiZSBzdGFi bGUuDQoNClRoZSBuZXh0IHNldCBvZiBpc3N1ZXMgYXJlIGFyb3VuZCBJUC4gIElmIHRoZSBkb2N1 bWVudCBpcyBhdCBhbiBTRE8sIHRoZSBJUCBpcyBjbGVhciBldmVuIGlmIHRoZXJlIHdlcmUgSVAg ZGlzY2xvc3VyZXMgc3VibWl0dGVkIGZvciB0aGF0IGRvY3VtZW50Lg0KDQpJZiBhIGRvY3VtZW50 IGlzIGhvc3RlZCBieSBhIHZlbmRvciwgZXZlbiBpZiB0aGF0IGRvY3VtZW50IGlzIG9wZW4sIGFk b3B0aW9uIHdvdWxkIGluY3JlYXNlIG9mIHNvbWV0aGluZyB0aGF0IGNhbiBiZSBzaGFyZWQgaWYg aXQgaXMgYXQgYW4gU0RPLiAgVGhlIHN1Ym1pdHRlZCBzdGlsbCBzaG93cyB0aGUgdGhvdWdodCBs ZWFkZXJzaGlwIHdpdGggdGhlIGNvbnRyaWJ1dGlvbiBhbmQgb3RoZXIgdmVuZG9ycyBjYW4gc2l0 ZSBjb21wbGlhbmNlIHRvIGEgc3RhbmRhcmRzIGRvY3VtZW50IGFzIG9wcG9zZWQgdG8gc29tZXRo aW5nIGZyb20gYW5vdGhlciB2ZW5kb3IuDQoNCkV4YW1wbGVzIG9mIG90aGVyIFNET3MgaW5jbHVk ZSBJU08sIElFRUUsIFczQywgSVRVLCBPQVNJUywgZXRjLiAgV2hpbGUgTklTVCBpcyBub3QgYW4g U0RPIGluIHRoZSBzYW1lIHNlbnNlLCB0aGVpciBkb2N1bWVudHMgYXJlIGFjY2VwdGVkIGFzIHZh bGlkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGZyb20gbWlzdCBvZiB0aGUgU0RPcy4NCg0KU3RldmUg SGFubmEgb3Igb3RoZXJzIC0gZG8geW91IGhhdmUgYW55IG90aGVyIHJlYXNvbnMgdG8gYWRkPw0K DQpJIGhvcGUgdGhpcyBpcyBoZWxwZnVsIQ0KS2F0aGxlZW4NCg0KU2VudCBmcm9tIG15IGlQaG9u ZQ0KDQpPbiBTZXAgMTAsIDIwMTIsIGF0IDk6NDUgQU0sICJkYXZpZC5vbGl2YUB2ZXJpem9uLm5l dDxtYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+IiA8ZGF2aWQub2xpdmFAdmVyaXpvbi5u ZXQ8bWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0Pj4gd3JvdGU6DQoNClRvIGFsbDoNCg0K VGhlIGRvY3VtZW50IGFwcGVhcnMgdmVyeSBnb29kIHRvIG1lLg0KDQpDb21tZW50czoNCjMuMy4x LiAgR29hbCDigJwgICBDb250aW51b3VzIGFzc2Vzc21lbnQgb2YgdGhlIGltcGxlbWVudGF0aW9u IGFuZCBlZmZlY3RpdmVuZXNzIG9mDQogICBzZWN1cml0eSBjb250cm9scyBiYXNlZCBvbiBtYWNo aW5lIHByb2Nlc3NhYmxlIGNvbnRlbnQu4oCdICBQSEVOT01FTkFMIQ0KDQoNClBhcmFncmFwaCA5 LiBBY2tub3dsZWRnZW1lbnRzczogIE1pc3BlbGxlZCB3b3JkIOKAnHRoaWVy4oCdIGNoYW5nZSB0 byDigJx0aGVpcuKAnS4NCg0KDQpTdWdnZXN0aW9uczoNCg0KVGhlIG1hdHVyZSBzdGF0ZSBvZiBh dXRvbWF0aW9uIG1ha2VzIGl0IHdvcnRod2hpbGUgdG8gaW50cm9kdWNlIG5ldyBhc3NvY2lhdGVk IHRlcm1zIHRvIGFkZHJlc3MgZnV0dXJlIHNpdHVhdGlvbnMuDQoNCkF1dG9tYXRhYmxlIChhZHZl cmIpOiAgVGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nlc3MgdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQg d2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuICBGb3IgaW5zdGFuY2UsIOKAnGNv bmZpZ3VyYXRpb24gY29tcGxpYW5jZSBpcyBhbiBhdXRvbWF0YWJsZSBwcm9jZXNz4oCdDQoNCk5v bi1hdXRvbWF0YWJsZSAoYWR2ZXJiKTogIFRoZSBjb25kaXRpb24gb2YgYSBwcm9jZXNzIHRoYXQg Y2Fubm90IGJlIGltcGxlbWVudGVkIHdpdGggc2VjdXJpdHkgYXV0b21hdGlvbiBtZWNoYW5pc21z LiAgRm9yIGluc3RhbmNlLCDigJxjb25mbGljdGluZyAgcG9saWN5IHJlc29sdXRpb24gaXMgYSBu b24tYXV0b21hdGFibGUgcHJvY2Vzc+KAnS4NCg0KU2VtaS1hdXRvbWF0YWJsZSAoYWR2ZXJiKTog IFRoZSBjb25kaXRpb24gb2YgYSBwcm9jZXNzIHdoaWNoIGNhbiBiZSBwYXJ0aWFsbHkgaW1wbGVt ZW50ZWQgb3Igc3VwcG9ydGVkIHdpdGggc2VjdXJpdHkgYXV0b21hdGlvbiBtZWNoYW5pc21zLiAg Rm9yIGV4YW1wbGUg4oCcU29tZSBzZW1pLWF1dG9tYXRhYmxlIHByb2Nlc3NlcyBjYW4gYmUgc3Vw cG9ydGVkIHdpdGggU0NBTSBzcGVjaWZpY2F0aW9ucyBzdWNoIGFzIHRoZSBPcGVuIENoZWNrbGlz dCBJbnRlcmFjdGl2ZSBMYW5ndWFnZSAoT0NJTCnigJ0uDQoNCkEgZmV3IHF1ZXN0aW9ucyBjb21l IHRvIG1pbmQgKHBlcmhhcHMgZHVlIHRvIG15IGxhY2sgb2YgZmFtaWxpYXJpdHkgd2l0aCB0aGUg bW9kdXMgb3BlcmFuZGkgb2YgdGhlIElFVEYpLg0KDQoxLiAgICAgICBXaGF0IGhhcHBlbnMgd2l0 aCB0aGUgZG9jdW1lbnQgYXQgdGhlIGVuZCBvZiBNYXJjaCAyMDEzPw0KDQoyLiAgICAgICBXaGVy ZSBkb2VzIHRoZSBtb2RlbCBpbiBGaWd1cmUgMSBjb21lIGZyb20/DQoNCjMuICAgICAgIFdoeSBh cmUgb25seSBvdGhlciBSRkNzIGFjY2VwdGFibGUgcmVmZXJlbmNlcz8NCg0KNC4gICAgICAgV2h5 IGFyZSBhY3JvbnltcyB3aXRob3V0IGRlZmluaXRpb25zIHVzZWQgKE9STSwgSVJNKT8NCkRhdmlk IE9saXZhDQoNCg0KDQpPbiAwOS8wNy8xMiwgV2FsdGVybWlyZSwgRGF2aWQgQS48ZGF2aWQud2Fs dGVybWlyZUBuaXN0LmdvdjxtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4+IHdyb3Rl Og0KDQpJIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQgdXNlIGNhc2VzIGRvY3VtZW50IChzZWUgYmVs b3cpIHRoYXQgcmVkdWNlcyB0aGUgc2NvcGUgdG8gVUMxLTMgYW5kIGFkZHMgYSBsb3Qgb2YgbmV3 IGNvbnRlbnQuIE1hbnkgdGhhbmtzIHRvIEFkYW0gTW9udHZpbGxlIGZvciBhbGwgaGlzIGhhcmQg d29yayBvbiB0aGlzIHJldmlzaW9uLg0KDQpDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNClNp bmNlcmVseSwNCkRhdmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gWzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPm1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBGcmlkYXksIFNl cHRlbWJlciAwNywgMjAxMiAzOjQ5IFBNDQpUbzogV2FsdGVybWlyZSwgRGF2aWQgQS4NCkNjOiA8 bWFpbHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tPiBhbW9udHZpbGxlQHRyaXB3aXJlLmNvbTxt YWlsdG86YW1vbnR2aWxsZUB0cmlwd2lyZS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIFdhbHRlcm1pcmUg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogZHJhZnQtd2Fs dGVybWlyZS1zYWNtLXVzZS1jYXNlcw0KUmV2aXNpb246IDAyDQpUaXRsZTogQW5hbHlzaXMgb2Yg U2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGludW91cyBNb25pdG9yaW5nIChTQUNNKSBVc2Ug Q2FzZXMNCkNyZWF0aW9uIGRhdGU6IDIwMTItMDktMDcNCldHIElEOiBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogMjMNClVSTDogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIudHh0PiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNl LWNhc2VzLTAyLnR4dA0KU3RhdHVzOiA8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMNCkh0bWxpemVkOiA8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0wMj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNl cy0wMg0KRGlmZjogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXdhbHRl cm1pcmUtc2FjbS11c2UtY2FzZXMtMDI+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDINCg0KQWJzdHJhY3Q6DQpUaGlzIGRv Y3VtZW50IGlkZW50aWZpZXMgZm91bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBmdW5jdGlv bmFsDQpjYXBhYmlsaXRpZXMgYW5kIHJlcXVpcmVtZW50cywgYXJjaGl0ZWN0dXJhbCBjb21wb25l bnRzLCBhbmQgdGhlDQpzdXBwb3J0aW5nIHN0YW5kYXJkcyBuZWVkZWQgdG8gZGVmaW5lIGFuIGlu dGVyb3BlcmFibGUsDQphdXRvbWF0aW9uXGluZnJhc3RydWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBv cnQgdGltZWx5LCBhY2N1cmF0ZSBhbmQNCmFjdGlvbmFibGUgc2l0dWF0aW9uYWwgYXdhcmVuZXNz IG92ZXIgYW4gb3JnYW5pemF0aW9uJ3MgSVQgc3lzdGVtcy4NCkF1dG9tYXRpb24gdG9vbHMgaW1w bGVtZW50aW5nIGEgY29udGludW91cyBtb25pdG9yaW5nIGFwcHJvYWNoIHdpbGwNCnV0aWxpemUg dGhpcyBpbmZyYXN0cnVjdHVyZSB0b2dldGhlciB3aXRoIGV4aXN0aW5nIGFuZCBlbWVyZ2luZw0K ZXZlbnQsIGluY2lkZW50IGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRvIHByb3Zp ZGUNCnZpc2liaWxpdHkgaW50byB0aGUgc3RhdGUgb2YgYXNzZXRzLCB1c2VyIGFjdGl2aXRpZXMg YW5kIG5ldHdvcmsNClxiZWhhdmlvci4gU3Rha2Vob2xkZXJzIHdpbGwgYmUgYWJsZSB0byB1c2Ug dGhlc2UgdG9vbHMgdG8gYWdncmVnYXRlDQphbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eSBh bmQgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZQ0Kb3JnYW5pemF0aW9ucyBzZWN1 cml0eSBwb3N0dXJlLCBxdWFudGlmeSBidXNpbmVzcyByaXNrLCBhbmQgbWFrZQ0KaW5mb3JtZWQg ZGVjaXNpb25zIHRoYXQgc3VwcG9ydCBvcmdhbml6YXRpb25hbCBvYmplY3RpdmVzIHdoaWxlDQpw cm90ZWN0aW5nIGNyaXRpY2FsIGluZm9ybWF0aW9uLiBPcmdhbml6YXRpb25zIHdpbGwgYmUgYWJs ZSB0byB1c2UNCnRoZXNlIHRvb2xzIHRvIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGluZm9ybWF0aW9u IHNoYXJpbmcgYWN0aXZpdGllcyB0bw0KY29sbGFib3JhdGUgd2l0aCBwYXJ0bmVycyB0byBpZGVu dGlmeSBhbmQgbWl0aWdhdGUgdGhyZWF0cy4gT3RoZXINCmF1dG9tYXRpb24gdG9vbHMgd2lsbCBi ZSBhYmxlIHRvIGludGVncmF0ZSB3aXRoIHRoZXNlIGNhcGFiaWxpdGllcyB0bw0KZW5mb3JjZSBw b2xpY2llcyBiYXNlZCBvbiBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVuIHN5c3RlbXMsIHByZXZl bnQNCm1pc3VzZSBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFjayBzdXJmYWNlLg0KDQoNCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCjxtYWlsdG86c2FjbUBpZXRmLm9y Zz5zYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FjbT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhY20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0K --_000_D28C611D52FB4AC79FE4826E33303ACFemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5IaSBEYXZpZCw8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkdyZWF0IHF1ZXN0aW9ucyAmYW1wOyB0aGFua3MgZm9yIHRoZSByZXZpZXch ICZuYnNwO0knbGwgc3RhcnQgd2l0aCAjNCwgYnV0IGFtIGxpbWl0ZWQgdG8gYW4gaVBob25lIGF0 IHRoZSBtb21lbnQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TdGFuZGFyZHMgZGV2ZWxvcG1l bnQgb3JnYW5pemF0aW9ucyAoU0RPcykgaGF2ZSByZXF1aXJlbWVudHMgdG8gZW5zdXJlIHRoZSBz dGFiaWxpdHkgb2YgZG9jdW1lbnRzIGZvciAibm9ybWF0aXZlIHJlZmVyZW5jZXMiLiAmbmJzcDtP dGhlciBTRE9zIGFyZSB2YWxpZCBsb2NhdGlvbnMgZm9yIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFz IHRoZSByZWZlcmVuY2UgaXMgdG8gYSBkb2N1bWVudCBhcyBvcHBvc2VkIHRvIGEgbGluay4gJm5i c3A7QSBsaW5rIGNhbiBjaGFuZ2UvZGlzYXBwZWFyLCB0aGUgY29udGVudCBjYW4gY2hhbmdlLCBh bmQgdGhlcmVmb3JlIHRoZSBkb2N1bWVudCBtYXkgbm90IGJlIHN0YWJsZS4gJm5ic3A7PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbmV4dCBzZXQgb2YgaXNzdWVzIGFyZSBhcm91bmQgSVAu ICZuYnNwO0lmIHRoZSBkb2N1bWVudCBpcyBhdCBhbiBTRE8sIHRoZSBJUCBpcyBjbGVhciBldmVu IGlmIHRoZXJlIHdlcmUgSVAgZGlzY2xvc3VyZXMgc3VibWl0dGVkIGZvciB0aGF0IGRvY3VtZW50 LiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIGEgZG9jdW1lbnQgaXMgaG9zdGVk IGJ5IGEgdmVuZG9yLCBldmVuIGlmIHRoYXQgZG9jdW1lbnQgaXMgb3BlbiwgYWRvcHRpb24gd291 bGQgaW5jcmVhc2Ugb2Ygc29tZXRoaW5nIHRoYXQgY2FuIGJlIHNoYXJlZCBpZiBpdCBpcyBhdCBh biBTRE8uICZuYnNwO1RoZSBzdWJtaXR0ZWQgc3RpbGwgc2hvd3MgdGhlIHRob3VnaHQgbGVhZGVy c2hpcCB3aXRoIHRoZSBjb250cmlidXRpb24gYW5kIG90aGVyIHZlbmRvcnMgY2FuIHNpdGUgY29t cGxpYW5jZSB0byBhIHN0YW5kYXJkcyBkb2N1bWVudCBhcyBvcHBvc2VkIHRvIHNvbWV0aGluZyBm cm9tIGFub3RoZXIgdmVuZG9yLiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkV4YW1w bGVzIG9mIG90aGVyIFNET3MgaW5jbHVkZSBJU08sIElFRUUsIFczQywgSVRVLCBPQVNJUywgZXRj LiAmbmJzcDtXaGlsZSBOSVNUIGlzIG5vdCBhbiBTRE8gaW4gdGhlIHNhbWUgc2Vuc2UsIHRoZWly IGRvY3VtZW50cyBhcmUgYWNjZXB0ZWQgYXMgdmFsaWQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgZnJv bSBtaXN0IG9mIHRoZSBTRE9zLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3RldmUgSGFubmEg b3Igb3RoZXJzIC0gZG8geW91IGhhdmUgYW55IG90aGVyIHJlYXNvbnMgdG8gYWRkPzwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+SSBob3BlIHRoaXMgaXMgaGVscGZ1bCE8L2Rpdj48ZGl2PkthdGhs ZWVuJm5ic3A7PGJyPjxicj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PGRpdj48YnI+T24gU2Vw IDEwLCAyMDEyLCBhdCA5OjQ1IEFNLCAiPGEgaHJlZj0ibWFpbHRvOmRhdmlkLm9saXZhQHZlcml6 b24ubmV0Ij5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86 ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQiPmRhdmlkLm9saXZhQHZlcml6b24ubmV0PC9hPiZndDsg d3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+PGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBDT0xPUjogIzAwMDAwMDsgRk9OVC1T SVpFOiAxMnB4Ij48ZGl2PjxwIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMTBwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VG8gYWxsOjxvOnA+ PC9vOnA+PC9mb250PjwvZm9udD48L3A+PHAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAxMHB0IiBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD48L286cD48L3A+PHAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAxMHB0IiBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIj48Zm9udCBmYWNlPSJDYWxpYnJpIj5UaGUgZG9jdW1l bnQgYXBwZWFycyB2ZXJ5IGdvb2QgdG8gbWUuPG86cD48L286cD48L2ZvbnQ+PC9mb250PjwvcD48 cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvbzpwPjwvcD48cCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi Pjxmb250IGZhY2U9IkNhbGlicmkiPkNvbW1lbnRzOjxvOnA+PC9vOnA+PC9mb250PjwvZm9udD48 L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJTjogMGluIDBpbiAwcHQ7IHRh Yi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMy MC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQx LjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IkNhbGlicmkiPjMuMy4xLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvc3Bhbj5Hb2FsIOKAnDwvZm9udD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyc7IEZPTlQtU0laRTogMTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyA8 L3NwYW4+Q29udGludW91cyBhc3Nlc3NtZW50IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZWZm ZWN0aXZlbmVzcyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0iTElORS1IRUlHSFQ6 IG5vcm1hbDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEz Ny40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4 LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBG T05ULVNJWkU6IDEwcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu JyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFuPnNl Y3VyaXR5IGNvbnRyb2xzIGJhc2VkIG9uIG1hY2hpbmUgcHJvY2Vzc2FibGUgY29udGVudC7igJ08 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+UEhFTk9NRU5BTCE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAxMHB0IiBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD48L286cD48L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJTjogMGlu IDBpbiAwcHQ7IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBw dCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0 IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0OyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFSR0lOOiAwaW4gMGlu IDBwdDsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3 NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1 LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+UGFyYWdyYXBoIDkuIEFja25vd2xl ZGdlbWVudHNzOjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj5N aXNwZWxsZWQgd29yZCDigJx0aGllcuKAnSBjaGFuZ2UgdG8g4oCcdGhlaXLigJ0uPG86cD48L286 cD48L3NwYW4+PC9wPjxkaXY+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn OyBGT05ULVNJWkU6IDEwcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJyI+PC9zcGFuPiZuYnNwOzwvZGl2PjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogbm9ybWFsOyBN QVJHSU46IDBpbiAwaW4gMHB0OyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMu MnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44 cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTog MTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJ TjogMGluIDBpbiAwcHQ7IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0 OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPlN1Z2dlc3Rpb25z OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFS R0lOOiAwaW4gMGluIDBwdDsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJw dCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0 IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEw cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogbm9ybWFsOyBNQVJHSU46 IDBpbiAwaW4gMHB0OyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIy OS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5 LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdDsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj5UaGUgbWF0dXJlIHN0 YXRlIG9mIGF1dG9tYXRpb24gbWFrZXMgaXQgd29ydGh3aGlsZSB0byBpbnRyb2R1Y2UgbmV3IGFz c29jaWF0ZWQgdGVybXMgdG8gYWRkcmVzcyBmdXR1cmUgc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJTjogMGluIDBpbiAw cHQ7IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQu OHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40 cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFSR0lOOiAwaW4gMGluIDBwdDsg dGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+QXV0b21hdGFibGUgKGFkdmVyYik6PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPlRoZSBjb25kaXRpb24gb2Yg YSBwcm9jZXNzIHRoYXQgY2FuIGJlIGltcGxlbWVudGVkIHdpdGggc2VjdXJpdHkgYXV0b21hdGlv biBtZWNoYW5pc21zLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bh bj5Gb3IgaW5zdGFuY2UsIOKAnGNvbmZpZ3VyYXRpb24gY29tcGxpYW5jZSBpcyBhbiBhdXRvbWF0 YWJsZSBwcm9jZXNz4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogbm9ybWFsOyBNQVJHSU46IDBpbiAwaW4gMHB0OyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQg MTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0 NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IEZPTlQtU0laRTogMTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBu b3JtYWw7IE1BUkdJTjogMGluIDBpbiAwcHQ7IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9O VC1TSVpFOiAxMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbici Pk5vbi1hdXRvbWF0YWJsZSAoYWR2ZXJiKTo8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L3NwYW4+VGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nlc3MgdGhhdCBjYW5ub3QgYmUg aW1wbGVtZW50ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuPHNwYW4gc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPkZvciBpbnN0YW5jZSwg4oCcY29u ZmxpY3RpbmcgPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L3NwYW4+cG9s aWN5IHJlc29sdXRpb24gaXMgYSBub24tYXV0b21hdGFibGUgcHJvY2Vzc+KAnS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJTjogMGluIDBp biAwcHQ7IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAy NzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5 NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFSR0lOOiAwaW4gMGluIDBw dDsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44 cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRw dCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+U2VtaS1hdXRvbWF0YWJsZSAoYWR2ZXJi KTo8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+VGhlIGNvbmRp dGlvbiBvZiBhIHByb2Nlc3Mgd2hpY2ggY2FuIGJlIHBhcnRpYWxseSBpbXBsZW1lbnRlZCBvciBz dXBwb3J0ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuPHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPkZvciBleGFtcGxlIOKAnFNvbWUgc2Vt aS1hdXRvbWF0YWJsZSBwcm9jZXNzZXMgY2FuIGJlIHN1cHBvcnRlZCB3aXRoIFNDQU0gc3BlY2lm aWNhdGlvbnMgc3VjaCBhcyB0aGUgT3BlbiBDaGVja2xpc3QgSW50ZXJhY3RpdmUgTGFuZ3VhZ2Ug KE9DSUwp4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250PjwvbzpwPjwvcD48cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmkiPkEg ZmV3IHF1ZXN0aW9ucyBjb21lIHRvIG1pbmQgKHBlcmhhcHMgZHVlIHRvIG15IGxhY2sgb2YgZmFt aWxpYXJpdHkgd2l0aCB0aGUgbW9kdXMgb3BlcmFuZGkgb2YgdGhlIElFVEYpLjxvOnA+PC9vOnA+ PC9mb250PjwvZm9udD48L3A+PHAgc3R5bGU9IlRFWFQtSU5ERU5UOiAtMC4yNWluOyBNQVJHSU46 IDBpbiAwaW4gMHB0IDAuNWluOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoQ3hTcEZpcnN0Ij48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1mYW1pbHk6 IENhbGlicmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6IElnbm9yZSI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+MS48L2ZvbnQ+ PHNwYW4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjxmb250IHNpemU9IjMi Pjxmb250IGZhY2U9IkNhbGlicmkiPldoYXQgaGFwcGVucyB3aXRoIHRoZSBkb2N1bWVudCBhdCB0 aGUgZW5kIG9mIE1hcmNoIDIwMTM/PG86cD48L286cD48L2ZvbnQ+PC9mb250PjwvcD48cCBzdHls ZT0iVEVYVC1JTkRFTlQ6IC0wLjI1aW47IE1BUkdJTjogMGluIDBpbiAwcHQgMC41aW47IG1zby1s aXN0OiBsMCBsZXZlbDEgbGZvMSIgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj48 c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLXRoZW1l LWZvbnQ6IG1pbm9yLWxhdGluIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+Mi48L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQ6IDdwdCAn VGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmkiPldo ZXJlIGRvZXMgdGhlIG1vZGVsIGluIEZpZ3VyZSAxIGNvbWUgZnJvbT88bzpwPjwvbzpwPjwvZm9u dD48L2ZvbnQ+PC9wPjxwIHN0eWxlPSJURVhULUlOREVOVDogLTAuMjVpbjsgTUFSR0lOOiAwaW4g MGluIDBwdCAwLjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BNaWRkbGUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LWZhbWlseTogQ2Fs aWJyaTsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItbGF0aW4iPjxzcGFuIHN0eWxlPSJtc28t bGlzdDogSWdub3JlIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj4zLjwvZm9udD48c3Bh biBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PGZvbnQgc2l6ZT0iMyI+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+V2h5IGFyZSBvbmx5IG90aGVyIFJGQ3MgYWNjZXB0YWJsZSByZWZl cmVuY2VzPzxvOnA+PC9vOnA+PC9mb250PjwvZm9udD48L3A+PHAgc3R5bGU9IlRFWFQtSU5ERU5U OiAtMC4yNWluOyBNQVJHSU46IDBpbiAwaW4gMTBwdCAwLjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xIiBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0Ij48c3BhbiBzdHlsZT0ibXNv LWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxh dGluIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i Q2FsaWJyaSI+NC48L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFu JyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmkiPldoeSBhcmUgYWNyb255bXMg d2l0aG91dCBkZWZpbml0aW9ucyB1c2VkIChPUk0sIElSTSk/PG86cD48L286cD48L2ZvbnQ+PC9m b250PjwvcD48cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmkiPkRhdmlkIE9saXZhPG86cD48L286 cD48L2ZvbnQ+PC9mb250PjwvcD4mbmJzcDs8L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+Jm5i c3A7PC9kaXY+PGRpdiBzdHlsZT0iTUFSR0lOOiA1cHggMHB4OyBCT1JERVItVE9QOiAjYmNiY2Jj IDFweCBzb2xpZCI+PC9kaXY+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBhcmlhbDsgQ09MT1I6 ICMwMDAwMDA7IEZPTlQtU0laRTogMTJweCI+T24gMDkvMDcvMTIsIDxzcGFuPldhbHRlcm1pcmUs IERhdmlkIEEuJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Ij5k YXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9hPiZndDs8L3NwYW4+IHdyb3RlOjwvc3Bhbj48ZGl2 PiZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBhcmlhbDsgQ09MT1I6ICMwMDAw MDA7IEZPTlQtU0laRTogMTJweCI+SSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVkIHVzZSBjYXNlcyBk b2N1bWVudCAoc2VlIGJlbG93KSB0aGF0IHJlZHVjZXMgdGhlIHNjb3BlIHRvIFVDMS0zIGFuZCBh ZGRzIGEgbG90IG9mIG5ldyBjb250ZW50LiBNYW55IHRoYW5rcyB0byBBZGFtIE1vbnR2aWxsZSBm b3IgYWxsIGhpcyBoYXJkIHdvcmsgb24gdGhpcyByZXZpc2lvbi48YnI+PGJyPkNvbW1lbnRzIGFy ZSBhcHByZWNpYXRlZC48YnI+PGJyPlNpbmNlcmVseSw8YnI+RGF2ZTxicj48YnI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogPGEgY2xhc3M9InBhcnNlZEVtYWlsIiBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPjwvYT4gWzxhIGNsYXNzPSJwYXJzZWRMaW5rIiBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyI+bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48L2E+XSA8 YnI+U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMTIgMzo0OSBQTTxicj5UbzogV2FsdGVy bWlyZSwgRGF2aWQgQS48YnI+Q2M6IDxhIGNsYXNzPSJwYXJzZWRFbWFpbCIgaHJlZj0ibWFpbHRv OmFtb250dmlsbGVAdHJpcHdpcmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0ibWFpbHRv OmFtb250dmlsbGVAdHJpcHdpcmUuY29tIj5hbW9udHZpbGxlQHRyaXB3aXJlLmNvbTwvYT48L2E+ PGJyPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FsdGVybWly ZS1zYWNtLXVzZS1jYXNlcy0wMi50eHQ8YnI+PGJyPjxicj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0wMi50eHQ8YnI+aGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBXYWx0ZXJtaXJlIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS48YnI+PGJyPkZpbGVuYW1lOiBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNl LWNhc2VzPGJyPlJldmlzaW9uOiAwMjxicj5UaXRsZTogQW5hbHlzaXMgb2YgU2VjdXJpdHkgQXV0 b21hdGlvbiBhbmQgQ29udGludW91cyBNb25pdG9yaW5nIChTQUNNKSBVc2UgQ2FzZXM8YnI+Q3Jl YXRpb24gZGF0ZTogMjAxMi0wOS0wNzxicj5XRyBJRDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJy Pk51bWJlciBvZiBwYWdlczogMjM8YnI+VVJMOiA8YSBjbGFzcz0icGFyc2VkTGluayIgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2FsdGVybWlyZS1zYWNt LXVzZS1jYXNlcy0wMi50eHQiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAy LnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2FsdGVybWly ZS1zYWNtLXVzZS1jYXNlcy0wMi50eHQ8L2E+PC9hPjxicj5TdGF0dXM6IDxhIGNsYXNzPSJwYXJz ZWRMaW5rIiBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbHRl cm1pcmUtc2FjbS11c2UtY2FzZXMiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMiPmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1j YXNlczwvYT48L2E+PGJyPkh0bWxpemVkOiA8YSBjbGFzcz0icGFyc2VkTGluayIgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0w MiIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDI8L2E+PC9hPjxicj5EaWZmOiA8 YSBjbGFzcz0icGFyc2VkTGluayIgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0wMiIgdGFyZ2V0PSJfYmxhbmsiPjxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXdhbHRlcm1pcmUt c2FjbS11c2UtY2FzZXMtMDIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDI8L2E+PC9hPjxicj48YnI+QWJzdHJhY3Q6PGJy PlRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyBmb3VuZGF0aW9uYWwgdXNlIGNhc2VzLCBkZXJpdmVk IGZ1bmN0aW9uYWw8YnI+Y2FwYWJpbGl0aWVzIGFuZCByZXF1aXJlbWVudHMsIGFyY2hpdGVjdHVy YWwgY29tcG9uZW50cywgYW5kIHRoZTxicj5zdXBwb3J0aW5nIHN0YW5kYXJkcyBuZWVkZWQgdG8g ZGVmaW5lIGFuIGludGVyb3BlcmFibGUsPGJyPmF1dG9tYXRpb25caW5mcmFzdHJ1Y3R1cmUgcmVx dWlyZWQgdG8gc3VwcG9ydCB0aW1lbHksIGFjY3VyYXRlIGFuZDxicj5hY3Rpb25hYmxlIHNpdHVh dGlvbmFsIGF3YXJlbmVzcyBvdmVyIGFuIG9yZ2FuaXphdGlvbidzIElUIHN5c3RlbXMuPGJyPkF1 dG9tYXRpb24gdG9vbHMgaW1wbGVtZW50aW5nIGEgY29udGludW91cyBtb25pdG9yaW5nIGFwcHJv YWNoIHdpbGw8YnI+dXRpbGl6ZSB0aGlzIGluZnJhc3RydWN0dXJlIHRvZ2V0aGVyIHdpdGggZXhp c3RpbmcgYW5kIGVtZXJnaW5nPGJyPmV2ZW50LCBpbmNpZGVudCBhbmQgbmV0d29yayBtYW5hZ2Vt ZW50IHN0YW5kYXJkcyB0byBwcm92aWRlPGJyPnZpc2liaWxpdHkgaW50byB0aGUgc3RhdGUgb2Yg YXNzZXRzLCB1c2VyIGFjdGl2aXRpZXMgYW5kIG5ldHdvcms8YnI+XGJlaGF2aW9yLiBTdGFrZWhv bGRlcnMgd2lsbCBiZSBhYmxlIHRvIHVzZSB0aGVzZSB0b29scyB0byBhZ2dyZWdhdGU8YnI+YW5k IGFuYWx5emUgcmVsZXZhbnQgc2VjdXJpdHkgYW5kIG9wZXJhdGlvbmFsIGRhdGEgdG8gdW5kZXJz dGFuZCB0aGU8YnI+b3JnYW5pemF0aW9ucyBzZWN1cml0eSBwb3N0dXJlLCBxdWFudGlmeSBidXNp bmVzcyByaXNrLCBhbmQgbWFrZTxicj5pbmZvcm1lZCBkZWNpc2lvbnMgdGhhdCBzdXBwb3J0IG9y Z2FuaXphdGlvbmFsIG9iamVjdGl2ZXMgd2hpbGU8YnI+cHJvdGVjdGluZyBjcml0aWNhbCBpbmZv cm1hdGlvbi4gT3JnYW5pemF0aW9ucyB3aWxsIGJlIGFibGUgdG8gdXNlPGJyPnRoZXNlIHRvb2xz IHRvIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGluZm9ybWF0aW9uIHNoYXJpbmcgYWN0aXZpdGllcyB0 bzxicj5jb2xsYWJvcmF0ZSB3aXRoIHBhcnRuZXJzIHRvIGlkZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0 aHJlYXRzLiBPdGhlcjxicj5hdXRvbWF0aW9uIHRvb2xzIHdpbGwgYmUgYWJsZSB0byBpbnRlZ3Jh dGUgd2l0aCB0aGVzZSBjYXBhYmlsaXRpZXMgdG88YnI+ZW5mb3JjZSBwb2xpY2llcyBiYXNlZCBv biBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVuIHN5c3RlbXMsIHByZXZlbnQ8YnI+bWlzdXNlIGFu ZCByZWR1Y2UgdGhlIG92ZXJhbGwgYXR0YWNrIHN1cmZhY2UuPGJyPjxicj48YnI+PGJyPjxicj5U aGUgSUVURiBTZWNyZXRhcmlhdDxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+c2FjbSBtYWlsaW5nIGxpc3Q8YnI+PGEgY2xhc3M9InBhcnNl ZEVtYWlsIiBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhy ZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjwvYT48YnI+PGEgY2xh c3M9InBhcnNlZExpbmsiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zYWNtPC9hPjwvYT48YnI+PC9kaXY+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+c2FjbSBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3Jn PC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nh Y208L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_D28C611D52FB4AC79FE4826E33303ACFemccom_-- From amontville@tripwire.com Mon Sep 10 08:21:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECE821F869F for ; Mon, 10 Sep 2012 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 QV2Ee16zVYM3 for ; Mon, 10 Sep 2012 08:21:44 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9321F8692 for ; Mon, 10 Sep 2012 08:21:43 -0700 (PDT) Received: from mail262-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 15:21:42 +0000 Received: from mail262-va3 (localhost [127.0.0.1]) by mail262-va3-R.bigfish.com (Postfix) with ESMTP id AF8FD17800FA for ; Mon, 10 Sep 2012 15:21:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I936eIc85eh542M1a09J1447Izz1202h1d1ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5hbe3k1155h) Received: from mail262-va3 (localhost.localdomain [127.0.0.1]) by mail262-va3 (MessageSwitch) id 1347290500133822_21999; Mon, 10 Sep 2012 15:21:40 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.235]) by mail262-va3.bigfish.com (Postfix) with ESMTP id 1E9E01140046 for ; Mon, 10 Sep 2012 15:21:40 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 15:21:39 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 02E222321229 for ; Mon, 10 Sep 2012 08:18:02 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 470B223211F0; Mon, 10 Sep 2012 08:18:01 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 10 Sep 2012 08:23:54 -0700 Received: from PDXMB03.tripwire.com ([fe80::284f:fde0:d82f:4223]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 10 Sep 2012 08:21:37 -0700 From: Adam Montville To: "Moriarty, Kathleen" , "david.oliva@verizon.net" Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: AQHNj1oq8aMEV8nqh0SKhkV1wNdDKZeEEFSA//+g5AA= Date: Mon, 10 Sep 2012 15:21:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC735352456Aamontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 8c0158d8-63c7-4519-a1bf-9baf09d85686 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "david.waltermire@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:21:48 -0000 --_000_CC735352456Aamontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: , "kathleen.moriarty@emc.com" > Date: Monday, September 10, 2012 7:01 AM To: "david.oliva@verizon.net" > Cc: "david.waltermire@nist.gov" >, "sacm@ietf.org" > Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-= use-cases-02.txt Hi David, Great questions & thanks for the review! I'll start with #4, but am limite= d to an iPhone at the moment. #3 is what I believe Kathleen meant. Standards development organizations (SDOs) have requirements to ensure the = stability of documents for "normative references". Other SDOs are valid lo= cations for normative references as the reference is to a document as oppos= ed to a link. A link can change/disappear, the content can change, and the= refore the document may not be stable. The next set of issues are around IP. If the document is at an SDO, the IP= is clear even if there were IP disclosures submitted for that document. If a document is hosted by a vendor, even if that document is open, adoptio= n would increase of something that can be shared if it is at an SDO. The s= ubmitted still shows the thought leadership with the contribution and other= vendors can site compliance to a standards document as opposed to somethin= g from another vendor. Examples of other SDOs include ISO, IEEE, W3C, ITU, OASIS, etc. While NIST= is not an SDO in the same sense, their documents are accepted as valid nor= mative references from mist of the SDOs. Steve Hanna or others - do you have any other reasons to add? I hope this is helpful! Kathleen Sent from my iPhone On Sep 10, 2012, at 9:45 AM, "david.oliva@verizon.net" > wrote= : To all: The document appears very good to me. Comments: 3.3.1. Goal =93 Continuous assessment of the implementation and effectiv= eness of security controls based on machine processable content.=94 PHENOMENAL! Paragraph 9. Acknowledgementss: Mispelled word =93thier=94 change to =93th= eir=94. Suggestions: The mature state of automation makes it worthwhile to introduce new associa= ted terms to address future situations. Automatable (adverb): The condition of a process that can be implemented w= ith security automation mechanisms. For instance, =93configuration complia= nce is an automatable process=94 Non-automatable (adverb): The condition of a process that cannot be implem= ented with security automation mechanisms. For instance, =93conflicting p= olicy resolution is a non-automatable process=94. Semi-automatable (adverb): The condition of a process which can be partial= ly implemented or supported with security automation mechanisms. For examp= le =93Some semi-automatable processes can be supported with SCAM specificat= ions such as the Open Checklist Interactive Language (OCIL)=94. A few questions come to mind (perhaps due to my lack of familiarity with th= e modus operandi of the IETF). 1. What happens with the document at the end of March 2013? 2. Where does the model in Figure 1 come from? 3. Why are only other RFCs acceptable references? 4. Why are acronyms without definitions used (ORM, IRM)? David Oliva On 09/07/12, Waltermire, David A.> wrote: I just posted an updated use cases document (see below) that reduces the sc= ope to UC1-3 and adds a lot of new content. Many thanks to Adam Montville f= or all his hard work on this revision. Comments are appreciated. Sincerely, Dave -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] Sent: Friday, September 07, 2012 3:49 PM To: Waltermire, David A. Cc: amontville@tripwire.com Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.tx= t A new version of I-D, draft-waltermire-sacm-use-cases-02.txt has been successfully submitted by David Waltermire and posted to the IETF = repository. Filename: draft-waltermire-sacm-use-cases Revision: 02 Title: Analysis of Security Automation and Continuous Monitoring (SACM) Use= Cases Creation date: 2012-09-07 WG ID: Individual Submission Number of pages: 23 URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-= 02.txt Status: h= ttp://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases Htmlized: h= ttp://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-02 Abstract: This document identifies foundational use cases, derived functional capabilities and requirements, architectural components, and the supporting standards needed to define an interoperable, automation\infrastructure required to support timely, accurate and actionable situational awareness over an organization's IT systems. Automation tools implementing a continuous monitoring approach will utilize this infrastructure together with existing and emerging event, incident and network management standards to provide visibility into the state of assets, user activities and network \behavior. Stakeholders will be able to use these tools to aggregate and analyze relevant security and operational data to understand the organizations security posture, quantify business risk, and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use these tools to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. The IETF Secretariat _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/li= stinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC735352456Aamontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
From: <Moriarty>, "kathleen.moriarty@emc.com"= <kathleen.moriarty@emc.com= >
Date: Monday, September 10, 2012 7:= 01 AM
To: "david.oliva@verizon.net" <david.oliva@verizon.net>
Cc: "david.waltermire@nist.gov" <david.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] FW: New Version= Notification for draft-waltermire-sacm-use-cases-02.txt

Hi David,

Great questions & thanks for the review!  I'll start with #4,= but am limited to an iPhone at the moment.


#3 is what I believe Kathleen meant.



Standards development organizations (SDOs) have requirements to ensure= the stability of documents for "normative references".  Oth= er SDOs are valid locations for normative references as the reference is to= a document as opposed to a link.  A link can change/disappear, the content can change, and therefore the document may not be stable. &nbs= p;

The next set of issues are around IP.  If the document is at an S= DO, the IP is clear even if there were IP disclosures submitted for that do= cument.  

If a document is hosted by a vendor, even if that document is open, ad= option would increase of something that can be shared if it is at an SDO. &= nbsp;The submitted still shows the thought leadership with the contribution= and other vendors can site compliance to a standards document as opposed to something from another vendor.  = ;

Examples of other SDOs include ISO, IEEE, W3C, ITU, OASIS, etc.  = While NIST is not an SDO in the same sense, their documents are accepted as= valid normative references from mist of the SDOs.

Steve Hanna or others - do you have any other reasons to add?

I hope this is helpful!
Kathleen 

Sent from my iPhone

On Sep 10, 2012, at 9:45 AM, "david.oliva@verizon.net" <david.oliva@verizon.net> wrote:

To all:

 

The document appears very good to me.<= /font>

 

Comments:

3.3.1.&= nbsp; Goal =93   Continuous assessment of the implementation and effectiveness of

   security controls based on machine processable content.=94  PHENOMENAL!

 

 

Paragraph 9. = Acknowledgementss:  Mispelled word =93thier=94 change to =93their=94.<= /p>

&= nbsp;

 

Suggestions:<= o:p>

 

The mature st= ate of automation makes it worthwhile to introduce new associated terms to = address future situations.

 

Automatable (= adverb):  The condition of a process that can be implemented with security aut= omation mechanisms.  For instance, =93configuration compliance is an automatable process= =94

 

Non-automatab= le (adverb):  The condition of a process that cannot be implemented with security = automation mechanisms.  For instance, =93conflicting  = ;policy resolution is a non-automatable process=94.

 

Semi-automata= ble (adverb):  The condition of a process which can be partially implemented or sup= ported with security automation mechanisms. 

A few questions come to mind (perhaps due to my lack of = familiarity with the modus operandi of the IETF).<= /p>

1.<= /font> Automation tools implementing a continuous monitoring approach will
utilize this infrastructure together with existing and emerging
event, incident and network management standards to provide
visibility into the state of assets, user activities and network
\behavior. Stakeholders will be able to use these tools to aggregate
and analyze relevant security and operational data to understand the
organizations security posture, quantify business risk, and make
informed decisions that support organizational objectives while
protecting critical information. Organizations will be able to use
these tools to augment and automate information sharing activities to
collaborate with partners to identify and mitigate threats. Other
automation tools will be able to integrate with these capabilities to
enforce policies based on human decisions to harden systems, prevent
misuse and reduce the overall attack surface.




The IETF Secretariat

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

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ie= tf.org/mailman/listinfo/sacm


--_000_CC735352456Aamontvilletripwirecom_-- From shanna@juniper.net Mon Sep 10 18:33:44 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C521F8701 for ; Mon, 10 Sep 2012 18:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 hSKSgI2tNMPC for ; Mon, 10 Sep 2012 18:33:43 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 910D521F86FD for ; Mon, 10 Sep 2012 18:33:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUE6U82yzccup7f/CxYYy5j7xE7hWhp0s@postini.com; Mon, 10 Sep 2012 18:33:42 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 18:30:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 10 Sep 2012 21:30:05 -0400 From: Stephen Hanna To: "Moriarty, Kathleen" , "david.oliva@verizon.net" Date: Mon, 10 Sep 2012 21:30:04 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: Ac2PXN2j1hF5lhFBT9WF9pU/biZWuAAXwCLA Message-ID: References: <110204.2574544.1347284521924.JavaMail.root@vznit170136> 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_AC6674AB7BC78549BB231821ABF7A9AEB9178F2B95EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "david.waltermire@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:33:44 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB9178F2B95EMBX01WFjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEthdGhsZWVu4oCZcyBjb21tZW50cyBvbiBxdWVzdGlvbiAzIGJ1dCBJ4oCZ ZCBhbHNvIHN1Z2dlc3QgdGhhdCBTQUNNIHBhcnRpY2lwYW50cyByZXZpZXcgc2VjdGlvbnMgNC4y LjQsIDcsIGFuZCAxMCBvZiBSRkMgMjAyNiwgZXNwZWNpYWxseSBzZWN0aW9uIDcuIFRoYXQgc2Vj dGlvbiBjb250YWlucyBhIGdvb2QgZXhwbGFuYXRpb24gb2YgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBvcGVuIHN0YW5kYXJkcyBhbmQgb3RoZXIgc3BlY2lmaWNhdGlvbnMsIGhvdyB0aGUgSUVURiBz aG91bGQgZGVhbCB3aXRoIHRoZXNlIGNhdGVnb3JpZXMgb2Ygc3BlY2lmaWNhdGlvbnMsIGFuZCB3 aHkuIFRoaXMgaXNzdWUgc2VlbXMgdG8gYmUgZXNwZWNpYWxseSBjcml0aWNhbCBmb3IgU0FDTS4N Cg0KVGhhbmtzLA0KDQpTdGV2ZQ0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNb3JpYXJ0eSwgS2F0aGxlZW4N ClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAyMDEyIDEwOjAyIEFNDQpUbzogZGF2aWQub2xp dmFAdmVyaXpvbi5uZXQNCkNjOiBkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292OyBzYWNtQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NhY21dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIudHh0DQoNCkhpIERhdmlkLA0KDQpH cmVhdCBxdWVzdGlvbnMgJiB0aGFua3MgZm9yIHRoZSByZXZpZXchICBJJ2xsIHN0YXJ0IHdpdGgg IzQsIGJ1dCBhbSBsaW1pdGVkIHRvIGFuIGlQaG9uZSBhdCB0aGUgbW9tZW50Lg0KDQpTdGFuZGFy ZHMgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9ucyAoU0RPcykgaGF2ZSByZXF1aXJlbWVudHMgdG8g ZW5zdXJlIHRoZSBzdGFiaWxpdHkgb2YgZG9jdW1lbnRzIGZvciAibm9ybWF0aXZlIHJlZmVyZW5j ZXMiLiAgT3RoZXIgU0RPcyBhcmUgdmFsaWQgbG9jYXRpb25zIGZvciBub3JtYXRpdmUgcmVmZXJl bmNlcyBhcyB0aGUgcmVmZXJlbmNlIGlzIHRvIGEgZG9jdW1lbnQgYXMgb3Bwb3NlZCB0byBhIGxp bmsuICBBIGxpbmsgY2FuIGNoYW5nZS9kaXNhcHBlYXIsIHRoZSBjb250ZW50IGNhbiBjaGFuZ2Us IGFuZCB0aGVyZWZvcmUgdGhlIGRvY3VtZW50IG1heSBub3QgYmUgc3RhYmxlLg0KDQpUaGUgbmV4 dCBzZXQgb2YgaXNzdWVzIGFyZSBhcm91bmQgSVAuICBJZiB0aGUgZG9jdW1lbnQgaXMgYXQgYW4g U0RPLCB0aGUgSVAgaXMgY2xlYXIgZXZlbiBpZiB0aGVyZSB3ZXJlIElQIGRpc2Nsb3N1cmVzIHN1 Ym1pdHRlZCBmb3IgdGhhdCBkb2N1bWVudC4NCg0KSWYgYSBkb2N1bWVudCBpcyBob3N0ZWQgYnkg YSB2ZW5kb3IsIGV2ZW4gaWYgdGhhdCBkb2N1bWVudCBpcyBvcGVuLCBhZG9wdGlvbiB3b3VsZCBp bmNyZWFzZSBvZiBzb21ldGhpbmcgdGhhdCBjYW4gYmUgc2hhcmVkIGlmIGl0IGlzIGF0IGFuIFNE Ty4gIFRoZSBzdWJtaXR0ZWQgc3RpbGwgc2hvd3MgdGhlIHRob3VnaHQgbGVhZGVyc2hpcCB3aXRo IHRoZSBjb250cmlidXRpb24gYW5kIG90aGVyIHZlbmRvcnMgY2FuIHNpdGUgY29tcGxpYW5jZSB0 byBhIHN0YW5kYXJkcyBkb2N1bWVudCBhcyBvcHBvc2VkIHRvIHNvbWV0aGluZyBmcm9tIGFub3Ro ZXIgdmVuZG9yLg0KDQpFeGFtcGxlcyBvZiBvdGhlciBTRE9zIGluY2x1ZGUgSVNPLCBJRUVFLCBX M0MsIElUVSwgT0FTSVMsIGV0Yy4gIFdoaWxlIE5JU1QgaXMgbm90IGFuIFNETyBpbiB0aGUgc2Ft ZSBzZW5zZSwgdGhlaXIgZG9jdW1lbnRzIGFyZSBhY2NlcHRlZCBhcyB2YWxpZCBub3JtYXRpdmUg cmVmZXJlbmNlcyBmcm9tIG1pc3Qgb2YgdGhlIFNET3MuDQoNClN0ZXZlIEhhbm5hIG9yIG90aGVy cyAtIGRvIHlvdSBoYXZlIGFueSBvdGhlciByZWFzb25zIHRvIGFkZD8NCg0KSSBob3BlIHRoaXMg aXMgaGVscGZ1bCENCkthdGhsZWVuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gU2VwIDEw LCAyMDEyLCBhdCA5OjQ1IEFNLCAiZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8bWFpbHRvOmRhdmlk Lm9saXZhQHZlcml6b24ubmV0PiIgPGRhdmlkLm9saXZhQHZlcml6b24ubmV0PG1haWx0bzpkYXZp ZC5vbGl2YUB2ZXJpem9uLm5ldD4+IHdyb3RlOg0KVG8gYWxsOg0KDQpUaGUgZG9jdW1lbnQgYXBw ZWFycyB2ZXJ5IGdvb2QgdG8gbWUuDQoNCkNvbW1lbnRzOg0KMy4zLjEuICBHb2FsIOKAnCAgIENv bnRpbnVvdXMgYXNzZXNzbWVudCBvZiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIGVmZmVjdGl2ZW5l c3Mgb2YNCiAgIHNlY3VyaXR5IGNvbnRyb2xzIGJhc2VkIG9uIG1hY2hpbmUgcHJvY2Vzc2FibGUg Y29udGVudC7igJ0gIFBIRU5PTUVOQUwhDQoNCg0KUGFyYWdyYXBoIDkuIEFja25vd2xlZGdlbWVu dHNzOiAgTWlzcGVsbGVkIHdvcmQg4oCcdGhpZXLigJ0gY2hhbmdlIHRvIOKAnHRoZWly4oCdLg0K DQoNClN1Z2dlc3Rpb25zOg0KDQpUaGUgbWF0dXJlIHN0YXRlIG9mIGF1dG9tYXRpb24gbWFrZXMg aXQgd29ydGh3aGlsZSB0byBpbnRyb2R1Y2UgbmV3IGFzc29jaWF0ZWQgdGVybXMgdG8gYWRkcmVz cyBmdXR1cmUgc2l0dWF0aW9ucy4NCg0KQXV0b21hdGFibGUgKGFkdmVyYik6ICBUaGUgY29uZGl0 aW9uIG9mIGEgcHJvY2VzcyB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRoIHNlY3VyaXR5IGF1 dG9tYXRpb24gbWVjaGFuaXNtcy4gIEZvciBpbnN0YW5jZSwg4oCcY29uZmlndXJhdGlvbiBjb21w bGlhbmNlIGlzIGFuIGF1dG9tYXRhYmxlIHByb2Nlc3PigJ0NCg0KTm9uLWF1dG9tYXRhYmxlIChh ZHZlcmIpOiAgVGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nlc3MgdGhhdCBjYW5ub3QgYmUgaW1wbGVt ZW50ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuICBGb3IgaW5zdGFuY2Us IOKAnGNvbmZsaWN0aW5nICBwb2xpY3kgcmVzb2x1dGlvbiBpcyBhIG5vbi1hdXRvbWF0YWJsZSBw cm9jZXNz4oCdLg0KDQpTZW1pLWF1dG9tYXRhYmxlIChhZHZlcmIpOiAgVGhlIGNvbmRpdGlvbiBv ZiBhIHByb2Nlc3Mgd2hpY2ggY2FuIGJlIHBhcnRpYWxseSBpbXBsZW1lbnRlZCBvciBzdXBwb3J0 ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuICBGb3IgZXhhbXBsZSDigJxT b21lIHNlbWktYXV0b21hdGFibGUgcHJvY2Vzc2VzIGNhbiBiZSBzdXBwb3J0ZWQgd2l0aCBTQ0FN IHNwZWNpZmljYXRpb25zIHN1Y2ggYXMgdGhlIE9wZW4gQ2hlY2tsaXN0IEludGVyYWN0aXZlIExh bmd1YWdlIChPQ0lMKeKAnS4NCg0KQSBmZXcgcXVlc3Rpb25zIGNvbWUgdG8gbWluZCAocGVyaGFw cyBkdWUgdG8gbXkgbGFjayBvZiBmYW1pbGlhcml0eSB3aXRoIHRoZSBtb2R1cyBvcGVyYW5kaSBv ZiB0aGUgSUVURikuDQoNCjEuICAgICAgIFdoYXQgaGFwcGVucyB3aXRoIHRoZSBkb2N1bWVudCBh dCB0aGUgZW5kIG9mIE1hcmNoIDIwMTM/DQoNCjIuICAgICAgIFdoZXJlIGRvZXMgdGhlIG1vZGVs IGluIEZpZ3VyZSAxIGNvbWUgZnJvbT8NCg0KMy4gICAgICAgV2h5IGFyZSBvbmx5IG90aGVyIFJG Q3MgYWNjZXB0YWJsZSByZWZlcmVuY2VzPw0KDQo0LiAgICAgICBXaHkgYXJlIGFjcm9ueW1zIHdp dGhvdXQgZGVmaW5pdGlvbnMgdXNlZCAoT1JNLCBJUk0pPw0KRGF2aWQgT2xpdmENCg0KDQoNCk9u IDA5LzA3LzEyLCBXYWx0ZXJtaXJlLCBEYXZpZCBBLjxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292 PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pj4gd3JvdGU6DQoNCkkganVzdCBwb3N0 ZWQgYW4gdXBkYXRlZCB1c2UgY2FzZXMgZG9jdW1lbnQgKHNlZSBiZWxvdykgdGhhdCByZWR1Y2Vz IHRoZSBzY29wZSB0byBVQzEtMyBhbmQgYWRkcyBhIGxvdCBvZiBuZXcgY29udGVudC4gTWFueSB0 aGFua3MgdG8gQWRhbSBNb250dmlsbGUgZm9yIGFsbCBoaXMgaGFyZCB3b3JrIG9uIHRoaXMgcmV2 aXNpb24uDQoNCkNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KU2luY2VyZWx5LA0KRGF2ZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMTIgMzo0OSBQTQ0K VG86IFdhbHRlcm1pcmUsIERhdmlkIEEuDQpDYzogYW1vbnR2aWxsZUB0cmlwd2lyZS5jb208bWFp bHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBXYWx0ZXJtaXJlIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6IGRyYWZ0LXdhbHRl cm1pcmUtc2FjbS11c2UtY2FzZXMNClJldmlzaW9uOiAwMg0KVGl0bGU6IEFuYWx5c2lzIG9mIFNl Y3VyaXR5IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyAoU0FDTSkgVXNlIENh c2VzDQpDcmVhdGlvbiBkYXRlOiAyMDEyLTA5LTA3DQpXRyBJRDogSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIzDQpVUkw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIudHh0DQpTdGF0dXM6 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVz ZS1jYXNlcw0KSHRtbGl6ZWQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbHRl cm1pcmUtc2FjbS11c2UtY2FzZXMtMDINCkRpZmY6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDINCg0KQWJzdHJhY3Q6DQpU aGlzIGRvY3VtZW50IGlkZW50aWZpZXMgZm91bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBm dW5jdGlvbmFsDQpjYXBhYmlsaXRpZXMgYW5kIHJlcXVpcmVtZW50cywgYXJjaGl0ZWN0dXJhbCBj b21wb25lbnRzLCBhbmQgdGhlDQpzdXBwb3J0aW5nIHN0YW5kYXJkcyBuZWVkZWQgdG8gZGVmaW5l IGFuIGludGVyb3BlcmFibGUsDQphdXRvbWF0aW9uXGluZnJhc3RydWN0dXJlIHJlcXVpcmVkIHRv IHN1cHBvcnQgdGltZWx5LCBhY2N1cmF0ZSBhbmQNCmFjdGlvbmFibGUgc2l0dWF0aW9uYWwgYXdh cmVuZXNzIG92ZXIgYW4gb3JnYW5pemF0aW9uJ3MgSVQgc3lzdGVtcy4NCkF1dG9tYXRpb24gdG9v bHMgaW1wbGVtZW50aW5nIGEgY29udGludW91cyBtb25pdG9yaW5nIGFwcHJvYWNoIHdpbGwNCnV0 aWxpemUgdGhpcyBpbmZyYXN0cnVjdHVyZSB0b2dldGhlciB3aXRoIGV4aXN0aW5nIGFuZCBlbWVy Z2luZw0KZXZlbnQsIGluY2lkZW50IGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRv IHByb3ZpZGUNCnZpc2liaWxpdHkgaW50byB0aGUgc3RhdGUgb2YgYXNzZXRzLCB1c2VyIGFjdGl2 aXRpZXMgYW5kIG5ldHdvcmsNClxiZWhhdmlvci4gU3Rha2Vob2xkZXJzIHdpbGwgYmUgYWJsZSB0 byB1c2UgdGhlc2UgdG9vbHMgdG8gYWdncmVnYXRlDQphbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1 cml0eSBhbmQgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZQ0Kb3JnYW5pemF0aW9u cyBzZWN1cml0eSBwb3N0dXJlLCBxdWFudGlmeSBidXNpbmVzcyByaXNrLCBhbmQgbWFrZQ0KaW5m b3JtZWQgZGVjaXNpb25zIHRoYXQgc3VwcG9ydCBvcmdhbml6YXRpb25hbCBvYmplY3RpdmVzIHdo aWxlDQpwcm90ZWN0aW5nIGNyaXRpY2FsIGluZm9ybWF0aW9uLiBPcmdhbml6YXRpb25zIHdpbGwg YmUgYWJsZSB0byB1c2UNCnRoZXNlIHRvb2xzIHRvIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGluZm9y bWF0aW9uIHNoYXJpbmcgYWN0aXZpdGllcyB0bw0KY29sbGFib3JhdGUgd2l0aCBwYXJ0bmVycyB0 byBpZGVudGlmeSBhbmQgbWl0aWdhdGUgdGhyZWF0cy4gT3RoZXINCmF1dG9tYXRpb24gdG9vbHMg d2lsbCBiZSBhYmxlIHRvIGludGVncmF0ZSB3aXRoIHRoZXNlIGNhcGFiaWxpdGllcyB0bw0KZW5m b3JjZSBwb2xpY2llcyBiYXNlZCBvbiBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVuIHN5c3RlbXMs IHByZXZlbnQNCm1pc3VzZSBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFjayBzdXJmYWNlLg0K DQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8 bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NhY20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0K --_000_AC6674AB7BC78549BB231821ABF7A9AEB9178F2B95EMBX01WFjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hp dGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgYWdyZWUgd2l0 aCBLYXRobGVlbuKAmXMgY29tbWVudHMgb24gcXVlc3Rpb24gMyBidXQgSeKAmWQgYWxzbyBzdWdn ZXN0IHRoYXQgU0FDTSBwYXJ0aWNpcGFudHMgcmV2aWV3IHNlY3Rpb25zIDQuMi40LCA3LCBhbmQg MTAgb2YgUkZDIDIwMjYsIGVzcGVjaWFsbHkgc2VjdGlvbiA3LiBUaGF0IHNlY3Rpb24gY29udGFp bnMgYSBnb29kIGV4cGxhbmF0aW9uIG9mIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gb3BlbiBzdGFu ZGFyZHMgYW5kIG90aGVyIHNwZWNpZmljYXRpb25zLCBob3cgdGhlIElFVEYgc2hvdWxkIGRlYWwg d2l0aCB0aGVzZSBjYXRlZ29yaWVzIG9mIHNwZWNpZmljYXRpb25zLCBhbmQgd2h5LiBUaGlzIGlz c3VlIHNlZW1zIHRvIGJlIGVzcGVjaWFsbHkgY3JpdGljYWwgZm9yIFNBQ00uPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1vcmlhcnR5LCBLYXRobGVlbjxicj48Yj5TZW50 OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMTA6MDIgQU08YnI+PGI+VG86PC9iPiBk YXZpZC5vbGl2YUB2ZXJpem9uLm5ldDxicj48Yj5DYzo8L2I+IGRhdmlkLndhbHRlcm1pcmVAbmlz dC5nb3Y7IHNhY21AaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNl cy0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIERhdmlk LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkdyZWF0IHF1ZXN0aW9ucyAm YW1wOyB0aGFua3MgZm9yIHRoZSByZXZpZXchICZuYnNwO0knbGwgc3RhcnQgd2l0aCAjNCwgYnV0 IGFtIGxpbWl0ZWQgdG8gYW4gaVBob25lIGF0IHRoZSBtb21lbnQuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+U3RhbmRhcmRzIGRldmVsb3BtZW50IG9yZ2FuaXphdGlvbnMg KFNET3MpIGhhdmUgcmVxdWlyZW1lbnRzIHRvIGVuc3VyZSB0aGUgc3RhYmlsaXR5IG9mIGRvY3Vt ZW50cyBmb3IgJnF1b3Q7bm9ybWF0aXZlIHJlZmVyZW5jZXMmcXVvdDsuICZuYnNwO090aGVyIFNE T3MgYXJlIHZhbGlkIGxvY2F0aW9ucyBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZXMgYXMgdGhlIHJl ZmVyZW5jZSBpcyB0byBhIGRvY3VtZW50IGFzIG9wcG9zZWQgdG8gYSBsaW5rLiAmbmJzcDtBIGxp bmsgY2FuIGNoYW5nZS9kaXNhcHBlYXIsIHRoZSBjb250ZW50IGNhbiBjaGFuZ2UsIGFuZCB0aGVy ZWZvcmUgdGhlIGRvY3VtZW50IG1heSBub3QgYmUgc3RhYmxlLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgbmV4dCBzZXQgb2YgaXNzdWVzIGFyZSBhcm91 bmQgSVAuICZuYnNwO0lmIHRoZSBkb2N1bWVudCBpcyBhdCBhbiBTRE8sIHRoZSBJUCBpcyBjbGVh ciBldmVuIGlmIHRoZXJlIHdlcmUgSVAgZGlzY2xvc3VyZXMgc3VibWl0dGVkIGZvciB0aGF0IGRv Y3VtZW50LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JZiBh IGRvY3VtZW50IGlzIGhvc3RlZCBieSBhIHZlbmRvciwgZXZlbiBpZiB0aGF0IGRvY3VtZW50IGlz IG9wZW4sIGFkb3B0aW9uIHdvdWxkIGluY3JlYXNlIG9mIHNvbWV0aGluZyB0aGF0IGNhbiBiZSBz aGFyZWQgaWYgaXQgaXMgYXQgYW4gU0RPLiAmbmJzcDtUaGUgc3VibWl0dGVkIHN0aWxsIHNob3dz IHRoZSB0aG91Z2h0IGxlYWRlcnNoaXAgd2l0aCB0aGUgY29udHJpYnV0aW9uIGFuZCBvdGhlciB2 ZW5kb3JzIGNhbiBzaXRlIGNvbXBsaWFuY2UgdG8gYSBzdGFuZGFyZHMgZG9jdW1lbnQgYXMgb3Bw b3NlZCB0byBzb21ldGhpbmcgZnJvbSBhbm90aGVyIHZlbmRvci4gJm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RXhhbXBsZXMgb2Ygb3RoZXIgU0RPcyBpbmNsdWRl IElTTywgSUVFRSwgVzNDLCBJVFUsIE9BU0lTLCBldGMuICZuYnNwO1doaWxlIE5JU1QgaXMgbm90 IGFuIFNETyBpbiB0aGUgc2FtZSBzZW5zZSwgdGhlaXIgZG9jdW1lbnRzIGFyZSBhY2NlcHRlZCBh cyB2YWxpZCBub3JtYXRpdmUgcmVmZXJlbmNlcyBmcm9tIG1pc3Qgb2YgdGhlIFNET3MuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3RldmUgSGFubmEgb3Igb3RoZXJzIC0g ZG8geW91IGhhdmUgYW55IG90aGVyIHJlYXNvbnMgdG8gYWRkPzxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkkgaG9wZSB0aGlzIGlzIGhlbHBmdWwhPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+S2F0aGxlZW4mbmJzcDs8YnI+PGJyPlNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5PbiBTZXAgMTAsIDIwMTIsIGF0IDk6 NDUgQU0sICZxdW90OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCI+ZGF2 aWQub2xpdmFAdmVyaXpvbi5uZXQ8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQu b2xpdmFAdmVyaXpvbi5uZXQiPmRhdmlkLm9saXZhQHZlcml6b24ubmV0PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEwLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlRvIGFsbDo8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEwLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTAuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+VGhlIGRvY3VtZW50IGFwcGVhcnMgdmVyeSBn b29kIHRvIG1lLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTAuMHB0Jz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4wcHQnPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5Db21tZW50czo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4zLjMuMS7CoCBHb2FsIOKAnDwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz7CoMKgIENvbnRpbnVvdXMgYXNzZXNzbWVudCBvZiB0aGUgaW1wbGVtZW50YXRp b24gYW5kIGVmZmVjdGl2ZW5lc3Mgb2Y8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPsKgwqAg c2VjdXJpdHkgY29udHJvbHMgYmFzZWQgb24gbWFjaGluZSBwcm9jZXNzYWJsZSBjb250ZW50LuKA ncKgIFBIRU5PTUVOQUwhPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4w cHQnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjpibGFjayc+UGFyYWdyYXBoIDkuIEFja25vd2xlZGdlbWVudHNzOsKgIE1p c3BlbGxlZCB3b3JkIOKAnHRoaWVy4oCdIGNoYW5nZSB0byDigJx0aGVpcuKAnS48L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPlN1Z2dlc3Rpb25zOjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5UaGUgbWF0dXJlIHN0YXRlIG9mIGF1 dG9tYXRpb24gbWFrZXMgaXQgd29ydGh3aGlsZSB0byBpbnRyb2R1Y2UgbmV3IGFzc29jaWF0ZWQg dGVybXMgdG8gYWRkcmVzcyBmdXR1cmUgc2l0dWF0aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+QXV0b21hdGFibGUgKGFk dmVyYik6wqAgVGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nlc3MgdGhhdCBjYW4gYmUgaW1wbGVtZW50 ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1lY2hhbmlzbXMuwqAgRm9yIGluc3RhbmNlLCDi gJxjb25maWd1cmF0aW9uIGNvbXBsaWFuY2UgaXMgYW4gYXV0b21hdGFibGUgcHJvY2Vzc+KAnTwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJs YWNrJz5Ob24tYXV0b21hdGFibGUgKGFkdmVyYik6wqAgVGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nl c3MgdGhhdCBjYW5ub3QgYmUgaW1wbGVtZW50ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9uIG1l Y2hhbmlzbXMuwqAgRm9yIGluc3RhbmNlLCDigJxjb25mbGljdGluZ8KgIHBvbGljeSByZXNvbHV0 aW9uIGlzIGEgbm9uLWF1dG9tYXRhYmxlIHByb2Nlc3PigJ0uPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPlNlbWktYXV0b21hdGFi bGUgKGFkdmVyYik6wqAgVGhlIGNvbmRpdGlvbiBvZiBhIHByb2Nlc3Mgd2hpY2ggY2FuIGJlIHBh cnRpYWxseSBpbXBsZW1lbnRlZCBvciBzdXBwb3J0ZWQgd2l0aCBzZWN1cml0eSBhdXRvbWF0aW9u IG1lY2hhbmlzbXMuwqAgRm9yIGV4YW1wbGUg4oCcU29tZSBzZW1pLWF1dG9tYXRhYmxlIHByb2Nl c3NlcyBjYW4gYmUgc3VwcG9ydGVkIHdpdGggU0NBTSBzcGVjaWZpY2F0aW9ucyBzdWNoIGFzIHRo ZSBPcGVuIENoZWNrbGlzdCBJbnRlcmFjdGl2ZSBMYW5ndWFnZSAoT0NJTCnigJ0uPC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4wcHQnPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEwLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkEgZmV3IHF1ZXN0aW9ucyBj b21lIHRvIG1pbmQgKHBlcmhhcHMgZHVlIHRvIG15IGxhY2sgb2YgZmFtaWxpYXJpdHkgd2l0aCB0 aGUgbW9kdXMgb3BlcmFuZGkgb2YgdGhlIElFVEYpLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+MS48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+V2hh dCBoYXBwZW5zIHdpdGggdGhlIGRvY3VtZW50IGF0IHRoZSBlbmQgb2YgTWFyY2ggMjAxMz88L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFw dDt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4yLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuMHB0O2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5XaGVyZSBkb2VzIHRoZSBtb2RlbCBpbiBGaWd1cmUgMSBjb21lIGZyb20/PC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQ7dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+My48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+V2h5IGFyZSBvbmx5IG90aGVyIFJGQ3MgYWNjZXB0YWJsZSByZWZlcmVuY2Vz Pzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6 LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+NC48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+V2h5 IGFyZSBhY3JvbnltcyB3aXRob3V0IGRlZmluaXRpb25zIHVzZWQgKE9STSwgSVJNKT88L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4wcHQnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5EYXZpZCBPbGl2YTwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPk9uIDA5LzA3LzEyLCBXYWx0ZXJtaXJlLCBEYXZpZCBBLiZsdDs8 YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiI+ZGF2aWQud2FsdGVybWly ZUBuaXN0LmdvdjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SSBqdXN0 IHBvc3RlZCBhbiB1cGRhdGVkIHVzZSBjYXNlcyBkb2N1bWVudCAoc2VlIGJlbG93KSB0aGF0IHJl ZHVjZXMgdGhlIHNjb3BlIHRvIFVDMS0zIGFuZCBhZGRzIGEgbG90IG9mIG5ldyBjb250ZW50LiBN YW55IHRoYW5rcyB0byBBZGFtIE1vbnR2aWxsZSBmb3IgYWxsIGhpcyBoYXJkIHdvcmsgb24gdGhp cyByZXZpc2lvbi48YnI+PGJyPkNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC48YnI+PGJyPlNpbmNl cmVseSw8YnI+RGF2ZTxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTog PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dIDxicj5TZW50OiBGcmlkYXksIFNl cHRlbWJlciAwNywgMjAxMiAzOjQ5IFBNPGJyPlRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLjxicj5D YzogPGEgaHJlZj0ibWFpbHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tIj5hbW9udHZpbGxlQHRy aXB3aXJlLmNvbTwvYT48YnI+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyLnR4dDxicj48YnI+PGJyPkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyLnR4dDxicj5o YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIFdhbHRlcm1pcmUgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj48YnI+RmlsZW5hbWU6IGRyYWZ0LXdhbHRl cm1pcmUtc2FjbS11c2UtY2FzZXM8YnI+UmV2aXNpb246IDAyPGJyPlRpdGxlOiBBbmFseXNpcyBv ZiBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3JpbmcgKFNBQ00pIFVz ZSBDYXNlczxicj5DcmVhdGlvbiBkYXRlOiAyMDEyLTA5LTA3PGJyPldHIElEOiBJbmRpdmlkdWFs IFN1Ym1pc3Npb248YnI+TnVtYmVyIG9mIHBhZ2VzOiAyMzxicj5VUkw6IDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2Ut Y2FzZXMtMDIudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13 YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyLnR4dDwvYT48YnI+U3RhdHVzOiA8YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2Ut Y2FzZXMiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FsdGVybWlyZS1z YWNtLXVzZS1jYXNlczwvYT48YnI+SHRtbGl6ZWQ6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDI8L2E+PGJy PkRpZmY6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXdh bHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDI8L2E+PGJyPjxicj5BYnN0cmFj dDo8YnI+VGhpcyBkb2N1bWVudCBpZGVudGlmaWVzIGZvdW5kYXRpb25hbCB1c2UgY2FzZXMsIGRl cml2ZWQgZnVuY3Rpb25hbDxicj5jYXBhYmlsaXRpZXMgYW5kIHJlcXVpcmVtZW50cywgYXJjaGl0 ZWN0dXJhbCBjb21wb25lbnRzLCBhbmQgdGhlPGJyPnN1cHBvcnRpbmcgc3RhbmRhcmRzIG5lZWRl ZCB0byBkZWZpbmUgYW4gaW50ZXJvcGVyYWJsZSw8YnI+YXV0b21hdGlvblxpbmZyYXN0cnVjdHVy ZSByZXF1aXJlZCB0byBzdXBwb3J0IHRpbWVseSwgYWNjdXJhdGUgYW5kPGJyPmFjdGlvbmFibGUg c2l0dWF0aW9uYWwgYXdhcmVuZXNzIG92ZXIgYW4gb3JnYW5pemF0aW9uJ3MgSVQgc3lzdGVtcy48 YnI+QXV0b21hdGlvbiB0b29scyBpbXBsZW1lbnRpbmcgYSBjb250aW51b3VzIG1vbml0b3Jpbmcg YXBwcm9hY2ggd2lsbDxicj51dGlsaXplIHRoaXMgaW5mcmFzdHJ1Y3R1cmUgdG9nZXRoZXIgd2l0 aCBleGlzdGluZyBhbmQgZW1lcmdpbmc8YnI+ZXZlbnQsIGluY2lkZW50IGFuZCBuZXR3b3JrIG1h bmFnZW1lbnQgc3RhbmRhcmRzIHRvIHByb3ZpZGU8YnI+dmlzaWJpbGl0eSBpbnRvIHRoZSBzdGF0 ZSBvZiBhc3NldHMsIHVzZXIgYWN0aXZpdGllcyBhbmQgbmV0d29yazxicj5cYmVoYXZpb3IuIFN0 YWtlaG9sZGVycyB3aWxsIGJlIGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZTxi cj5hbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwgZGF0YSB0byB1 bmRlcnN0YW5kIHRoZTxicj5vcmdhbml6YXRpb25zIHNlY3VyaXR5IHBvc3R1cmUsIHF1YW50aWZ5 IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlPGJyPmluZm9ybWVkIGRlY2lzaW9ucyB0aGF0IHN1cHBv cnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGlsZTxicj5wcm90ZWN0aW5nIGNyaXRpY2Fs IGluZm9ybWF0aW9uLiBPcmdhbml6YXRpb25zIHdpbGwgYmUgYWJsZSB0byB1c2U8YnI+dGhlc2Ug dG9vbHMgdG8gYXVnbWVudCBhbmQgYXV0b21hdGUgaW5mb3JtYXRpb24gc2hhcmluZyBhY3Rpdml0 aWVzIHRvPGJyPmNvbGxhYm9yYXRlIHdpdGggcGFydG5lcnMgdG8gaWRlbnRpZnkgYW5kIG1pdGln YXRlIHRocmVhdHMuIE90aGVyPGJyPmF1dG9tYXRpb24gdG9vbHMgd2lsbCBiZSBhYmxlIHRvIGlu dGVncmF0ZSB3aXRoIHRoZXNlIGNhcGFiaWxpdGllcyB0bzxicj5lbmZvcmNlIHBvbGljaWVzIGJh c2VkIG9uIGh1bWFuIGRlY2lzaW9ucyB0byBoYXJkZW4gc3lzdGVtcywgcHJldmVudDxicj5taXN1 c2UgYW5kIHJlZHVjZSB0aGUgb3ZlcmFsbCBhdHRhY2sgc3VyZmFjZS48YnI+PGJyPjxicj48YnI+ PGJyPlRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5zYWNtIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5zYWNtIG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_AC6674AB7BC78549BB231821ABF7A9AEB9178F2B95EMBX01WFjnprn_-- From david.waltermire@nist.gov Wed Sep 12 05:57:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6544721F8584 for ; Wed, 12 Sep 2012 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.821 X-Spam-Level: X-Spam-Status: No, score=-4.821 tagged_above=-999 required=5 tests=[AWL=-1.779, BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, MIME_BASE64_TEXT=1.753, 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 wOUz3LJdFvn4 for ; Wed, 12 Sep 2012 05:57:06 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 872C121F8575 for ; Wed, 12 Sep 2012 05:57:05 -0700 (PDT) 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.1.379.0; Wed, 12 Sep 2012 08:56:47 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 12 Sep 2012 08:57:04 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Wed, 12 Sep 2012 08:57:02 -0400 Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4Q Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov> In-Reply-To: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov> 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_D7A0423E5E193F40BE6E94126930C4930BA25D8895MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:57:12 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA25D8895MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, GA. The details are below for anyone interested. At this point we need to complete preparations for the BoF. To be successful, we will need your participation in the BoF and your help getting ready. Here are meeting details if you are interested in making travel arrangements: http://www.ietf.org/meeting/85/index.html At this point we need additional drafts to be submitted to augment the agenda and support the BoF. I'd be happy to work with anyone interested in preparing drafts for any of the existing specifications in this area (e.g. CPE, Asset Identification, ARF, ASR, etc.) We should probably do a direct conversion of existing specifications for -00 versions before making any changes. The -00 deadline for the IETF 85 meeting is 10/15 with any updated drafts due a week later on 10/22. Any volunteers? We will also need speakers to present drafts. Please let me or Kathleen know if you are interested in making a short presentation. We also need to continue to refine the charter (included below) and use case documents. Any additional comments/changes would be appreciated. Sincerely, Dave From: Waltermire, David A. Sent: Monday, September 10, 2012 6:45 PM To: 'stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moriarty, Kathleen' Subject: SACM BoF Request Please find the our request for a WG formation BoF below. I have also included a draft charter that we have been developing with feedback from the SACM list. Please let me know if you have any questions or if you would like any additional details. Sincerely, Dave Waltermire -- BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from the SACM mailing list to solidify discussions on a proposed charter, use cases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this work is to address enterprise use cases. The working group will achieve this by consuming shared intelligence and continuing (with cooperation) the security automation work already performed by various organizations around the world. The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group are the emerging security automation interfaces and data formats relating to event management and continuous assessment. The continuous assessment capabilities enable organizational situational awareness through frequent snapshots of the operating state of their environment, with risk prioritized based on consumed information provided by shared intelligence (vulnerabilities, threats, etc.). By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making. This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing and aggregating device states and comparing these device states against expected values, and reporting on those results in a predefined or ad hoc manner. This area of focus provides for necessary language and data format specifications. 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking. This working group will achieve the following milestones in two phases: Phase One - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability - A Standards Track document specifying a control framework representation format. - A Standards Track document specifying benchmark configuration representation - An Informational document stating guidelines / requirements for specifying checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other content defined in this group with the NEA protocols Phase Two - Standards Track document specifying security automation/continuous assessment interfaces - A Standards Track document specifying communication protocols used for security automation and continuous assessment - A Standards Track document describing the messages and network protocols for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems --_000_D7A0423E5E193F40BE6E94126930C4930BA25D8895MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgc2VudCBpbiBhIHJlcXVlc3QgdG8gaG9sZCBh IFNBQ00gQm9GIGF0IHRoZSBJRVRGIDg1IG1lZXRpbmcgaW4gQXRsYW50YSwgR0EuJm5ic3A7IFRo ZSBkZXRhaWxzIGFyZSBiZWxvdyBmb3IgYW55b25lIGludGVyZXN0ZWQuJm5ic3A7IEF0IHRoaXMg cG9pbnQgd2UgbmVlZCB0byBjb21wbGV0ZSBwcmVwYXJhdGlvbnMgZm9yIHRoZSBCb0YuJm5ic3A7 IFRvIGJlIHN1Y2Nlc3NmdWwsIHdlIHdpbGwgbmVlZCB5b3VyIHBhcnRpY2lwYXRpb24gaW4gdGhl IEJvRiBhbmQgeW91ciBoZWxwIGdldHRpbmcgcmVhZHkuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+SGVyZSBhcmUgbWVldGluZyBkZXRhaWxzIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBt YWtpbmcgdHJhdmVsIGFycmFuZ2VtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODUvaW5kZXguaHRtbCI+aHR0cDov L3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg1L2luZGV4Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+QXQgdGhpcyBwb2ludCB3ZSBuZWVkIGFkZGl0aW9uYWwgZHJhZnRzIHRvIGJl IHN1Ym1pdHRlZCB0byBhdWdtZW50IHRoZSBhZ2VuZGEgYW5kIHN1cHBvcnQgdGhlIEJvRi4mbmJz cDsgSSYjODIxNztkIGJlIGhhcHB5IHRvIHdvcmsgd2l0aCBhbnlvbmUgaW50ZXJlc3RlZCBpbiBw cmVwYXJpbmcgZHJhZnRzIGZvciBhbnkgb2YgdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGlu IHRoaXMgYXJlYSAoZS5nLiBDUEUsIEFzc2V0IElkZW50aWZpY2F0aW9uLCBBUkYsIEFTUiwgZXRj LikmbmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5IGRvIGEgZGlyZWN0IGNvbnZlcnNpb24gb2YgZXhp c3Rpbmcgc3BlY2lmaWNhdGlvbnMgZm9yIC0wMCB2ZXJzaW9ucyBiZWZvcmUgbWFraW5nIGFueSBj aGFuZ2VzLiZuYnNwOyBUaGUgLTAwIGRlYWRsaW5lIGZvciB0aGUgSUVURiA4NSBtZWV0aW5nIGlz IDEwLzE1IHdpdGggYW55IHVwZGF0ZWQgZHJhZnRzIGR1ZSBhIHdlZWsgbGF0ZXIgb24gMTAvMjIu Jm5ic3A7IEFueSB2b2x1bnRlZXJzPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XZSB3 aWxsIGFsc28gbmVlZCBzcGVha2VycyB0byBwcmVzZW50IGRyYWZ0cy4mbmJzcDsgUGxlYXNlIGxl dCBtZSBvciBLYXRobGVlbiBrbm93IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBtYWtpbmcgYSBz aG9ydCBwcmVzZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgYWxzbyBu ZWVkIHRvIGNvbnRpbnVlIHRvIHJlZmluZSB0aGUgY2hhcnRlciAoaW5jbHVkZWQgYmVsb3cpIGFu ZCB1c2UgY2FzZSBkb2N1bWVudHMuIEFueSBhZGRpdGlvbmFsIGNvbW1lbnRzL2NoYW5nZXMgd291 bGQgYmUgYXBwcmVjaWF0ZWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2lu Y2VyZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFdhbHRlcm1pcmUsIERhdmlk IEEuIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgNjo0NSBQTTxi cj48Yj5Ubzo8L2I+ICdzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllJzsgJ3R1cm5lcnNAaWVjYS5j b20nOyAnTW9yaWFydHksIEthdGhsZWVuJzxicj48Yj5TdWJqZWN0OjwvYj4gU0FDTSBCb0YgUmVx dWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlBsZWFzZSBmaW5kIHRoZSBv dXIgcmVxdWVzdCBmb3IgYSBXRyBmb3JtYXRpb24gQm9GIGJlbG93LiZuYnNwOyBJIGhhdmUgYWxz byBpbmNsdWRlZCBhIGRyYWZ0IGNoYXJ0ZXIgdGhhdCB3ZSBoYXZlIGJlZW4gZGV2ZWxvcGluZyB3 aXRoIGZlZWRiYWNrIGZyb20gdGhlIFNBQ00gbGlzdC4mbmJzcDsgUGxlYXNlIGxldCBtZSBrbm93 IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgb3IgaWYgeW91IHdvdWxkIGxpa2UgYW55IGFkZGl0 aW9uYWwgZGV0YWlscy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+RGF2ZSBXYWx0ZXJtaXJlPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tLTxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+Qk9GIGZ1bGwgbmFtZTogU2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGlu dW91cyBNb25pdG9yaW5nIFtTQUNNXTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5B UkVBOiBTZWN1cml0eTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5CT0YgQ2hhaXJz OiBLYXRobGVlbiBNb3JpYXJ0eSAoPGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5QGVt Yy5jb20iPmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb208L2E+KTxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2aWQgV2FsdGVybWlyZSAoPGEgaHJlZj0ibWFpbHRv OmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L2E+ KTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BZ2VuZGE6PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD4qIFJldmlldyB0aGUgZHJhZnQgY2hhcnRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD4qIFJldmlldyBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAyIDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4qIFJldmlldyBkcmFmdHMgc3VibWl0dGVkIGluIHN1 cHBvcnQgb2YgdGhlIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7IC0gZHJhZnQtd2FsdGVybWlyZS1jb250ZW50LXJlcG9zaXRvcnktMDA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IC0gTW9yZSBleHBlY3RlZCBiZWZvcmUgLTAwIGRl YWRsaW5lPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5GdWxsIERlc2NyaXB0aW9uIG9mIEJPRjogVGhlIFNBQ00g Qm9GIGlzIGludGVuZGVkIHRvIHByb2dyZXNzIHRoZSB3b3JrIGZyb20gdGhlIFNBQ00gbWFpbGlu ZyBsaXN0IHRvIHNvbGlkaWZ5IGRpc2N1c3Npb25zIG9uIGEgcHJvcG9zZWQgY2hhcnRlciwgdXNl IGNhc2VzIGFuZCBtaWxlc3RvbmVzIGluIHN1cHBvcnQgb2YgbW92aW5nIHRvIGFuIElFVEYgd29y a2luZyBncm91cC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkNPTkZMSUNUUyB0byBhdm9pZDogU0FBRywgTUlM RTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5FeHBlY3RlZCBBdHRlbmRhbmNlOiA0 MCwgbm90IHN1cmUgd2hhdCB0aGUgcHJldmlvdXMgYXR0ZW5kYW5jZSB3YXM/PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNwZWNpYWwgUmVxdWVzdHM6IE1lZXRlY2hvIHN1cHBvcnQ8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+TnVtYmVyIG9mIHNlc3Npb25zOiAxPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkxlbmd0aCBvZiBzZXNzaW9uOiAyIGhvdXJz PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5EcmFmdCBDaGFydGVyOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+UHJvcG9zZWQg V29ya2luZyBHcm91cCBDaGFydGVyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5DaGFpcnM6PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRCRDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5UQkQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNlY3VyaXR5IEFyZWEgRGlyZWN0b3JzOjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RlcGhlbiBG YXJyZWxsICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+Jmd0OzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+U2VjdXJpdHkgQXJlYSBBZHZpc29yOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIj50dXJuZXJzQGllY2EuY29tPC9hPiZndDs8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPk1haWxpbmcgTGlzdHM6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHZW5lcmFsIERpc2N1c3Npb246IDxhIGhyZWY9Im1h aWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG8gU3Vic2NyaWJlOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FjbSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBcmNoaXZlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2FjbSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3NhY208L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5EZXNjcmlwdGlvbiBvZiBXb3JraW5n IEdyb3VwPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5TZWN1cmluZyBpbmZvcm1hdGlvbiBhbmQgdGhlIHN5c3Rl bXMgdGhhdCBzdG9yZSwgcHJvY2VzcywgYW5kIHRyYW5zbWl0IHRoYXQgaW5mb3JtYXRpb24gaGFz IGJlY29tZSBhIGNoYWxsZW5naW5nIHRhc2sgZm9yIG9yZ2FuaXphdGlvbnMgb2YgYWxsIHNpemVz LCBhbmQgd2UgZmluZCB0aGF0IHNlY3VyaXR5IHByYWN0aXRpb25lcnMgc3BlbmQgbW9zdCBvZiB0 aGVpciB0aW1lIG9uIG1hbnVhbCBwcm9jZXNzZXMgcmVsZWdhdGluZyB0aGVtIHRvIGluZWZmZWN0 aXZlbmVzcy4gU2VjdXJpdHkgYXV0b21hdGlvbiB0byB2ZXJpZnkgc3lzdGVtIGNvbmZpZ3VyYXRp b25zIHdpdGggdGhlIGFiaWxpdHkgdG8gcHJpb3JpdGl6ZSByaXNrIGJhc2VkIG9uIGluY3JlYXNl ZCBzaXR1YXRpb25hbCBhd2FyZW5lc3MgZnJvbSBzaGFyZWQgaW50ZWxsaWdlbmNlIGlzIHRoZSBr ZXkgdG8gZXNjYXBpbmcgdGhpcyBydXQuIFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Ag c2VjdXJpdHkgYXV0b21hdGlvbiBzdGFuZGFyZHMgaW4gc3VwcG9ydCBvZiBpbmZvcm1hdGlvbiBz ZWN1cml0eSBwcm9jZXNzZXMgYW5kIHByYWN0aWNlcyB3aGVyZSBwcmFjdGljYWwuIFRoZXNlIHN0 YW5kYXJkcyB3aWxsIGhlbHAgc2VjdXJpdHkgcHJhY3RpdGlvbmVycyB0byBiZSBiZXR0ZXIgdXRp bGl6ZWQgd2l0aGluIHRoZWlyIG9yZ2FuaXphdGlvbnMgYnkgYXV0b21hdGluZyByb3V0aW5lIHRh c2tzIHJlbGF0ZWQgdG8gZW5kcG9pbnQgYW5kIHNlcnZlciBzZWN1cml0eSBzbyB0aGF0IHByYWN0 aXRpb25lcnMgY2FuIGZvY3VzIG9uIG1vcmUgYWR2YW5jZWQgdGFza3MuIFRoZSBpbml0aWFsIGZv Y3VzIG9mIHRoaXMgd29yayBpcyB0byBhZGRyZXNzIGVudGVycHJpc2UgdXNlIGNhc2VzLiA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGlzIGJ5IGNvbnN1 bWluZyBzaGFyZWQgaW50ZWxsaWdlbmNlIGFuZCBjb250aW51aW5nICh3aXRoIGNvb3BlcmF0aW9u KSB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiB3b3JrIGFscmVhZHkgcGVyZm9ybWVkIGJ5IHZhcmlv dXMgb3JnYW5pemF0aW9ucyBhcm91bmQgdGhlIHdvcmxkLiZuYnNwOyBUaGUgaW5pdGlhbCB3b3Jr IGhhcyBiZWVuIGZydWl0ZnVsLCBhbmQgdGhlIGRhdGEgZm9ybWF0cyBwcmV2aW91c2x5IHB1Ymxp c2hlZCBhcmUgcmVhZHkgZm9yIGV4cGFuc2lvbiBvbiB0aGUgaW50ZXJuYXRpb25hbCBzdGFnZS4g T2YgcGFydGljdWxhciBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRoZSBzZWN1 cml0eSBhdXRvbWF0aW9uIHNwZWNpZmljYXRpb25zIHN1cHBvcnRpbmcgYXNzZXQsIGNoYW5nZSwg Y29uZmlndXJhdGlvbiwgYW5kIHZ1bG5lcmFiaWxpdHkgbWFuYWdlbWVudC4gT2YgYWRkaXRpb25h bCBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRoZSBlbWVyZ2luZyBzZWN1cml0 eSBhdXRvbWF0aW9uIGludGVyZmFjZXMgYW5kIGRhdGEgZm9ybWF0cyByZWxhdGluZyB0byBldmVu dCBtYW5hZ2VtZW50IGFuZCBjb250aW51b3VzIGFzc2Vzc21lbnQuJm5ic3A7IFRoZSBjb250aW51 b3VzIGFzc2Vzc21lbnQgY2FwYWJpbGl0aWVzIGVuYWJsZSBvcmdhbml6YXRpb25hbCBzaXR1YXRp b25hbCBhd2FyZW5lc3MgdGhyb3VnaCBmcmVxdWVudCBzbmFwc2hvdHMgb2YgdGhlIG9wZXJhdGlu ZyBzdGF0ZSBvZiB0aGVpciBlbnZpcm9ubWVudCwgd2l0aCByaXNrIHByaW9yaXRpemVkIGJhc2Vk IG9uIGNvbnN1bWVkIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHNoYXJlZCBpbnRlbGxpZ2VuY2Ug KHZ1bG5lcmFiaWxpdGllcywgdGhyZWF0cywgZXRjLikuPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5CeSB1bmRl cnRha2luZyB0aGlzIHdvcmssIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBj YXRlZ29yaWVzIG9mIHByb2JsZW1zIGluIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIGRvbWFpbjog ZGVmaW5pbmcgZXhwcmVzc2lvbnMgZm9yIHBhcnRpY3VsYXIgZG9tYWluIGNvbmNlcHRzIChpLmUu IGRhdGEgZm9ybWF0cyksIGVzdGFibGlzaGluZyBhIHN0YW5kYXJkcy1iYXNlZCBmb3VuZGF0aW9u IHN1cHBvcnRpbmcgdGhlIGN1cmF0aW9uIGFuZCBleGNoYW5nZSBvZiBzZWN1cml0eSBhdXRvbWF0 aW9uIGNvbnRlbnQgY29sbGVjdGlvbnMgaW4gY29udGVudCByZXBvc2l0b3JpZXMsIGFuZCBlbmFi bGluZyBpbnRlcm9wZXJhYmlsaXR5IHRocm91Z2ggdGhlIGRldmVsb3BtZW50IGFuZCB1c2Ugb2Yg c3RhbmRhcmQgaW50ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzLiBDb250ZW50 IGJhc2VkIG9uIHJpY2ggZGF0YSBzdGFuZGFyZHMgYW5kIHByb3RvY29scyB3aWxsIHByb3ZpZGUg dGhlIGF1dGhvcml0YXRpdmUgaW5zdHJ1Y3Rpb25zIG5lZWRlZCBieSBkYXRhLWRyaXZlbiB0b29s cyB0byBlbmFibGUgdGhlIGF1dG9tYXRlZCBjb2xsZWN0aW9uIGFuZCBleGNoYW5nZSBvZiBjb25m aWd1cmF0aW9uIGFuZCB2dWxuZXJhYmlsaXR5IGRhdGEgcGVydGFpbmluZyB0byBlbnRlcnByaXNl IGFzc2V0cy4gSW5mb3JtYXRpb24gcHJvZHVjZWQgYnkgdGhlc2UgdG9vbHMgd2lsbCBwcm92aWRl IGFjY3VyYXRlIGFuZCB0aW1lbHkgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGluIHN1cHBvcnQgb2Yg b3JnYW5pemF0aW9uYWwgZGVjaXNpb24gbWFraW5nLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgd29y a2luZyBncm91cCB3aWxsIHByb3ZpZGUgc29sdXRpb25zIHRvIHRoZXNlIGNhdGVnb3JpZXMgb2Yg cHJvYmxlbXMgYW5kIHRoZSBtYWluIGFyZWFzIG9mIGZvY3VzIGZvciB0aGlzIHdvcmtpbmcgZ3Jv dXAgYXJlIGRlc2NyaWJlZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+MS4gRGVmaW5lLCBl aXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRvcHRpb24sIG9yIGNyZWF0aW9uLCBhIHNl dCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYXNzZXNz aW5nIGFuZCBhZ2dyZWdhdGluZyBkZXZpY2Ugc3RhdGVzIGFuZCBjb21wYXJpbmcgdGhlc2UgZGV2 aWNlIHN0YXRlcyBhZ2FpbnN0IGV4cGVjdGVkIHZhbHVlcywgYW5kIHJlcG9ydGluZyBvbiB0aG9z ZSByZXN1bHRzIGluIGEgcHJlZGVmaW5lZCBvciBhZCBob2MgbWFubmVyLiZuYnNwOyBUaGlzIGFy ZWEgb2YgZm9jdXMgcHJvdmlkZXMgZm9yIG5lY2Vzc2FyeSBsYW5ndWFnZSBhbmQgZGF0YSBmb3Jt YXQgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4yLiBEZWZpbmUsIGVpdGhlciBieSBu b3JtYXRpdmUgcmVmZXJlbmNlLCBhZG9wdGlvbiwgb3IgY3JlYXRpb24sIGEgc2V0IG9mIHN0YW5k YXJkcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGNvbnRpbnVvdXNseSBhc3Nlc3MgYW5kIHJlcG9ydCBv biB0aGUgc3RhdGUgb2Ygc3lzdGVtcywgY29tcG9zZWQgb2YgbWFueSBkaWZmZXJlbnQgdHlwZXMg b2YgZGV2aWNlcyBhbmQgbmV0d29ya3MsIG9wZXJhdGVkIGJ5IHZhcnlpbmcgcGVyc29ubmVsLCB0 byBlbnN1cmUgc2VjdXJpdHkgcHJvY2VzcyBlZmZlY3RpdmVuZXNzIGluIGEgcHJlLWRlZmluZWQg b3IgYWQtaG9jIG1hbm5lci4mbmJzcDsgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBp bnRlZ3JhdGlvbiBwcm90b2NvbHMgc3VwcG9ydGluZyBwbHVnIGFuZCBwbGF5IGNvbnRpbnVvdXMg YXNzZXNzbWVudCBhbmQgc2VjdXJpdHkgYXV0b21hdGlvbiBuZXR3b3JraW5nLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+VGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGUgZm9sbG93aW5nIG1pbGVz dG9uZXMgaW4gdHdvIHBoYXNlczo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlBoYXNlIE9uZTxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNp ZnlpbmcgYXNzZXQgZGVzY3JpcHRpb24gZm9ybWF0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhc3NldCBpZGVu dGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRz IFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gbmFtaW5nPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWlu ZyBwbGF0Zm9ybSBtYXRjaGluZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEg U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gYXBwbGljYWJpbGl0 eTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRv Y3VtZW50IHNwZWNpZnlpbmcgYSBjb250cm9sIGZyYW1ld29yayByZXByZXNlbnRhdGlvbiBmb3Jt YXQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBiZW5jaG1hcmsgY29uZmlndXJhdGlvbiByZXByZXNlbnRhdGlv bjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEFuIEluZm9ybWF0aW9uYWwgZG9j dW1lbnQgc3RhdGluZyBndWlkZWxpbmVzIC8gcmVxdWlyZW1lbnRzIGZvciBzcGVjaWZ5aW5nIGNo ZWNraW5nIGxhbmd1YWdlczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIFN0YW5k YXJkcyBUcmFjayBkb2N1bWVudHMgc3BlY2lmeWluZyBkZXZpY2Ugc3RhdGUgY2hlY2tpbmcgbGFu Z3VhZ2VzPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJh Y2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhbiBpbnRlcnJvZ2F0aXZlIGNoZWNraW5nIGxhbmd1YWdl IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRv Y3VtZW50IHNwZWNpZnlpbmcgYXNzZXQgcmVwb3J0aW5nIGluZm9ybWF0aW9uIDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmli aW5nIGhvdyB0byB1c2UgdGhlIGxhbmd1YWdlcyBhbmQgb3RoZXIgY29udGVudCBkZWZpbmVkIGlu IHRoaXMgZ3JvdXAgd2l0aCB0aGUgTkVBIHByb3RvY29sczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+UGhhc2Ug VHdvPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gU3RhbmRhcmRzIFRyYWNrIGRv Y3VtZW50IHNwZWNpZnlpbmcgc2VjdXJpdHkgYXV0b21hdGlvbi9jb250aW51b3VzIGFzc2Vzc21l bnQgaW50ZXJmYWNlczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRh cmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgdXNl ZCBmb3Igc2VjdXJpdHkgYXV0b21hdGlvbiBhbmQgY29udGludW91cyBhc3Nlc3NtZW50PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQg ZGVzY3JpYmluZyB0aGUgbWVzc2FnZXMgYW5kIG5ldHdvcmsgcHJvdG9jb2xzIGZvciBkaXN0cmli dXRpbmcgc2VjdXJpdHkgYXV0b21hdGlvbiBjb250ZW50Jm5ic3A7IChjb250ZW50IHJlcG9zaXRv cnkpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgZGVzY3JpYmluZyBwcm90b2NvbHMgYW5kIGRhdGEgZm9ybWF0cyBmb3Igc2VjdXJl bHkgc2hhcmluZyBkeW5hbWljIG5ldHdvcmsgc3RhdGUgaW5mb3JtYXRpb24gYW1vbmcgc2VjdXJp dHkgc3lzdGVtczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930BA25D8895MBCLUSTERxcha_-- From adam@stoicsecurity.com Wed Sep 12 07:16:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3921F85F3 for ; Wed, 12 Sep 2012 07:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, MIME_QP_LONG_LINE=1.396] 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 2s-bVBfYlAh7 for ; Wed, 12 Sep 2012 07:16:37 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by ietfa.amsl.com (Postfix) with SMTP id EB19C21F8569 for ; Wed, 12 Sep 2012 07:16:36 -0700 (PDT) Received: (qmail 7730 invoked from network); 12 Sep 2012 14:16:35 -0000 Received: from unknown (50.137.24.91) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 12 Sep 2012 14:16:34 -0000 References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-89D4793C-0197-4674-820E-116A47468BFA Message-Id: <80513180-F438-42C2-9C99-304AFD6856DC@stoicsecurity.com> X-Mailer: iPhone Mail (9B206) From: "Adam W. Montville" Date: Wed, 12 Sep 2012 07:16:32 -0700 To: "Waltermire, David A." Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:16:38 -0000 --Apple-Mail-89D4793C-0197-4674-820E-116A47468BFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you Dave! I'd be happy to pick up Asset ID. Sent from my iPhone On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." wrote: > I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, G= A. The details are below for anyone interested. At this point we need to c= omplete preparations for the BoF. To be successful, we will need your parti= cipation in the BoF and your help getting ready. > =20 > Here are meeting details if you are interested in making travel arrangemen= ts: > =20 > http://www.ietf.org/meeting/85/index.html > =20 > At this point we need additional drafts to be submitted to augment the age= nda and support the BoF. I=E2=80=99d be happy to work with anyone intereste= d in preparing drafts for any of the existing specifications in this area (e= .g. CPE, Asset Identification, ARF, ASR, etc.) We should probably do a dire= ct conversion of existing specifications for -00 versions before making any c= hanges. The -00 deadline for the IETF 85 meeting is 10/15 with any updated d= rafts due a week later on 10/22. Any volunteers? > =20 > We will also need speakers to present drafts. Please let me or Kathleen k= now if you are interested in making a short presentation. > =20 > We also need to continue to refine the charter (included below) and use ca= se documents. Any additional comments/changes would be appreciated. > =20 > Sincerely, > Dave > =20 > From: Waltermire, David A.=20 > Sent: Monday, September 10, 2012 6:45 PM > To: 'stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moriarty, Kathleen' > Subject: SACM BoF Request > =20 > Please find the our request for a WG formation BoF below. I have also inc= luded a draft charter that we have been developing with feedback from the SA= CM list. Please let me know if you have any questions or if you would like a= ny additional details. > =20 > Sincerely, > Dave Waltermire > =20 > -- > =20 > BOF full name: Security Automation and Continuous Monitoring [SACM] > AREA: Security > BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) > Agenda: > =20 > * Review the draft charter > * Review draft-waltermire-sacm-use-cases-02 > * Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > =20 > Full Description of BOF: The SACM BoF is intended to progress the work fro= m the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. > =20 > CONFLICTS to avoid: SAAG, MILE > Expected Attendance: 40, not sure what the previous attendance was? > Special Requests: Meetecho support > Number of sessions: 1 > Length of session: 2 hours > =20 > Draft Charter: > =20 > Proposed Working Group Charter > =20 > Chairs: > TBD > TBD > =20 > Security Area Directors: > Stephen Farrell > Sean Turner > =20 > Security Area Advisor: > Sean Turner > =20 > Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > =20 > Description of Working Group > =20 > Securing information and the systems that store, process, and transmit tha= t information has become a challenging task for organizations of all sizes, a= nd we find that security practitioners spend most of their time on manual pr= ocesses relegating them to ineffectiveness. Security automation to verify sy= stem configurations with the ability to prioritize risk based on increased s= ituational awareness from shared intelligence is the key to escaping this ru= t. This working group will develop security automation standards in support o= f information security processes and practices where practical. These standa= rds will help security practitioners to be better utilized within their orga= nizations by automating routine tasks related to endpoint and server securit= y so that practitioners can focus on more advanced tasks. The initial focus o= f this work is to address enterprise use cases. > =20 > The working group will achieve this by consuming shared intelligence and c= ontinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitfu= l, and the data formats previously published are ready for expansion on the i= nternational stage. Of particular interest to this working group are the sec= urity automation specifications supporting asset, change, configuration, and= vulnerability management. Of additional interest to this working group are t= he emerging security automation interfaces and data formats relating to even= t management and continuous assessment. The continuous assessment capabilit= ies enable organizational situational awareness through frequent snapshots o= f the operating state of their environment, with risk prioritized based on c= onsumed information provided by shared intelligence (vulnerabilities, threat= s, etc.). > =20 > By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for parti= cular domain concepts (i.e. data formats), establishing a standards-based fo= undation supporting the curation and exchange of security automation content= collections in content repositories, and enabling interoperability through t= he development and use of standard interfaces and communications protocols. C= ontent based on rich data standards and protocols will provide the authorita= tive instructions needed by data-driven tools to enable the automated collec= tion and exchange of configuration and vulnerability data pertaining to ente= rprise assets. Information produced by these tools will provide accurate and= timely situational awareness in support of organizational decision making. > =20 > This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: > =20 > 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing and aggregating devic= e states and comparing these device states against expected values, and repo= rting on those results in a predefined or ad hoc manner. This area of focus= provides for necessary language and data format specifications. > =20 > 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of s= ystems, composed of many different types of devices and networks, operated b= y varying personnel, to ensure security process effectiveness in a pre-defin= ed or ad-hoc manner. This area of focus provides for integration protocols s= upporting plug and play continuous assessment and security automation networ= king. > =20 > This working group will achieve the following milestones in two phases: > =20 > Phase One > - A Standards Track document specifying asset description format > - A Standards Track document specifying asset identification > - A Standards Track document specifying platform naming > - A Standards Track document specifying platform matching > - A Standards Track document specifying platform applicability > - A Standards Track document specifying a control framework representation= format. > - A Standards Track document specifying benchmark configuration representa= tion > - An Informational document stating guidelines / requirements for specifyi= ng checking languages > - Standards Track documents specifying device state checking languages > - A Standards Track document specifying an interrogative checking language= > - A Standards Track document specifying asset reporting information > - Standards Track document describing how to use the languages and other c= ontent defined in this group with the NEA protocols > =20 > Phase Two > - Standards Track document specifying security automation/continuous asses= sment interfaces > - A Standards Track document specifying communication protocols used for s= ecurity automation and continuous assessment > - A Standards Track document describing the messages and network protocols= for distributing security automation content (content repository) > - A Standards Track document describing protocols and data formats for sec= urely sharing dynamic network state information among security systems > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail-89D4793C-0197-4674-820E-116A47468BFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you Dave!
=
I'd be happy to pick up Asset ID.

Sent from my i= Phone

On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." <= david.waltermire@nist.gov&g= t; wrote:

I sent in a request to hold a SACM Bo= F at the IETF 85 meeting in Atlanta, GA.  The details are below for any= one interested.  At this point we need to complete preparations for the= BoF.  To be successful, we will need your participation in the BoF and= your help getting ready.

 

Here are meeting details if you are interested i= n making travel arrangements:

 

http://www.ietf.org/meeting/85/index.html

 

At this point we= need additional drafts to be submitted to augment the agenda and support th= e BoF.  I=E2=80=99d be happy to work with anyone interested in preparin= g drafts for any of the existing specifications in this area (e.g. CPE, Asse= t Identification, ARF, ASR, etc.)  We should probably do a direct conve= rsion of existing specifications for -00 versions before making any changes.=   The -00 deadline for the IETF 85 meeting is 10/15 with any updated dr= afts due a week later on 10/22.  Any volunteers?

=

 

We will also need s= peakers to present drafts.  Please let me or Kathleen know if you are i= nterested in making a short presentation.

 

We also need to continue to ref= ine the charter (included below) and use case documents. Any additional comm= ents/changes would be appreciated.

 

Sincerely,

Dave

 

From: Waltermire, David A.
Sent: Monday, September 10, 20= 12 6:45 PM
To: 'steph= en.farrell@cs.tcd.ie'; 'turners@ieca= .com'; 'Moriarty, Kathleen'
Subject: SACM BoF Request

 

Please find the our request for a WG formation BoF below.&nb= sp; I have also included a draft charter that we have been developing with f= eedback from the SACM list.  Please let me know if you have any questio= ns or if you would like any additional details.

 

Sincerely,

Dave Waltermire

 

--

 

BOF full name: Securit= y Automation and Continuous Monitoring [SACM]

AREA: Security

BOF Chairs: Kathl= een Moriarty (kathleen.moriarty= @emc.com)

    &= nbsp;       David Waltermire (david.waltermire@nist.gov)

Agenda:

 = ;

* Review the draft charter

<= p class=3D"MsoNormal">* Review draft-waltermire-sacm-use-cases-02

* Review drafts submitted in support of the char= ter

  - draft-waltermire-content-r= epository-00

  - More expected bef= ore -00 deadline

 

<= p class=3D"MsoNormal">Full Description of BOF: The SACM BoF is intended to p= rogress the work from the SACM mailing list to solidify discussions on a pro= posed charter, use cases and milestones in support of moving to an IETF work= ing group.

 

CONFLICTS to avoid: SAAG, MILE

Expected Attendance: 40, not sure what the previous attendance was?<= o:p>

Special Requests: Meetecho support=

Number of sessions: 1

Length of session: 2 hours

 

Draft Charter:

 

Proposed= Working Group Charter

 

Chairs:

TBD=

TBD

 

Security Area Directors:=

     Stephen Farrell &l= t;stephen.farrell@cs.tcd.ie= >

     Sean Turn= er <turners@ieca.com>

 

Sec= urity Area Advisor:

   &= nbsp; Sean Turner <turners@ieca.com>

 

Mailing Lists:

  =    General Discussion: sacm@ietf.= org

     To Sub= scribe:       http://www.ietf.org/mailman/listinfo/sacm

     Archive:  &n= bsp;         http://www.ietf.org/mail-archive/web/sacm=

 

Description of Working Group

 

Securing information and the systems= that store, process, and transmit that information has become a challenging= task for organizations of all sizes, and we find that security practitioner= s spend most of their time on manual processes relegating them to ineffectiv= eness. Security automation to verify system configurations with the ability t= o prioritize risk based on increased situational awareness from shared intel= ligence is the key to escaping this rut. This working group will develop sec= urity automation standards in support of information security processes and p= ractices where practical. These standards will help security practitioners t= o be better utilized within their organizations by automating routine tasks r= elated to endpoint and server security so that practitioners can focus on mo= re advanced tasks. The initial focus of this work is to address enterprise u= se cases.

 

The working group will achieve this by consuming shared inte= lligence and continuing (with cooperation) the security automation work alre= ady performed by various organizations around the world.  The initial w= ork has been fruitful, and the data formats previously published are ready f= or expansion on the international stage. Of particular interest to this work= ing group are the security automation specifications supporting asset, chang= e, configuration, and vulnerability management. Of additional interest to th= is working group are the emerging security automation interfaces and data fo= rmats relating to event management and continuous assessment.  The cont= inuous assessment capabilities enable organizational situational awareness t= hrough frequent snapshots of the operating state of their environment, with r= isk prioritized based on consumed information provided by shared intelligenc= e (vulnerabilities, threats, etc.).

 

By undertaking this work, we recogn= ize that there are multiple categories of problems in the security automatio= n domain: defining expressions for particular domain concepts (i.e. data for= mats), establishing a standards-based foundation supporting the curation and= exchange of security automation content collections in content repositories= , and enabling interoperability through the development and use of standard i= nterfaces and communications protocols. Content based on rich data standards= and protocols will provide the authoritative instructions needed by data-dr= iven tools to enable the automated collection and exchange of configuration a= nd vulnerability data pertaining to enterprise assets. Information produced b= y these tools will provide accurate and timely situational awareness in supp= ort of organizational decision making.

 

This working group will provide= solutions to these categories of problems and the main areas of focus for t= his working group are described as follows:

 

1. Define, either by normat= ive reference, adoption, or creation, a set of standards that can be used fo= r the purpose of assessing and aggregating device states and comparing these= device states against expected values, and reporting on those results in a p= redefined or ad hoc manner.  This area of focus provides for necessary l= anguage and data format specifications.

 

2. Define, either by normative r= eference, adoption, or creation, a set of standards that can be used to cont= inuously assess and report on the state of systems, composed of many differe= nt types of devices and networks, operated by varying personnel, to ensure s= ecurity process effectiveness in a pre-defined or ad-hoc manner.  This a= rea of focus provides for integration protocols supporting plug and play con= tinuous assessment and security automation networking.

 

This working gro= up will achieve the following milestones in two phases:

 

Phase One<= /o:p>

- A Standards Track document specifying asse= t description format

- A Standards Trac= k document specifying asset identification

- A Standards Track document specifying platform naming

- A Standards Track document specifying platform matchi= ng

- A Standards Track document specify= ing platform applicability

- A Standard= s Track document specifying a control framework representation format.<= /o:p>

- A Standards Track document specifying benc= hmark configuration representation

- An= Informational document stating guidelines / requirements for specifying che= cking languages

- Standards Track docum= ents specifying device state checking languages

- A Standards Track document specifying an interrogative checking l= anguage

- A Standards Track document s= pecifying asset reporting information

= - Standards Track document describing how to use the languages and other con= tent defined in this group with the NEA protocols

 

Phase Two<= /p>

- Standards Track document specifying security aut= omation/continuous assessment interfaces

- A Standards Track document specifying communication protocols used for s= ecurity automation and continuous assessment

- A Standards Track document describing the messages and network proto= cols for distributing security automation content  (content repository)=

- A Standards Track document describin= g protocols and data formats for securely sharing dynamic network state info= rmation among security systems

&nb= sp;

_= ______________________________________________
sacm mailing l= ist
sacm@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sacm
= --Apple-Mail-89D4793C-0197-4674-820E-116A47468BFA-- From david.waltermire@nist.gov Wed Sep 12 07:43:31 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A521F8594 for ; Wed, 12 Sep 2012 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, 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 QrFPoDviBgEe for ; Wed, 12 Sep 2012 07:43:29 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 213A221F858F for ; Wed, 12 Sep 2012 07:43:29 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Sep 2012 10:43:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 12 Sep 2012 10:43:28 -0400 From: "Waltermire, David A." To: "Adam W. Montville" Date: Wed, 12 Sep 2012 10:43:26 -0400 Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: Ac2Q8QuxbCQfUSnWQsGHGJzJQ1nSBQAAwdSA Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov> <80513180-F438-42C2-9C99-304AFD6856DC@stoicsecurity.com> In-Reply-To: <80513180-F438-42C2-9C99-304AFD6856DC@stoicsecurity.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_D7A0423E5E193F40BE6E94126930C4930BA25D89D2MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:43:31 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA25D89D2MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRhbSwNCg0KVGhhbmtzIGZvciBhZ3JlZWluZyB0byB3b3JrIG9uIHRoaXMuICBJZiB5b3UgZG9u 4oCZdCBtaW5kLCBJ4oCZZCBsaWtlIHRvIHRha2UgdGhlIGFwcHJvYWNoIG9mIGNvbnZlcnRpbmcg dGhlIGRvY3VtZW50IGFzLWlzIGZvciB0aGUgLTAwIGRyYWZ0LiAgSWYgYW55IGNoYW5nZXMgYXJl IGRlc2lyZWQsIHdlIGNhbiB0aGVuIGRpc2N1c3MgdGhlbSBvbiB0aGUgbWFpbGluZyBsaXN0LCBk ZXZlbG9wIGNvbnNlbnN1cywgYW5kIHRoZW4gdXBkYXRlIHRoZSBkb2N1bWVudHMgdG8gcmVmbGVj dCB0aGUgY29uc2Vuc3VzLiAgVGhhdCB3YXkgZXZlcnlvbmUgaGFzIGlucHV0IGludG8gd2hhdCBl bmRzIHVwIGluIHRoZSBzcGVjaWZpY2F0aW9ucy4gIFdlIG1heSBuZWVkIHRvIHRha2Ugc29tZSBs aWJlcnRpZXMgd2l0aCBkaWFncmFtcyBvciBkYXRhIHRhYmxlcyB0aGF0IG1heSBub3QgY29udmVy dCB3ZWxsLiAgSeKAmWQgYmUgaGFwcHkgdG8gaGVscCB5b3Ugd29yayB0aHJvdWdoIHRoZXNlIGtp bmRzIG9mIGlzc3Vlcy4NCg0KU2luY2VyZWx5LA0KRGF2ZQ0KDQpGcm9tOiBBZGFtIFcuIE1vbnR2 aWxsZSBbbWFpbHRvOmFkYW1Ac3RvaWNzZWN1cml0eS5jb21dDQpTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAxMiwgMjAxMiAxMDoxNyBBTQ0KVG86IFdhbHRlcm1pcmUsIERhdmlkIEEuDQpDYzog c2FjbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYWNtXSBGVzogU0FDTSBCb0YgUmVxdWVzdA0K DQpUaGFuayB5b3UgRGF2ZSENCg0KSSdkIGJlIGhhcHB5IHRvIHBpY2sgdXAgQXNzZXQgSUQuDQoN ClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gU2VwIDEyLCAyMDEyLCBhdCA1OjU3IEFNLCAiV2Fs dGVybWlyZSwgRGF2aWQgQS4iIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292Pj4gd3JvdGU6DQpJIHNlbnQgaW4gYSByZXF1ZXN0IHRvIGhv bGQgYSBTQUNNIEJvRiBhdCB0aGUgSUVURiA4NSBtZWV0aW5nIGluIEF0bGFudGEsIEdBLiAgVGhl IGRldGFpbHMgYXJlIGJlbG93IGZvciBhbnlvbmUgaW50ZXJlc3RlZC4gIEF0IHRoaXMgcG9pbnQg d2UgbmVlZCB0byBjb21wbGV0ZSBwcmVwYXJhdGlvbnMgZm9yIHRoZSBCb0YuICBUbyBiZSBzdWNj ZXNzZnVsLCB3ZSB3aWxsIG5lZWQgeW91ciBwYXJ0aWNpcGF0aW9uIGluIHRoZSBCb0YgYW5kIHlv dXIgaGVscCBnZXR0aW5nIHJlYWR5Lg0KDQpIZXJlIGFyZSBtZWV0aW5nIGRldGFpbHMgaWYgeW91 IGFyZSBpbnRlcmVzdGVkIGluIG1ha2luZyB0cmF2ZWwgYXJyYW5nZW1lbnRzOg0KDQpodHRwOi8v d3d3LmlldGYub3JnL21lZXRpbmcvODUvaW5kZXguaHRtbA0KDQpBdCB0aGlzIHBvaW50IHdlIG5l ZWQgYWRkaXRpb25hbCBkcmFmdHMgdG8gYmUgc3VibWl0dGVkIHRvIGF1Z21lbnQgdGhlIGFnZW5k YSBhbmQgc3VwcG9ydCB0aGUgQm9GLiAgSeKAmWQgYmUgaGFwcHkgdG8gd29yayB3aXRoIGFueW9u ZSBpbnRlcmVzdGVkIGluIHByZXBhcmluZyBkcmFmdHMgZm9yIGFueSBvZiB0aGUgZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbnMgaW4gdGhpcyBhcmVhIChlLmcuIENQRSwgQXNzZXQgSWRlbnRpZmljYXRp b24sIEFSRiwgQVNSLCBldGMuKSAgV2Ugc2hvdWxkIHByb2JhYmx5IGRvIGEgZGlyZWN0IGNvbnZl cnNpb24gb2YgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgZm9yIC0wMCB2ZXJzaW9ucyBiZWZvcmUg bWFraW5nIGFueSBjaGFuZ2VzLiAgVGhlIC0wMCBkZWFkbGluZSBmb3IgdGhlIElFVEYgODUgbWVl dGluZyBpcyAxMC8xNSB3aXRoIGFueSB1cGRhdGVkIGRyYWZ0cyBkdWUgYSB3ZWVrIGxhdGVyIG9u IDEwLzIyLiAgQW55IHZvbHVudGVlcnM/DQoNCldlIHdpbGwgYWxzbyBuZWVkIHNwZWFrZXJzIHRv IHByZXNlbnQgZHJhZnRzLiAgUGxlYXNlIGxldCBtZSBvciBLYXRobGVlbiBrbm93IGlmIHlvdSBh cmUgaW50ZXJlc3RlZCBpbiBtYWtpbmcgYSBzaG9ydCBwcmVzZW50YXRpb24uDQoNCldlIGFsc28g bmVlZCB0byBjb250aW51ZSB0byByZWZpbmUgdGhlIGNoYXJ0ZXIgKGluY2x1ZGVkIGJlbG93KSBh bmQgdXNlIGNhc2UgZG9jdW1lbnRzLiBBbnkgYWRkaXRpb25hbCBjb21tZW50cy9jaGFuZ2VzIHdv dWxkIGJlIGFwcHJlY2lhdGVkLg0KDQpTaW5jZXJlbHksDQpEYXZlDQoNCkZyb206IFdhbHRlcm1p cmUsIERhdmlkIEEuDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiA2OjQ1IFBNDQpU bzogJ3N0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50 Y2QuaWU+JzsgJ3R1cm5lcnNAaWVjYS5jb208bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20+JzsgJ01v cmlhcnR5LCBLYXRobGVlbicNClN1YmplY3Q6IFNBQ00gQm9GIFJlcXVlc3QNCg0KUGxlYXNlIGZp bmQgdGhlIG91ciByZXF1ZXN0IGZvciBhIFdHIGZvcm1hdGlvbiBCb0YgYmVsb3cuICBJIGhhdmUg YWxzbyBpbmNsdWRlZCBhIGRyYWZ0IGNoYXJ0ZXIgdGhhdCB3ZSBoYXZlIGJlZW4gZGV2ZWxvcGlu ZyB3aXRoIGZlZWRiYWNrIGZyb20gdGhlIFNBQ00gbGlzdC4gIFBsZWFzZSBsZXQgbWUga25vdyBp ZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIGlmIHlvdSB3b3VsZCBsaWtlIGFueSBhZGRpdGlv bmFsIGRldGFpbHMuDQoNClNpbmNlcmVseSwNCkRhdmUgV2FsdGVybWlyZQ0KDQotLQ0KDQpCT0Yg ZnVsbCBuYW1lOiBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3Jpbmcg W1NBQ01dDQpBUkVBOiBTZWN1cml0eQ0KQk9GIENoYWlyczogS2F0aGxlZW4gTW9yaWFydHkgKGth dGhsZWVuLm1vcmlhcnR5QGVtYy5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20+ KQ0KICAgICAgICAgICAgRGF2aWQgV2FsdGVybWlyZSAoZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdv djxtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4pDQpBZ2VuZGE6DQoNCiogUmV2aWV3 IHRoZSBkcmFmdCBjaGFydGVyDQoqIFJldmlldyBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNh c2VzLTAyDQoqIFJldmlldyBkcmFmdHMgc3VibWl0dGVkIGluIHN1cHBvcnQgb2YgdGhlIGNoYXJ0 ZXINCiAgLSBkcmFmdC13YWx0ZXJtaXJlLWNvbnRlbnQtcmVwb3NpdG9yeS0wMA0KICAtIE1vcmUg ZXhwZWN0ZWQgYmVmb3JlIC0wMCBkZWFkbGluZQ0KDQpGdWxsIERlc2NyaXB0aW9uIG9mIEJPRjog VGhlIFNBQ00gQm9GIGlzIGludGVuZGVkIHRvIHByb2dyZXNzIHRoZSB3b3JrIGZyb20gdGhlIFNB Q00gbWFpbGluZyBsaXN0IHRvIHNvbGlkaWZ5IGRpc2N1c3Npb25zIG9uIGEgcHJvcG9zZWQgY2hh cnRlciwgdXNlIGNhc2VzIGFuZCBtaWxlc3RvbmVzIGluIHN1cHBvcnQgb2YgbW92aW5nIHRvIGFu IElFVEYgd29ya2luZyBncm91cC4NCg0KQ09ORkxJQ1RTIHRvIGF2b2lkOiBTQUFHLCBNSUxFDQpF eHBlY3RlZCBBdHRlbmRhbmNlOiA0MCwgbm90IHN1cmUgd2hhdCB0aGUgcHJldmlvdXMgYXR0ZW5k YW5jZSB3YXM/DQpTcGVjaWFsIFJlcXVlc3RzOiBNZWV0ZWNobyBzdXBwb3J0DQpOdW1iZXIgb2Yg c2Vzc2lvbnM6IDENCkxlbmd0aCBvZiBzZXNzaW9uOiAyIGhvdXJzDQoNCkRyYWZ0IENoYXJ0ZXI6 DQoNClByb3Bvc2VkIFdvcmtpbmcgR3JvdXAgQ2hhcnRlcg0KDQpDaGFpcnM6DQpUQkQNClRCRA0K DQpTZWN1cml0eSBBcmVhIERpcmVjdG9yczoNCiAgICAgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVu LmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NCiAg ICAgU2VhbiBUdXJuZXIgPHR1cm5lcnNAaWVjYS5jb208bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20+ Pg0KDQpTZWN1cml0eSBBcmVhIEFkdmlzb3I6DQogICAgIFNlYW4gVHVybmVyIDx0dXJuZXJzQGll Y2EuY29tPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPj4NCg0KTWFpbGluZyBMaXN0czoNCiAgICAg R2VuZXJhbCBEaXNjdXNzaW9uOiBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0K ICAgICBUbyBTdWJzY3JpYmU6ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zYWNtDQogICAgIEFyY2hpdmU6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NhY20NCg0KRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cA0KDQpT ZWN1cmluZyBpbmZvcm1hdGlvbiBhbmQgdGhlIHN5c3RlbXMgdGhhdCBzdG9yZSwgcHJvY2Vzcywg YW5kIHRyYW5zbWl0IHRoYXQgaW5mb3JtYXRpb24gaGFzIGJlY29tZSBhIGNoYWxsZW5naW5nIHRh c2sgZm9yIG9yZ2FuaXphdGlvbnMgb2YgYWxsIHNpemVzLCBhbmQgd2UgZmluZCB0aGF0IHNlY3Vy aXR5IHByYWN0aXRpb25lcnMgc3BlbmQgbW9zdCBvZiB0aGVpciB0aW1lIG9uIG1hbnVhbCBwcm9j ZXNzZXMgcmVsZWdhdGluZyB0aGVtIHRvIGluZWZmZWN0aXZlbmVzcy4gU2VjdXJpdHkgYXV0b21h dGlvbiB0byB2ZXJpZnkgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIHdpdGggdGhlIGFiaWxpdHkgdG8g cHJpb3JpdGl6ZSByaXNrIGJhc2VkIG9uIGluY3JlYXNlZCBzaXR1YXRpb25hbCBhd2FyZW5lc3Mg ZnJvbSBzaGFyZWQgaW50ZWxsaWdlbmNlIGlzIHRoZSBrZXkgdG8gZXNjYXBpbmcgdGhpcyBydXQu IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Agc2VjdXJpdHkgYXV0b21hdGlvbiBzdGFu ZGFyZHMgaW4gc3VwcG9ydCBvZiBpbmZvcm1hdGlvbiBzZWN1cml0eSBwcm9jZXNzZXMgYW5kIHBy YWN0aWNlcyB3aGVyZSBwcmFjdGljYWwuIFRoZXNlIHN0YW5kYXJkcyB3aWxsIGhlbHAgc2VjdXJp dHkgcHJhY3RpdGlvbmVycyB0byBiZSBiZXR0ZXIgdXRpbGl6ZWQgd2l0aGluIHRoZWlyIG9yZ2Fu aXphdGlvbnMgYnkgYXV0b21hdGluZyByb3V0aW5lIHRhc2tzIHJlbGF0ZWQgdG8gZW5kcG9pbnQg YW5kIHNlcnZlciBzZWN1cml0eSBzbyB0aGF0IHByYWN0aXRpb25lcnMgY2FuIGZvY3VzIG9uIG1v cmUgYWR2YW5jZWQgdGFza3MuIFRoZSBpbml0aWFsIGZvY3VzIG9mIHRoaXMgd29yayBpcyB0byBh ZGRyZXNzIGVudGVycHJpc2UgdXNlIGNhc2VzLg0KDQpUaGUgd29ya2luZyBncm91cCB3aWxsIGFj aGlldmUgdGhpcyBieSBjb25zdW1pbmcgc2hhcmVkIGludGVsbGlnZW5jZSBhbmQgY29udGludWlu ZyAod2l0aCBjb29wZXJhdGlvbikgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gd29yayBhbHJlYWR5 IHBlcmZvcm1lZCBieSB2YXJpb3VzIG9yZ2FuaXphdGlvbnMgYXJvdW5kIHRoZSB3b3JsZC4gIFRo ZSBpbml0aWFsIHdvcmsgaGFzIGJlZW4gZnJ1aXRmdWwsIGFuZCB0aGUgZGF0YSBmb3JtYXRzIHBy ZXZpb3VzbHkgcHVibGlzaGVkIGFyZSByZWFkeSBmb3IgZXhwYW5zaW9uIG9uIHRoZSBpbnRlcm5h dGlvbmFsIHN0YWdlLiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91 cCBhcmUgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gc3BlY2lmaWNhdGlvbnMgc3VwcG9ydGluZyBh c3NldCwgY2hhbmdlLCBjb25maWd1cmF0aW9uLCBhbmQgdnVsbmVyYWJpbGl0eSBtYW5hZ2VtZW50 LiBPZiBhZGRpdGlvbmFsIGludGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91cCBhcmUgdGhlIGVt ZXJnaW5nIHNlY3VyaXR5IGF1dG9tYXRpb24gaW50ZXJmYWNlcyBhbmQgZGF0YSBmb3JtYXRzIHJl bGF0aW5nIHRvIGV2ZW50IG1hbmFnZW1lbnQgYW5kIGNvbnRpbnVvdXMgYXNzZXNzbWVudC4gIFRo ZSBjb250aW51b3VzIGFzc2Vzc21lbnQgY2FwYWJpbGl0aWVzIGVuYWJsZSBvcmdhbml6YXRpb25h bCBzaXR1YXRpb25hbCBhd2FyZW5lc3MgdGhyb3VnaCBmcmVxdWVudCBzbmFwc2hvdHMgb2YgdGhl IG9wZXJhdGluZyBzdGF0ZSBvZiB0aGVpciBlbnZpcm9ubWVudCwgd2l0aCByaXNrIHByaW9yaXRp emVkIGJhc2VkIG9uIGNvbnN1bWVkIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHNoYXJlZCBpbnRl bGxpZ2VuY2UgKHZ1bG5lcmFiaWxpdGllcywgdGhyZWF0cywgZXRjLikuDQoNCkJ5IHVuZGVydGFr aW5nIHRoaXMgd29yaywgd2UgcmVjb2duaXplIHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIGNhdGVn b3JpZXMgb2YgcHJvYmxlbXMgaW4gdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gZG9tYWluOiBkZWZp bmluZyBleHByZXNzaW9ucyBmb3IgcGFydGljdWxhciBkb21haW4gY29uY2VwdHMgKGkuZS4gZGF0 YSBmb3JtYXRzKSwgZXN0YWJsaXNoaW5nIGEgc3RhbmRhcmRzLWJhc2VkIGZvdW5kYXRpb24gc3Vw cG9ydGluZyB0aGUgY3VyYXRpb24gYW5kIGV4Y2hhbmdlIG9mIHNlY3VyaXR5IGF1dG9tYXRpb24g Y29udGVudCBjb2xsZWN0aW9ucyBpbiBjb250ZW50IHJlcG9zaXRvcmllcywgYW5kIGVuYWJsaW5n IGludGVyb3BlcmFiaWxpdHkgdGhyb3VnaCB0aGUgZGV2ZWxvcG1lbnQgYW5kIHVzZSBvZiBzdGFu ZGFyZCBpbnRlcmZhY2VzIGFuZCBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMuIENvbnRlbnQgYmFz ZWQgb24gcmljaCBkYXRhIHN0YW5kYXJkcyBhbmQgcHJvdG9jb2xzIHdpbGwgcHJvdmlkZSB0aGUg YXV0aG9yaXRhdGl2ZSBpbnN0cnVjdGlvbnMgbmVlZGVkIGJ5IGRhdGEtZHJpdmVuIHRvb2xzIHRv IGVuYWJsZSB0aGUgYXV0b21hdGVkIGNvbGxlY3Rpb24gYW5kIGV4Y2hhbmdlIG9mIGNvbmZpZ3Vy YXRpb24gYW5kIHZ1bG5lcmFiaWxpdHkgZGF0YSBwZXJ0YWluaW5nIHRvIGVudGVycHJpc2UgYXNz ZXRzLiBJbmZvcm1hdGlvbiBwcm9kdWNlZCBieSB0aGVzZSB0b29scyB3aWxsIHByb3ZpZGUgYWNj dXJhdGUgYW5kIHRpbWVseSBzaXR1YXRpb25hbCBhd2FyZW5lc3MgaW4gc3VwcG9ydCBvZiBvcmdh bml6YXRpb25hbCBkZWNpc2lvbiBtYWtpbmcuDQoNClRoaXMgd29ya2luZyBncm91cCB3aWxsIHBy b3ZpZGUgc29sdXRpb25zIHRvIHRoZXNlIGNhdGVnb3JpZXMgb2YgcHJvYmxlbXMgYW5kIHRoZSBt YWluIGFyZWFzIG9mIGZvY3VzIGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIGRlc2NyaWJlZCBh cyBmb2xsb3dzOg0KDQoxLiBEZWZpbmUsIGVpdGhlciBieSBub3JtYXRpdmUgcmVmZXJlbmNlLCBh ZG9wdGlvbiwgb3IgY3JlYXRpb24sIGEgc2V0IG9mIHN0YW5kYXJkcyB0aGF0IGNhbiBiZSB1c2Vk IGZvciB0aGUgcHVycG9zZSBvZiBhc3Nlc3NpbmcgYW5kIGFnZ3JlZ2F0aW5nIGRldmljZSBzdGF0 ZXMgYW5kIGNvbXBhcmluZyB0aGVzZSBkZXZpY2Ugc3RhdGVzIGFnYWluc3QgZXhwZWN0ZWQgdmFs dWVzLCBhbmQgcmVwb3J0aW5nIG9uIHRob3NlIHJlc3VsdHMgaW4gYSBwcmVkZWZpbmVkIG9yIGFk IGhvYyBtYW5uZXIuICBUaGlzIGFyZWEgb2YgZm9jdXMgcHJvdmlkZXMgZm9yIG5lY2Vzc2FyeSBs YW5ndWFnZSBhbmQgZGF0YSBmb3JtYXQgc3BlY2lmaWNhdGlvbnMuDQoNCjIuIERlZmluZSwgZWl0 aGVyIGJ5IG5vcm1hdGl2ZSByZWZlcmVuY2UsIGFkb3B0aW9uLCBvciBjcmVhdGlvbiwgYSBzZXQg b2Ygc3RhbmRhcmRzIHRoYXQgY2FuIGJlIHVzZWQgdG8gY29udGludW91c2x5IGFzc2VzcyBhbmQg cmVwb3J0IG9uIHRoZSBzdGF0ZSBvZiBzeXN0ZW1zLCBjb21wb3NlZCBvZiBtYW55IGRpZmZlcmVu dCB0eXBlcyBvZiBkZXZpY2VzIGFuZCBuZXR3b3Jrcywgb3BlcmF0ZWQgYnkgdmFyeWluZyBwZXJz b25uZWwsIHRvIGVuc3VyZSBzZWN1cml0eSBwcm9jZXNzIGVmZmVjdGl2ZW5lc3MgaW4gYSBwcmUt ZGVmaW5lZCBvciBhZC1ob2MgbWFubmVyLiAgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZv ciBpbnRlZ3JhdGlvbiBwcm90b2NvbHMgc3VwcG9ydGluZyBwbHVnIGFuZCBwbGF5IGNvbnRpbnVv dXMgYXNzZXNzbWVudCBhbmQgc2VjdXJpdHkgYXV0b21hdGlvbiBuZXR3b3JraW5nLg0KDQpUaGlz IHdvcmtpbmcgZ3JvdXAgd2lsbCBhY2hpZXZlIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lcyBpbiB0 d28gcGhhc2VzOg0KDQpQaGFzZSBPbmUNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3Bl Y2lmeWluZyBhc3NldCBkZXNjcmlwdGlvbiBmb3JtYXQNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9j dW1lbnQgc3BlY2lmeWluZyBhc3NldCBpZGVudGlmaWNhdGlvbg0KLSBBIFN0YW5kYXJkcyBUcmFj ayBkb2N1bWVudCBzcGVjaWZ5aW5nIHBsYXRmb3JtIG5hbWluZw0KLSBBIFN0YW5kYXJkcyBUcmFj ayBkb2N1bWVudCBzcGVjaWZ5aW5nIHBsYXRmb3JtIG1hdGNoaW5nDQotIEEgU3RhbmRhcmRzIFRy YWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gYXBwbGljYWJpbGl0eQ0KLSBBIFN0YW5k YXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGEgY29udHJvbCBmcmFtZXdvcmsgcmVwcmVz ZW50YXRpb24gZm9ybWF0Lg0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5n IGJlbmNobWFyayBjb25maWd1cmF0aW9uIHJlcHJlc2VudGF0aW9uDQotIEFuIEluZm9ybWF0aW9u YWwgZG9jdW1lbnQgc3RhdGluZyBndWlkZWxpbmVzIC8gcmVxdWlyZW1lbnRzIGZvciBzcGVjaWZ5 aW5nIGNoZWNraW5nIGxhbmd1YWdlcw0KLSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnRzIHNwZWNp ZnlpbmcgZGV2aWNlIHN0YXRlIGNoZWNraW5nIGxhbmd1YWdlcw0KLSBBIFN0YW5kYXJkcyBUcmFj ayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFuIGludGVycm9nYXRpdmUgY2hlY2tpbmcgbGFuZ3VhZ2UN Ci0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhc3NldCByZXBvcnRpbmcg aW5mb3JtYXRpb24NCi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgaG93IHRv IHVzZSB0aGUgbGFuZ3VhZ2VzIGFuZCBvdGhlciBjb250ZW50IGRlZmluZWQgaW4gdGhpcyBncm91 cCB3aXRoIHRoZSBORUEgcHJvdG9jb2xzDQoNClBoYXNlIFR3bw0KLSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBzZWN1cml0eSBhdXRvbWF0aW9uL2NvbnRpbnVvdXMgYXNzZXNz bWVudCBpbnRlcmZhY2VzDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcg Y29tbXVuaWNhdGlvbiBwcm90b2NvbHMgdXNlZCBmb3Igc2VjdXJpdHkgYXV0b21hdGlvbiBhbmQg Y29udGludW91cyBhc3Nlc3NtZW50DQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2Ny aWJpbmcgdGhlIG1lc3NhZ2VzIGFuZCBuZXR3b3JrIHByb3RvY29scyBmb3IgZGlzdHJpYnV0aW5n IHNlY3VyaXR5IGF1dG9tYXRpb24gY29udGVudCAgKGNvbnRlbnQgcmVwb3NpdG9yeSkNCi0gQSBT dGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyBwcm90b2NvbHMgYW5kIGRhdGEgZm9y bWF0cyBmb3Igc2VjdXJlbHkgc2hhcmluZyBkeW5hbWljIG5ldHdvcmsgc3RhdGUgaW5mb3JtYXRp b24gYW1vbmcgc2VjdXJpdHkgc3lzdGVtcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8bWFp bHRvOnNhY21AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NhY20NCg== --_000_D7A0423E5E193F40BE6E94126930C4930BA25D89D2MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkFkYW0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciBh Z3JlZWluZyB0byB3b3JrIG9uIHRoaXMuwqAgSWYgeW91IGRvbuKAmXQgbWluZCwgSeKAmWQgbGlr ZSB0byB0YWtlIHRoZSBhcHByb2FjaCBvZiBjb252ZXJ0aW5nIHRoZSBkb2N1bWVudCBhcy1pcyBm b3IgdGhlIC0wMCBkcmFmdC7CoCBJZiBhbnkgY2hhbmdlcyBhcmUgZGVzaXJlZCwgd2UgY2FuIHRo ZW4gZGlzY3VzcyB0aGVtIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGRldmVsb3AgY29uc2Vuc3VzLCBh bmQgdGhlbiB1cGRhdGUgdGhlIGRvY3VtZW50cyB0byByZWZsZWN0IHRoZSBjb25zZW5zdXMuwqAg VGhhdCB3YXkgZXZlcnlvbmUgaGFzIGlucHV0IGludG8gd2hhdCBlbmRzIHVwIGluIHRoZSBzcGVj aWZpY2F0aW9ucy7CoCBXZSBtYXkgbmVlZCB0byB0YWtlIHNvbWUgbGliZXJ0aWVzIHdpdGggZGlh Z3JhbXMgb3IgZGF0YSB0YWJsZXMgdGhhdCBtYXkgbm90IGNvbnZlcnQgd2VsbC7CoCBJ4oCZZCBi ZSBoYXBweSB0byBoZWxwIHlvdSB3b3JrIHRocm91Z2ggdGhlc2Uga2luZHMgb2YgaXNzdWVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+RGF2ZTwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEFk YW0gVy4gTW9udHZpbGxlIFttYWlsdG86YWRhbUBzdG9pY3NlY3VyaXR5LmNvbV0gPGJyPjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMDoxNyBBTTxicj48Yj5Ubzo8 L2I+IFdhbHRlcm1pcmUsIERhdmlkIEEuPGJyPjxiPkNjOjwvYj4gc2FjbUBpZXRmLm9yZzxicj48 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBGVzogU0FDTSBCb0YgUmVxdWVzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmsgeW91IERhdmUhPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSdkIGJlIGhhcHB5IHRvIHBpY2sgdXAgQXNzZXQg SUQuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPlNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5PbiBTZXAgMTIsIDIwMTIsIGF0IDU6 NTcgQU0sICZxdW90O1dhbHRlcm1pcmUsIERhdmlkIEEuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiI+ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIHNlbnQgaW4gYSByZXF1ZXN0IHRvIGhvbGQg YSBTQUNNIEJvRiBhdCB0aGUgSUVURiA4NSBtZWV0aW5nIGluIEF0bGFudGEsIEdBLiZuYnNwOyBU aGUgZGV0YWlscyBhcmUgYmVsb3cgZm9yIGFueW9uZSBpbnRlcmVzdGVkLiZuYnNwOyBBdCB0aGlz IHBvaW50IHdlIG5lZWQgdG8gY29tcGxldGUgcHJlcGFyYXRpb25zIGZvciB0aGUgQm9GLiZuYnNw OyBUbyBiZSBzdWNjZXNzZnVsLCB3ZSB3aWxsIG5lZWQgeW91ciBwYXJ0aWNpcGF0aW9uIGluIHRo ZSBCb0YgYW5kIHlvdXIgaGVscCBnZXR0aW5nIHJlYWR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPkhlcmUgYXJlIG1lZXRpbmcgZGV0YWlscyBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4g bWFraW5nIHRyYXZlbCBhcnJhbmdlbWVudHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg1L2luZGV4Lmh0bWwiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NS9pbmRleC5odG1sPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPkF0IHRoaXMgcG9pbnQgd2UgbmVlZCBhZGRpdGlvbmFsIGRyYWZ0cyB0byBi ZSBzdWJtaXR0ZWQgdG8gYXVnbWVudCB0aGUgYWdlbmRhIGFuZCBzdXBwb3J0IHRoZSBCb0YuJm5i c3A7IEnigJlkIGJlIGhhcHB5IHRvIHdvcmsgd2l0aCBhbnlvbmUgaW50ZXJlc3RlZCBpbiBwcmVw YXJpbmcgZHJhZnRzIGZvciBhbnkgb2YgdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGluIHRo aXMgYXJlYSAoZS5nLiBDUEUsIEFzc2V0IElkZW50aWZpY2F0aW9uLCBBUkYsIEFTUiwgZXRjLikm bmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5IGRvIGEgZGlyZWN0IGNvbnZlcnNpb24gb2YgZXhpc3Rp bmcgc3BlY2lmaWNhdGlvbnMgZm9yIC0wMCB2ZXJzaW9ucyBiZWZvcmUgbWFraW5nIGFueSBjaGFu Z2VzLiZuYnNwOyBUaGUgLTAwIGRlYWRsaW5lIGZvciB0aGUgSUVURiA4NSBtZWV0aW5nIGlzIDEw LzE1IHdpdGggYW55IHVwZGF0ZWQgZHJhZnRzIGR1ZSBhIHdlZWsgbGF0ZXIgb24gMTAvMjIuJm5i c3A7IEFueSB2b2x1bnRlZXJzPyA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XZSB3aWxs IGFsc28gbmVlZCBzcGVha2VycyB0byBwcmVzZW50IGRyYWZ0cy4mbmJzcDsgUGxlYXNlIGxldCBt ZSBvciBLYXRobGVlbiBrbm93IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBtYWtpbmcgYSBzaG9y dCBwcmVzZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgYWxzbyBuZWVk IHRvIGNvbnRpbnVlIHRvIHJlZmluZSB0aGUgY2hhcnRlciAoaW5jbHVkZWQgYmVsb3cpIGFuZCB1 c2UgY2FzZSBkb2N1bWVudHMuIEFueSBhZGRpdGlvbmFsIGNvbW1lbnRzL2NoYW5nZXMgd291bGQg YmUgYXBwcmVjaWF0ZWQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2luY2Vy ZWx5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPkRhdmU8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFdhbHRlcm1pcmUsIERhdmlkIEEu IDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgNjo0NSBQTTxicj48 Yj5Ubzo8L2I+ICc8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4nOyAnPGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNAaWVj YS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+JzsgJ01vcmlhcnR5LCBLYXRobGVlbic8YnI+PGI+ U3ViamVjdDo8L2I+IFNBQ00gQm9GIFJlcXVlc3Q8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD5QbGVhc2UgZmluZCB0aGUgb3VyIHJlcXVlc3QgZm9yIGEgV0cgZm9ybWF0aW9uIEJv RiBiZWxvdy4mbmJzcDsgSSBoYXZlIGFsc28gaW5jbHVkZWQgYSBkcmFmdCBjaGFydGVyIHRoYXQg d2UgaGF2ZSBiZWVuIGRldmVsb3Bpbmcgd2l0aCBmZWVkYmFjayBmcm9tIHRoZSBTQUNNIGxpc3Qu Jm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIGlm IHlvdSB3b3VsZCBsaWtlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5T aW5jZXJlbHksPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkRhdmUgV2FsdGVybWly ZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+LS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkJPRiBmdWxsIG5hbWU6IFNlY3Vy aXR5IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyBbU0FDTV08bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QVJFQTogU2VjdXJpdHk8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+Qk9GIENoYWlyczogS2F0aGxlZW4gTW9yaWFydHkgKDxhIGhyZWY9Im1h aWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tIj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29t PC9hPik8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdmlkIFdh bHRlcm1pcmUgKDxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Ij5kYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9hPik8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+QWdlbmRhOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+KiBSZXZpZXcgdGhlIGRyYWZ0IGNoYXJ0ZXI8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+KiBSZXZpZXcgZHJhZnQtd2FsdGVybWlyZS1z YWNtLXVzZS1jYXNlcy0wMiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+KiBSZXZp ZXcgZHJhZnRzIHN1Ym1pdHRlZCBpbiBzdXBwb3J0IG9mIHRoZSBjaGFydGVyPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAtIGRyYWZ0LXdhbHRlcm1pcmUtY29udGVudC1y ZXBvc2l0b3J5LTAwPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAtIE1v cmUgZXhwZWN0ZWQgYmVmb3JlIC0wMCBkZWFkbGluZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RnVsbCBEZXNj cmlwdGlvbiBvZiBCT0Y6IFRoZSBTQUNNIEJvRiBpcyBpbnRlbmRlZCB0byBwcm9ncmVzcyB0aGUg d29yayBmcm9tIHRoZSBTQUNNIG1haWxpbmcgbGlzdCB0byBzb2xpZGlmeSBkaXNjdXNzaW9ucyBv biBhIHByb3Bvc2VkIGNoYXJ0ZXIsIHVzZSBjYXNlcyBhbmQgbWlsZXN0b25lcyBpbiBzdXBwb3J0 IG9mIG1vdmluZyB0byBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5DT05G TElDVFMgdG8gYXZvaWQ6IFNBQUcsIE1JTEU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+RXhwZWN0ZWQgQXR0ZW5kYW5jZTogNDAsIG5vdCBzdXJlIHdoYXQgdGhlIHByZXZpb3VzIGF0 dGVuZGFuY2Ugd2FzPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5TcGVjaWFsIFJl cXVlc3RzOiBNZWV0ZWNobyBzdXBwb3J0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs Pk51bWJlciBvZiBzZXNzaW9uczogMTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5M ZW5ndGggb2Ygc2Vzc2lvbjogMiBob3VyczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RHJhZnQgQ2hhcnRlcjo8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPlByb3Bvc2VkIFdvcmtpbmcgR3JvdXAgQ2hhcnRlcjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+Q2hhaXJzOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UQkQ8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+VEJEPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5TZWN1cml0eSBB cmVhIERpcmVjdG9yczo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0Ozxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIj50dXJuZXJz QGllY2EuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNlY3VyaXR5IEFyZWEgQWR2aXNvcjo8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNvbSI+dHVybmVy c0BpZWNhLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5NYWlsaW5nIExpc3RzOjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR2VuZXJh bCBEaXNjdXNzaW9uOiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRvIFN1YnNjcmliZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9hPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJjaGl2ZTombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY20iPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zYWNtPC9hPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+RGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+U2VjdXJpbmcg aW5mb3JtYXRpb24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHByb2Nlc3MsIGFuZCB0cmFu c21pdCB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWNvbWUgYSBjaGFsbGVuZ2luZyB0YXNrIGZvciBv cmdhbml6YXRpb25zIG9mIGFsbCBzaXplcywgYW5kIHdlIGZpbmQgdGhhdCBzZWN1cml0eSBwcmFj dGl0aW9uZXJzIHNwZW5kIG1vc3Qgb2YgdGhlaXIgdGltZSBvbiBtYW51YWwgcHJvY2Vzc2VzIHJl bGVnYXRpbmcgdGhlbSB0byBpbmVmZmVjdGl2ZW5lc3MuIFNlY3VyaXR5IGF1dG9tYXRpb24gdG8g dmVyaWZ5IHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aXRoIHRoZSBhYmlsaXR5IHRvIHByaW9yaXRp emUgcmlzayBiYXNlZCBvbiBpbmNyZWFzZWQgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGZyb20gc2hh cmVkIGludGVsbGlnZW5jZSBpcyB0aGUga2V5IHRvIGVzY2FwaW5nIHRoaXMgcnV0LiBUaGlzIHdv cmtpbmcgZ3JvdXAgd2lsbCBkZXZlbG9wIHNlY3VyaXR5IGF1dG9tYXRpb24gc3RhbmRhcmRzIGlu IHN1cHBvcnQgb2YgaW5mb3JtYXRpb24gc2VjdXJpdHkgcHJvY2Vzc2VzIGFuZCBwcmFjdGljZXMg d2hlcmUgcHJhY3RpY2FsLiBUaGVzZSBzdGFuZGFyZHMgd2lsbCBoZWxwIHNlY3VyaXR5IHByYWN0 aXRpb25lcnMgdG8gYmUgYmV0dGVyIHV0aWxpemVkIHdpdGhpbiB0aGVpciBvcmdhbml6YXRpb25z IGJ5IGF1dG9tYXRpbmcgcm91dGluZSB0YXNrcyByZWxhdGVkIHRvIGVuZHBvaW50IGFuZCBzZXJ2 ZXIgc2VjdXJpdHkgc28gdGhhdCBwcmFjdGl0aW9uZXJzIGNhbiBmb2N1cyBvbiBtb3JlIGFkdmFu Y2VkIHRhc2tzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgdG8gYWRkcmVzcyBl bnRlcnByaXNlIHVzZSBjYXNlcy4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgd29ya2luZyBncm91cCB3 aWxsIGFjaGlldmUgdGhpcyBieSBjb25zdW1pbmcgc2hhcmVkIGludGVsbGlnZW5jZSBhbmQgY29u dGludWluZyAod2l0aCBjb29wZXJhdGlvbikgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gd29yayBh bHJlYWR5IHBlcmZvcm1lZCBieSB2YXJpb3VzIG9yZ2FuaXphdGlvbnMgYXJvdW5kIHRoZSB3b3Js ZC4mbmJzcDsgVGhlIGluaXRpYWwgd29yayBoYXMgYmVlbiBmcnVpdGZ1bCwgYW5kIHRoZSBkYXRh IGZvcm1hdHMgcHJldmlvdXNseSBwdWJsaXNoZWQgYXJlIHJlYWR5IGZvciBleHBhbnNpb24gb24g dGhlIGludGVybmF0aW9uYWwgc3RhZ2UuIE9mIHBhcnRpY3VsYXIgaW50ZXJlc3QgdG8gdGhpcyB3 b3JraW5nIGdyb3VwIGFyZSB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBzcGVjaWZpY2F0aW9ucyBz dXBwb3J0aW5nIGFzc2V0LCBjaGFuZ2UsIGNvbmZpZ3VyYXRpb24sIGFuZCB2dWxuZXJhYmlsaXR5 IG1hbmFnZW1lbnQuIE9mIGFkZGl0aW9uYWwgaW50ZXJlc3QgdG8gdGhpcyB3b3JraW5nIGdyb3Vw IGFyZSB0aGUgZW1lcmdpbmcgc2VjdXJpdHkgYXV0b21hdGlvbiBpbnRlcmZhY2VzIGFuZCBkYXRh IGZvcm1hdHMgcmVsYXRpbmcgdG8gZXZlbnQgbWFuYWdlbWVudCBhbmQgY29udGludW91cyBhc3Nl c3NtZW50LiZuYnNwOyBUaGUgY29udGludW91cyBhc3Nlc3NtZW50IGNhcGFiaWxpdGllcyBlbmFi bGUgb3JnYW5pemF0aW9uYWwgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIHRocm91Z2ggZnJlcXVlbnQg c25hcHNob3RzIG9mIHRoZSBvcGVyYXRpbmcgc3RhdGUgb2YgdGhlaXIgZW52aXJvbm1lbnQsIHdp dGggcmlzayBwcmlvcml0aXplZCBiYXNlZCBvbiBjb25zdW1lZCBpbmZvcm1hdGlvbiBwcm92aWRl ZCBieSBzaGFyZWQgaW50ZWxsaWdlbmNlICh2dWxuZXJhYmlsaXRpZXMsIHRocmVhdHMsIGV0Yy4p LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+QnkgdW5kZXJ0YWtpbmcgdGhpcyB3b3JrLCB3ZSByZWNvZ25pemUg dGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgY2F0ZWdvcmllcyBvZiBwcm9ibGVtcyBpbiB0aGUgc2Vj dXJpdHkgYXV0b21hdGlvbiBkb21haW46IGRlZmluaW5nIGV4cHJlc3Npb25zIGZvciBwYXJ0aWN1 bGFyIGRvbWFpbiBjb25jZXB0cyAoaS5lLiBkYXRhIGZvcm1hdHMpLCBlc3RhYmxpc2hpbmcgYSBz dGFuZGFyZHMtYmFzZWQgZm91bmRhdGlvbiBzdXBwb3J0aW5nIHRoZSBjdXJhdGlvbiBhbmQgZXhj aGFuZ2Ugb2Ygc2VjdXJpdHkgYXV0b21hdGlvbiBjb250ZW50IGNvbGxlY3Rpb25zIGluIGNvbnRl bnQgcmVwb3NpdG9yaWVzLCBhbmQgZW5hYmxpbmcgaW50ZXJvcGVyYWJpbGl0eSB0aHJvdWdoIHRo ZSBkZXZlbG9wbWVudCBhbmQgdXNlIG9mIHN0YW5kYXJkIGludGVyZmFjZXMgYW5kIGNvbW11bmlj YXRpb25zIHByb3RvY29scy4gQ29udGVudCBiYXNlZCBvbiByaWNoIGRhdGEgc3RhbmRhcmRzIGFu ZCBwcm90b2NvbHMgd2lsbCBwcm92aWRlIHRoZSBhdXRob3JpdGF0aXZlIGluc3RydWN0aW9ucyBu ZWVkZWQgYnkgZGF0YS1kcml2ZW4gdG9vbHMgdG8gZW5hYmxlIHRoZSBhdXRvbWF0ZWQgY29sbGVj dGlvbiBhbmQgZXhjaGFuZ2Ugb2YgY29uZmlndXJhdGlvbiBhbmQgdnVsbmVyYWJpbGl0eSBkYXRh IHBlcnRhaW5pbmcgdG8gZW50ZXJwcmlzZSBhc3NldHMuIEluZm9ybWF0aW9uIHByb2R1Y2VkIGJ5 IHRoZXNlIHRvb2xzIHdpbGwgcHJvdmlkZSBhY2N1cmF0ZSBhbmQgdGltZWx5IHNpdHVhdGlvbmFs IGF3YXJlbmVzcyBpbiBzdXBwb3J0IG9mIG9yZ2FuaXphdGlvbmFsIGRlY2lzaW9uIG1ha2luZy4g PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5UaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm92aWRlIHNvbHV0aW9u cyB0byB0aGVzZSBjYXRlZ29yaWVzIG9mIHByb2JsZW1zIGFuZCB0aGUgbWFpbiBhcmVhcyBvZiBm b2N1cyBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIGFyZSBkZXNjcmliZWQgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjEuIERlZmluZSwgZWl0aGVyIGJ5IG5vcm1hdGl2ZSByZWZlcmVuY2UsIGFk b3B0aW9uLCBvciBjcmVhdGlvbiwgYSBzZXQgb2Ygc3RhbmRhcmRzIHRoYXQgY2FuIGJlIHVzZWQg Zm9yIHRoZSBwdXJwb3NlIG9mIGFzc2Vzc2luZyBhbmQgYWdncmVnYXRpbmcgZGV2aWNlIHN0YXRl cyBhbmQgY29tcGFyaW5nIHRoZXNlIGRldmljZSBzdGF0ZXMgYWdhaW5zdCBleHBlY3RlZCB2YWx1 ZXMsIGFuZCByZXBvcnRpbmcgb24gdGhvc2UgcmVzdWx0cyBpbiBhIHByZWRlZmluZWQgb3IgYWQg aG9jIG1hbm5lci4mbmJzcDsgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBuZWNlc3Nh cnkgbGFuZ3VhZ2UgYW5kIGRhdGEgZm9ybWF0IHNwZWNpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+Mi4gRGVmaW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRvcHRpb24sIG9y IGNyZWF0aW9uLCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCB0byBjb250aW51 b3VzbHkgYXNzZXNzIGFuZCByZXBvcnQgb24gdGhlIHN0YXRlIG9mIHN5c3RlbXMsIGNvbXBvc2Vk IG9mIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMgYW5kIG5ldHdvcmtzLCBvcGVyYXRl ZCBieSB2YXJ5aW5nIHBlcnNvbm5lbCwgdG8gZW5zdXJlIHNlY3VyaXR5IHByb2Nlc3MgZWZmZWN0 aXZlbmVzcyBpbiBhIHByZS1kZWZpbmVkIG9yIGFkLWhvYyBtYW5uZXIuJm5ic3A7IFRoaXMgYXJl YSBvZiBmb2N1cyBwcm92aWRlcyBmb3IgaW50ZWdyYXRpb24gcHJvdG9jb2xzIHN1cHBvcnRpbmcg cGx1ZyBhbmQgcGxheSBjb250aW51b3VzIGFzc2Vzc21lbnQgYW5kIHNlY3VyaXR5IGF1dG9tYXRp b24gbmV0d29ya2luZy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgd29ya2luZyBncm91cCB3aWxsIGFj aGlldmUgdGhlIGZvbGxvd2luZyBtaWxlc3RvbmVzIGluIHR3byBwaGFzZXM6PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5QaGFzZSBPbmU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+LSBBIFN0YW5k YXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IGRlc2NyaXB0aW9uIGZvcm1hdDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3Vt ZW50IHNwZWNpZnlpbmcgYXNzZXQgaWRlbnRpZmljYXRpb248bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIHBsYXRm b3JtIG5hbWluZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEgU3RhbmRhcmRz IFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gbWF0Y2hpbmc8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5 aW5nIHBsYXRmb3JtIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGEgY29udHJvbCBmcmFt ZXdvcmsgcmVwcmVzZW50YXRpb24gZm9ybWF0LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYmVuY2htYXJrIGNv bmZpZ3VyYXRpb24gcmVwcmVzZW50YXRpb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+LSBBbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHN0YXRpbmcgZ3VpZGVsaW5lcyAvIHJlcXVp cmVtZW50cyBmb3Igc3BlY2lmeWluZyBjaGVja2luZyBsYW5ndWFnZXM8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+LSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnRzIHNwZWNpZnlpbmcg ZGV2aWNlIHN0YXRlIGNoZWNraW5nIGxhbmd1YWdlczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYW4gaW50ZXJy b2dhdGl2ZSBjaGVja2luZyBsYW5ndWFnZSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IHJlcG9ydGlu ZyBpbmZvcm1hdGlvbiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+LSBTdGFuZGFy ZHMgVHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyBob3cgdG8gdXNlIHRoZSBsYW5ndWFnZXMgYW5k IG90aGVyIGNvbnRlbnQgZGVmaW5lZCBpbiB0aGlzIGdyb3VwIHdpdGggdGhlIE5FQSBwcm90b2Nv bHM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPlBoYXNlIFR3bzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD4tIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIHNlY3VyaXR5IGF1dG9t YXRpb24vY29udGludW91cyBhc3Nlc3NtZW50IGludGVyZmFjZXM8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGNv bW11bmljYXRpb24gcHJvdG9jb2xzIHVzZWQgZm9yIHNlY3VyaXR5IGF1dG9tYXRpb24gYW5kIGNv bnRpbnVvdXMgYXNzZXNzbWVudDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4tIEEg U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIG1lc3NhZ2VzIGFuZCBuZXR3 b3JrIHByb3RvY29scyBmb3IgZGlzdHJpYnV0aW5nIHNlY3VyaXR5IGF1dG9tYXRpb24gY29udGVu dCZuYnNwOyAoY29udGVudCByZXBvc2l0b3J5KTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgcHJvdG9jb2xzIGFu ZCBkYXRhIGZvcm1hdHMgZm9yIHNlY3VyZWx5IHNoYXJpbmcgZHluYW1pYyBuZXR3b3JrIHN0YXRl IGluZm9ybWF0aW9uIGFtb25nIHNlY3VyaXR5IHN5c3RlbXM8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPnNhY20gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1h aWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9i bG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930BA25D89D2MBCLUSTERxcha_-- From amontville@tripwire.com Wed Sep 12 07:46:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D221F8602 for ; Wed, 12 Sep 2012 07:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, RCVD_IN_DNSWL_LOW=-1] 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 R3I3BCLTafb7 for ; Wed, 12 Sep 2012 07:46:11 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 34FC321F85A4 for ; Wed, 12 Sep 2012 07:46:10 -0700 (PDT) Received: from mail118-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Sep 2012 14:46:09 +0000 Received: from mail118-am1 (localhost [127.0.0.1]) by mail118-am1-R.bigfish.com (Postfix) with ESMTP id 2F8094600B1 for ; Wed, 12 Sep 2012 14:46:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371I1469Kc85eh148cI1418Ic25dLzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdhbe3k1155h) Received: from mail118-am1 (localhost.localdomain [127.0.0.1]) by mail118-am1 (MessageSwitch) id 1347461166265410_28981; Wed, 12 Sep 2012 14:46:06 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.239]) by mail118-am1.bigfish.com (Postfix) with ESMTP id 3EAAF4A0097 for ; Wed, 12 Sep 2012 14:46:06 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Sep 2012 14:46:03 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id BB492232122F for ; Wed, 12 Sep 2012 07:42:09 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 010FA23211EA; Wed, 12 Sep 2012 07:42:09 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Sep 2012 07:48:14 -0700 Received: from PDXMB03.tripwire.com ([fe80::284f:fde0:d82f:4223]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 12 Sep 2012 07:46:00 -0700 From: Adam Montville To: "Waltermire, David A." , "Adam W. Montville" Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QABIq4wAAAPCBAP//i14A Date: Wed, 12 Sep 2012 14:45:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC75EDF310CA1amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: ac5a13ab-6c70-4c2d-a458-e0d309269baf X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:46:12 -0000 --_000_CC75EDF310CA1amontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: , "David A." > Date: Wednesday, September 12, 2012 7:43 AM To: "Adam W. Montville" > Cc: "sacm@ietf.org" > Subject: Re: [sacm] FW: SACM BoF Request Adam, Thanks for agreeing to work on this. If you don=92t mind, I=92d like to ta= ke the approach of converting the document as-is for the -00 draft. If any= changes are desired, we can then discuss them on the mailing list, develop= consensus, and then update the documents to reflect the consensus. That w= ay everyone has input into what ends up in the specifications. We may need= to take some liberties with diagrams or data tables that may not convert w= ell. I=92d be happy to help you work through these kinds of issues. No problem =96 happy to help. I think that approach is appropriate, and sh= ould apply to any of the documents we intend to bring in. Sincerely, Dave From: Adam W. Montville [mailto:adam@stoicsecurity.com] Sent: Wednesday, September 12, 2012 10:17 AM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] FW: SACM BoF Request Thank you Dave! I'd be happy to pick up Asset ID. Sent from my iPhone On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." > wrote: I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, G= A. The details are below for anyone interested. At this point we need to = complete preparations for the BoF. To be successful, we will need your par= ticipation in the BoF and your help getting ready. Here are meeting details if you are interested in making travel arrangement= s: http://www.ietf.org/meeting/85/index.html At this point we need additional drafts to be submitted to augment the agen= da and support the BoF. I=92d be happy to work with anyone interested in p= reparing drafts for any of the existing specifications in this area (e.g. C= PE, Asset Identification, ARF, ASR, etc.) We should probably do a direct c= onversion of existing specifications for -00 versions before making any cha= nges. The -00 deadline for the IETF 85 meeting is 10/15 with any updated d= rafts due a week later on 10/22. Any volunteers? We will also need speakers to present drafts. Please let me or Kathleen kn= ow if you are interested in making a short presentation. We also need to continue to refine the charter (included below) and use cas= e documents. Any additional comments/changes would be appreciated. Sincerely, Dave From: Waltermire, David A. Sent: Monday, September 10, 2012 6:45 PM To: 'stephen.farrell@cs.tcd.ie'; 'turners= @ieca.com'; 'Moriarty, Kathleen' Subject: SACM BoF Request Please find the our request for a WG formation BoF below. I have also incl= uded a draft charter that we have been developing with feedback from the SA= CM list. Please let me know if you have any questions or if you would like= any additional details. Sincerely, Dave Waltermire -- BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from= the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation to verify= system configurations with the ability to prioritize risk based on increas= ed situational awareness from shared intelligence is the key to escaping th= is rut. This working group will develop security automation standards in su= pport of information security processes and practices where practical. Thes= e standards will help security practitioners to be better utilized within t= heir organizations by automating routine tasks related to endpoint and serv= er security so that practitioners can focus on more advanced tasks. The ini= tial focus of this work is to address enterprise use cases. The working group will achieve this by consuming shared intelligence and co= ntinuing (with cooperation) the security automation work already performed = by various organizations around the world. The initial work has been fruit= ful, and the data formats previously published are ready for expansion on t= he international stage. Of particular interest to this working group are th= e security automation specifications supporting asset, change, configuratio= n, and vulnerability management. Of additional interest to this working gro= up are the emerging security automation interfaces and data formats relatin= g to event management and continuous assessment. The continuous assessment= capabilities enable organizational situational awareness through frequent = snapshots of the operating state of their environment, with risk prioritize= d based on consumed information provided by shared intelligence (vulnerabil= ities, threats, etc.). By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories, and enabling interoperability thro= ugh the development and use of standard interfaces and communications proto= cols. Content based on rich data standards and protocols will provide the a= uthoritative instructions needed by data-driven tools to enable the automat= ed collection and exchange of configuration and vulnerability data pertaini= ng to enterprise assets. Information produced by these tools will provide a= ccurate and timely situational awareness in support of organizational decis= ion making. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing and aggregating devi= ce states and comparing these device states against expected values, and re= porting on those results in a predefined or ad hoc manner. This area of fo= cus provides for necessary language and data format specifications. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of= systems, composed of many different types of devices and networks, operate= d by varying personnel, to ensure security process effectiveness in a pre-d= efined or ad-hoc manner. This area of focus provides for integration proto= cols supporting plug and play continuous assessment and security automation= networking. This working group will achieve the following milestones in two phases: Phase One - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability - A Standards Track document specifying a control framework representation = format. - A Standards Track document specifying benchmark configuration representat= ion - An Informational document stating guidelines / requirements for specifyin= g checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other co= ntent defined in this group with the NEA protocols Phase Two - Standards Track document specifying security automation/continuous assess= ment interfaces - A Standards Track document specifying communication protocols used for se= curity automation and continuous assessment - A Standards Track document describing the messages and network protocols = for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC75EDF310CA1amontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6B3311CE396F5245870E97140131C452@tripwire.com> Content-Transfer-Encoding: quoted-printable
From: <Waltermire>, "Dav= id A." <david.waltermi= re@nist.gov>
Date: Wednesday, September 12, 2012= 7:43 AM
To: "Adam W. Montville" &= lt;adam@stoicsecurity.com>=
Cc: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] FW: SACM BoF Re= quest

Adam,

 

Thanks for agreeing to= work on this.  If you don=92t mind, I=92d like to take the approach o= f converting the document as-is for the -00 draft.  If any changes are= desired, we can then discuss them on the mailing list, develop consensus, and then update the documents to reflect the cons= ensus.  That way everyone has input into what ends up in the specifica= tions.  We may need to take some liberties with diagrams or data table= s that may not convert well.  I=92d be happy to help you work through these kinds of issues.


No problem =96 happy to help.  I think that approach is appropria= te, and should apply to any of the documents we intend to bring in.




 

Sincerely,

Dave

 

From: Adam W. Montville [mailto:adam@stoicsecurity.com]
Sent: Wednesday, September 12, 2012 10:17 AM
To: Waltermire, David A.
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: SACM BoF Request

 

Thank you Dave!

 

I'd be happy to pick up Asset ID.


Sent from my iPhone


On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." <david.waltermire@nist.gov> wro= te:

I sent in a request to= hold a SACM BoF at the IETF 85 meeting in Atlanta, GA.  The details a= re below for anyone interested.  At this point we need to complete pre= parations for the BoF.  To be successful, we will need your participation in the BoF and your help getting ready.

 

Here are meeting detai= ls if you are interested in making travel arrangements:

 

http://www.ietf.org/meeting/85/index.html

 

At this point we need = additional drafts to be submitted to augment the agenda and support the BoF= .  I=92d be happy to work with anyone interested in preparing drafts f= or any of the existing specifications in this area (e.g. CPE, Asset Identification, ARF, ASR, etc.)  We should prob= ably do a direct conversion of existing specifications for -00 versions bef= ore making any changes.  The -00 deadline for the IETF 85 meeting is 1= 0/15 with any updated drafts due a week later on 10/22.  Any volunteers?

 

We will also need spea= kers to present drafts.  Please let me or Kathleen know if you are int= erested in making a short presentation.

 

We also need to contin= ue to refine the charter (included below) and use case documents. Any addit= ional comments/changes would be appreciated.

 

Sincerely,=

Dave=

 

 

Please find the our request for a WG formation BoF b= elow.  I have also included a draft charter that we have been developi= ng with feedback from the SACM list.  Please let me know if you have a= ny questions or if you would like any additional details.

 

Sincerely,

Dave Waltermire

 

--

 

BOF full name: Security Automation and Continuous Mo= nitoring [SACM]

AREA: Security

BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com)

        &nbs= p;   David Waltermire (david.waltermire@nist.gov)

Agenda:

 

* Review the draft charter

* Review draft-waltermire-sacm-use-cases-02

* Review drafts submitted in support of the charter<= o:p>

  - draft-waltermire-content-repository-00=

  - More expected before -00 deadline

 

Full Description of BOF: The SACM BoF is intended to= progress the work from the SACM mailing list to solidify discussions on a = proposed charter, use cases and milestones in support of moving to an IETF = working group.

 

CONFLICTS to avoid: SAAG, MILE

Expected Attendance: 40, not sure what the previous = attendance was?

Special Requests: Meetecho support

Number of sessions: 1

Length of session: 2 hours

 

Draft Charter:

 

Proposed Working Group Charter

 

Chairs:

TBD

TBD

 

Security Area Directors:

     Stephen Farrell <stephen.farrell@cs.tcd.ie>

     Sean Turner <turners@ieca.com>

 

Security Area Advisor:

     Sean Turner <turners@ieca.com>

 

Mailing Lists:

     General Discussion: sacm@ietf.org

     To Subscribe:  &n= bsp;    http://www.ietf.org/mailman/listinfo/sacm

     Archive:   &= nbsp;        http://www.ietf.org/mail-archive/web/sacm

 

Description of Working Group

 

Securing information and the systems that store, pro= cess, and transmit that information has become a challenging task for organ= izations of all sizes, and we find that security practitioners spend most o= f their time on manual processes relegating them to ineffectiveness. Security automation to verify system configuratio= ns with the ability to prioritize risk based on increased situational aware= ness from shared intelligence is the key to escaping this rut. This working= group will develop security automation standards in support of information security processes and practices where= practical. These standards will help security practitioners to be better u= tilized within their organizations by automating routine tasks related to e= ndpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this = work is to address enterprise use cases.

 

The working group will achieve this by consuming sha= red intelligence and continuing (with cooperation) the security automation = work already performed by various organizations around the world.  The= initial work has been fruitful, and the data formats previously published are ready for expansion on the internati= onal stage. Of particular interest to this working group are the security a= utomation specifications supporting asset, change, configuration, and vulne= rability management. Of additional interest to this working group are the emerging security automation interf= aces and data formats relating to event management and continuous assessmen= t.  The continuous assessment capabilities enable organizational situa= tional awareness through frequent snapshots of the operating state of their environment, with risk prioritized based o= n consumed information provided by shared intelligence (vulnerabilities, th= reats, etc.).

 

By undertaking this work, we recognize that there ar= e multiple categories of problems in the security automation domain: defini= ng expressions for particular domain concepts (i.e. data formats), establis= hing a standards-based foundation supporting the curation and exchange of security automation content collec= tions in content repositories, and enabling interoperability through the de= velopment and use of standard interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritative instructions needed by data-d= riven tools to enable the automated collection and exchange of configuratio= n and vulnerability data pertaining to enterprise assets. Information produ= ced by these tools will provide accurate and timely situational awareness in support of organizational dec= ision making.

 

This working group will provide solutions to these c= ategories of problems and the main areas of focus for this working group ar= e described as follows:

 

1. Define, either by normative reference, adoption, = or creation, a set of standards that can be used for the purpose of assessi= ng and aggregating device states and comparing these device states against = expected values, and reporting on those results in a predefined or ad hoc manner.  This area of focus p= rovides for necessary language and data format specifications.

 

2. Define, either by normative reference, adoption, = or creation, a set of standards that can be used to continuously assess and= report on the state of systems, composed of many different types of device= s and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad= -hoc manner.  This area of focus provides for integration protocols su= pporting plug and play continuous assessment and security automation networ= king.

 

This working group will achieve the following milest= ones in two phases:

 

Phase One

- A Standards Track document specifying asset descri= ption format

- A Standards Track document specifying asset identi= fication

- A Standards Track document specifying platform nam= ing

- A Standards Track document specifying platform mat= ching

- A Standards Track document specifying platform app= licability

- A Standards Track document specifying a control fr= amework representation format.

- A Standards Track document specifying benchmark co= nfiguration representation

- An Informational document stating guidelines / req= uirements for specifying checking languages

- Standards Track documents specifying device state = checking languages

- A Standards Track document specifying an interroga= tive checking language

- A Standards Track document specifying asset report= ing information

- Standards Track document describing how to use the= languages and other content defined in this group with the NEA protocols

 

Phase Two

- Standards Track document specifying security autom= ation/continuous assessment interfaces

- A Standards Track document specifying communicatio= n protocols used for security automation and continuous assessment

- A Standards Track document describing the messages= and network protocols for distributing security automation content  (= content repository)

- A Standards Track document describing protocols an= d data formats for securely sharing dynamic network state information among= security systems

 

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


--_000_CC75EDF310CA1amontvilletripwirecom_-- From david.oliva@verizon.net Wed Sep 12 09:17:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24AB21F84F8 for ; Wed, 12 Sep 2012 09:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, LONGWORDS=1.803, MIME_HTML_ONLY=1.457] 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 2AFd+k33kukb for ; Wed, 12 Sep 2012 09:17:36 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id BADB321F84EE for ; Wed, 12 Sep 2012 09:17:36 -0700 (PDT) Received: from vznit170136pub.verizon.net ([unknown] [192.168.1.3]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MA800DEGVWVGRE0@vms173005.mailsrvcs.net> for sacm@ietf.org; Wed, 12 Sep 2012 11:17:21 -0500 (CDT) Received: from 96.241.166.234 ([96.241.166.234]) by vznit170136 (Verizon Webmail) with HTTP; Wed, 12 Sep 2012 11:17:19 -0500 (CDT) Date: Wed, 12 Sep 2012 11:17:19 -0500 (CDT) From: david.oliva@verizon.net To: david.waltermire@nist.gov, sacm@ietf.org Message-id: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.241.166.234] Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:17:38 -0000
&nb= sp;David:
 
I would like to take on ASR (I pressum= e you are talking about IR 7848 for future SCAP/SACM versions).
&= nbsp;
Which in fact, brings up a question.
 
=
In terms of maturity, how do you know which Interagency Reports will b= e part of future SACM/SCAP versions?
 
David Oliva=
 
 
On 09/12/12, Waltermire, David A.<david.= waltermire@nist.gov> wrote:
 

I sent in a request= to hold a SACM BoF at the IETF 85 meeting in Atlanta, GA.  The detail= s are below for anyone interested.  At this point we need to complete = preparations for the BoF.  To be successful, we will need your partici= pation in the BoF and your help getting ready.

 

Here are meeting details if you are interested = in making travel arrangements:

 

http://www.ietf.org/meeting/85/index.html

 

At this point we need additional draf= ts to be submitted to augment the agenda and support the BoF.  I=E2=80= =99d be happy to work with anyone interested in preparing drafts for any of= the existing specifications in this area (e.g. CPE, Asset Identification, = ARF, ASR, etc.)  We should probably do a direct conversion of existing= specifications for -00 versions before making any changes.  The -00 d= eadline for the IETF 85 meeting is 10/15 with any updated drafts due a week= later on 10/22.  Any volunteers?

 

We will also need speakers to present drafts.  Pl= ease let me or Kathleen know if you are interested in making a short presen= tation.

 = ;

We also nee= d to continue to refine the charter (included below) and use case documents= . Any additional comments/changes would be appreciated.

 

Sincerely,

Dave

 

From:<= /B> Wal= termire, David A.
Sent: Monday, September 10, 2012 6:45 PM
To: 'stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moria= rty, Kathleen'
Subject: SACM BoF Request

 

Please find the our reque= st for a WG formation BoF below.  I have also included a draft charter= that we have been developing with feedback from the SACM list.  Pleas= e let me know if you have any questions or if you would like any additional= details.

 

Sincerely,=

Dave Waltermire

 

=

--

 

BOF full name: Security Automation and Continuous Monitoring [SACM]

=

AREA: Security

BOF Chairs: Kat= hleen Moriarty (kathleen.moriarty@emc.com)

            David = Waltermire (david.waltermire@nist.gov)

Ag= enda:

 

* Review the d= raft charter

* Review draft-waltermire-sacm-use-cas= es-02

* Review drafts submitted in support of the = charter

  - draft-waltermire-content-repositor= y-00

  - More expected before -00 deadline

=

 

Full Description of BOF= : The SACM BoF is intended to progress the work from the SACM mailing list = to solidify discussions on a proposed charter, use cases and milestones in = support of moving to an IETF working group.

 <= /P>

CONFLICTS to avoid: SAAG, MILE

Expected Attendance: 40, not sure what the previous attendance was?

=

Special Requests: Meetecho support

Number of sessions: 1

Length of session: 2 hou= rs

 

Draft Charter:

 

Proposed Working Group= Charter

 

Chairs:

=

TBD

TBD

 

Security Area Directors:

     Stephen Farrell <stephen.farrell@c= s.tcd.ie>

     Sean Turn= er <turners@ieca.com>

 

Security Area Advisor:

   &= nbsp; Sean Turner <turners@ieca.com>

 <= /P>

Mailing Lists:

  =    General Discussion: sacm@ietf.org

 =     To Subscribe:       http://www.= ietf.org/mailman/listinfo/sacm

  &nbs= p;  Archive:         &nbs= p;  http://www.ietf.org/mail-archive/web/sacm

&= nbsp;

Description of Working Group

 

Securing information and the systems= that store, process, and transmit that information has become a challengin= g task for organizations of all sizes, and we find that security practition= ers spend most of their time on manual processes relegating them to ineffec= tiveness. Security automation to verify system configurations with the abil= ity to prioritize risk based on increased situational awareness from shared= intelligence is the key to escaping this rut. This working group will deve= lop security automation standards in support of information security proces= ses and practices where practical. These standards will help security pract= itioners to be better utilized within their organizations by automating rou= tine tasks related to endpoint and server security so that practitioners ca= n focus on more advanced tasks. The initial focus of this work is to addres= s enterprise use cases.

 

The working group will achieve this by consuming shared intelligence a= nd continuing (with cooperation) the security automation work already perfo= rmed by various organizations around the world.  The initial work has = been fruitful, and the data formats previously published are ready for expa= nsion on the international stage. Of particular interest to this working gr= oup are the security automation specifications supporting asset, change, co= nfiguration, and vulnerability management. Of additional interest to this w= orking group are the emerging security automation interfaces and data forma= ts relating to event management and continuous assessment.  The contin= uous assessment capabilities enable organizational situational awareness th= rough frequent snapshots of the operating state of their environment, with = risk prioritized based on consumed information provided by shared intellige= nce (vulnerabilities, threats, etc.).

 

By undertaking this work, we recognize that there are mul= tiple categories of problems in the security automation domain: defining ex= pressions for particular domain concepts (i.e. data formats), establishing = a standards-based foundation supporting the curation and exchange of securi= ty automation content collections in content repositories, and enabling int= eroperability through the development and use of standard interfaces and co= mmunications protocols. Content based on rich data standards and protocols = will provide the authoritative instructions needed by data-driven tools to = enable the automated collection and exchange of configuration and vulnerabi= lity data pertaining to enterprise assets. Information produced by these to= ols will provide accurate and timely situational awareness in support of or= ganizational decision making.

 

This working group will provide solutions to these categories = of problems and the main areas of focus for this working group are describe= d as follows:

 

1. Def= ine, either by normative reference, adoption, or creation, a set of standar= ds that can be used for the purpose of assessing and aggregating device sta= tes and comparing these device states against expected values, and reportin= g on those results in a predefined or ad hoc manner.  This area of foc= us provides for necessary language and data format specifications.

 

2. Define, either by normati= ve reference, adoption, or creation, a set of standards that can be used to= continuously assess and report on the state of systems, composed of many d= ifferent types of devices and networks, operated by varying personnel, to e= nsure security process effectiveness in a pre-defined or ad-hoc manner.&nbs= p; This area of focus provides for integration protocols supporting plug an= d play continuous assessment and security automation networking.

 

This working group will achiev= e the following milestones in two phases:

 

Phase One

- A Standards Track= document specifying asset description format

- A S= tandards Track document specifying asset identification

- A Standards Track document specifying platform naming

- A Standards Track document specifying platform matching

- A Standards Track document specifying platform applicabi= lity

- A Standards Track document specifying a cont= rol framework representation format.

- A Standards = Track document specifying benchmark configuration representation

- An Informational document stating guidelines / requirements= for specifying checking languages

- Standards Trac= k documents specifying device state checking languages

- A Standards Track document specifying an interrogative checking langu= age

- A Standards Track document specifying asset = reporting information

- Standards Track document d= escribing how to use the languages and other content defined in this group = with the NEA protocols

 

Phase Two

- Standards Track document specifying = security automation/continuous assessment interfaces

- A Standards Track document specifying communication protocols used for = security automation and continuous assessment

- A S= tandards Track document describing the messages and network protocols for d= istributing security automation content  (content repository)

- A Standards Track document describing protocols and data = formats for securely sharing dynamic network state information among securi= ty systems

 



___= ____________________________________________
sacm mailing list
sacm@ietf.or= g
https://www.ietf.org/mailman/listinfo/sacm
<= /DIV>
From mdavidson@mitre.org Wed Sep 12 12:58:03 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E34F21F85FC for ; Wed, 12 Sep 2012 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, 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 pIwZGSEmSN5Y for ; Wed, 12 Sep 2012 12:58:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3657021F8613 for ; Wed, 12 Sep 2012 12:58:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8817021B0720; Wed, 12 Sep 2012 15:58:00 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3B26121B0734; Wed, 12 Sep 2012 15:58:00 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.34]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 15:57:59 -0400 From: "Davidson II, Mark S" To: "david.oliva@verizon.net" , "david.waltermire@nist.gov" , "sacm@ietf.org" Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrA Date: Wed, 12 Sep 2012 19:57:59 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> In-Reply-To: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80BD1D17AIMCMBX02MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:58:03 -0000 --_000_69F1FC52EB080B4983863BD1602520D80BD1D17AIMCMBX02MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzIGZvciB0aGUgbGF0ZSByZXNwb25zZSwgSSBkaWRu4oCZdCBnZXQgdG8gdGhp cyBlbWFpbCB1bnRpbCBqdXN0IG5vdy4NCg0KQXMgYW4gb3JpZ2luYWwgYXV0aG9yIGZvciB0aGUg QVNSIHNwZWMsIEnigJlkIGxpa2UgdG8gcGFydGljaXBhdGUgaW4gYnJpbmdpbmcgQVNSIHRvIHRo ZSBJRVRGLiBJcyB0aGF0IGEgcG9zc2liaWxpdHk/DQoNClRoYW5rIHlvdS4NCi1NYXJrIERhdmlk c29uDQoNCkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGRhdmlkLm9saXZhQHZlcml6b24ubmV0DQpTZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMjoxNyBQTQ0KVG86IGRhdmlkLndhbHRlcm1pcmVA bmlzdC5nb3Y7IHNhY21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FjbV0gRlc6IFNBQ00gQm9G IFJlcXVlc3QNCg0KIERhdmlkOg0KDQpJIHdvdWxkIGxpa2UgdG8gdGFrZSBvbiBBU1IgKEkgcHJl c3N1bWUgeW91IGFyZSB0YWxraW5nIGFib3V0IElSIDc4NDggZm9yIGZ1dHVyZSBTQ0FQL1NBQ00g dmVyc2lvbnMpLg0KDQpXaGljaCBpbiBmYWN0LCBicmluZ3MgdXAgYSBxdWVzdGlvbi4NCg0KSW4g dGVybXMgb2YgbWF0dXJpdHksIGhvdyBkbyB5b3Uga25vdyB3aGljaCBJbnRlcmFnZW5jeSBSZXBv cnRzIHdpbGwgYmUgcGFydCBvZiBmdXR1cmUgU0FDTS9TQ0FQIHZlcnNpb25zPw0KDQpEYXZpZCBP bGl2YQ0KDQoNCk9uIDA5LzEyLzEyLCBXYWx0ZXJtaXJlLCBEYXZpZCBBLjxkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292PiB3cm90ZToNCg0KSSBzZW50IGluIGEgcmVxdWVzdCB0byBob2xkIGEgU0FD TSBCb0YgYXQgdGhlIElFVEYgODUgbWVldGluZyBpbiBBdGxhbnRhLCBHQS4gIFRoZSBkZXRhaWxz IGFyZSBiZWxvdyBmb3IgYW55b25lIGludGVyZXN0ZWQuICBBdCB0aGlzIHBvaW50IHdlIG5lZWQg dG8gY29tcGxldGUgcHJlcGFyYXRpb25zIGZvciB0aGUgQm9GLiAgVG8gYmUgc3VjY2Vzc2Z1bCwg d2Ugd2lsbCBuZWVkIHlvdXIgcGFydGljaXBhdGlvbiBpbiB0aGUgQm9GIGFuZCB5b3VyIGhlbHAg Z2V0dGluZyByZWFkeS4NCg0KSGVyZSBhcmUgbWVldGluZyBkZXRhaWxzIGlmIHlvdSBhcmUgaW50 ZXJlc3RlZCBpbiBtYWtpbmcgdHJhdmVsIGFycmFuZ2VtZW50czoNCg0KaHR0cDovL3d3dy5pZXRm Lm9yZy9tZWV0aW5nLzg1L2luZGV4Lmh0bWwNCg0KQXQgdGhpcyBwb2ludCB3ZSBuZWVkIGFkZGl0 aW9uYWwgZHJhZnRzIHRvIGJlIHN1Ym1pdHRlZCB0byBhdWdtZW50IHRoZSBhZ2VuZGEgYW5kIHN1 cHBvcnQgdGhlIEJvRi4gIEnigJlkIGJlIGhhcHB5IHRvIHdvcmsgd2l0aCBhbnlvbmUgaW50ZXJl c3RlZCBpbiBwcmVwYXJpbmcgZHJhZnRzIGZvciBhbnkgb2YgdGhlIGV4aXN0aW5nIHNwZWNpZmlj YXRpb25zIGluIHRoaXMgYXJlYSAoZS5nLiBDUEUsIEFzc2V0IElkZW50aWZpY2F0aW9uLCBBUkYs IEFTUiwgZXRjLikgIFdlIHNob3VsZCBwcm9iYWJseSBkbyBhIGRpcmVjdCBjb252ZXJzaW9uIG9m IGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGZvciAtMDAgdmVyc2lvbnMgYmVmb3JlIG1ha2luZyBh bnkgY2hhbmdlcy4gIFRoZSAtMDAgZGVhZGxpbmUgZm9yIHRoZSBJRVRGIDg1IG1lZXRpbmcgaXMg MTAvMTUgd2l0aCBhbnkgdXBkYXRlZCBkcmFmdHMgZHVlIGEgd2VlayBsYXRlciBvbiAxMC8yMi4g IEFueSB2b2x1bnRlZXJzPw0KDQpXZSB3aWxsIGFsc28gbmVlZCBzcGVha2VycyB0byBwcmVzZW50 IGRyYWZ0cy4gIFBsZWFzZSBsZXQgbWUgb3IgS2F0aGxlZW4ga25vdyBpZiB5b3UgYXJlIGludGVy ZXN0ZWQgaW4gbWFraW5nIGEgc2hvcnQgcHJlc2VudGF0aW9uLg0KDQpXZSBhbHNvIG5lZWQgdG8g Y29udGludWUgdG8gcmVmaW5lIHRoZSBjaGFydGVyIChpbmNsdWRlZCBiZWxvdykgYW5kIHVzZSBj YXNlIGRvY3VtZW50cy4gQW55IGFkZGl0aW9uYWwgY29tbWVudHMvY2hhbmdlcyB3b3VsZCBiZSBh cHByZWNpYXRlZC4NCg0KU2luY2VyZWx5LA0KRGF2ZQ0KDQpGcm9tOiBXYWx0ZXJtaXJlLCBEYXZp ZCBBLg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgNjo0NSBQTQ0KVG86ICdzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPic7 ICd0dXJuZXJzQGllY2EuY29tPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPic7ICdNb3JpYXJ0eSwg S2F0aGxlZW4nDQpTdWJqZWN0OiBTQUNNIEJvRiBSZXF1ZXN0DQoNClBsZWFzZSBmaW5kIHRoZSBv dXIgcmVxdWVzdCBmb3IgYSBXRyBmb3JtYXRpb24gQm9GIGJlbG93LiAgSSBoYXZlIGFsc28gaW5j bHVkZWQgYSBkcmFmdCBjaGFydGVyIHRoYXQgd2UgaGF2ZSBiZWVuIGRldmVsb3Bpbmcgd2l0aCBm ZWVkYmFjayBmcm9tIHRoZSBTQUNNIGxpc3QuICBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhh dmUgYW55IHF1ZXN0aW9ucyBvciBpZiB5b3Ugd291bGQgbGlrZSBhbnkgYWRkaXRpb25hbCBkZXRh aWxzLg0KDQpTaW5jZXJlbHksDQpEYXZlIFdhbHRlcm1pcmUNCg0KLS0NCg0KQk9GIGZ1bGwgbmFt ZTogU2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGludW91cyBNb25pdG9yaW5nIFtTQUNNXQ0K QVJFQTogU2VjdXJpdHkNCkJPRiBDaGFpcnM6IEthdGhsZWVuIE1vcmlhcnR5IChrYXRobGVlbi5t b3JpYXJ0eUBlbWMuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPikNCiAgICAg ICAgICAgIERhdmlkIFdhbHRlcm1pcmUgKGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRv OmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+KQ0KQWdlbmRhOg0KDQoqIFJldmlldyB0aGUgZHJh ZnQgY2hhcnRlcg0KKiBSZXZpZXcgZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0wMg0K KiBSZXZpZXcgZHJhZnRzIHN1Ym1pdHRlZCBpbiBzdXBwb3J0IG9mIHRoZSBjaGFydGVyDQogIC0g ZHJhZnQtd2FsdGVybWlyZS1jb250ZW50LXJlcG9zaXRvcnktMDANCiAgLSBNb3JlIGV4cGVjdGVk IGJlZm9yZSAtMDAgZGVhZGxpbmUNCg0KRnVsbCBEZXNjcmlwdGlvbiBvZiBCT0Y6IFRoZSBTQUNN IEJvRiBpcyBpbnRlbmRlZCB0byBwcm9ncmVzcyB0aGUgd29yayBmcm9tIHRoZSBTQUNNIG1haWxp bmcgbGlzdCB0byBzb2xpZGlmeSBkaXNjdXNzaW9ucyBvbiBhIHByb3Bvc2VkIGNoYXJ0ZXIsIHVz ZSBjYXNlcyBhbmQgbWlsZXN0b25lcyBpbiBzdXBwb3J0IG9mIG1vdmluZyB0byBhbiBJRVRGIHdv cmtpbmcgZ3JvdXAuDQoNCkNPTkZMSUNUUyB0byBhdm9pZDogU0FBRywgTUlMRQ0KRXhwZWN0ZWQg QXR0ZW5kYW5jZTogNDAsIG5vdCBzdXJlIHdoYXQgdGhlIHByZXZpb3VzIGF0dGVuZGFuY2Ugd2Fz Pw0KU3BlY2lhbCBSZXF1ZXN0czogTWVldGVjaG8gc3VwcG9ydA0KTnVtYmVyIG9mIHNlc3Npb25z OiAxDQpMZW5ndGggb2Ygc2Vzc2lvbjogMiBob3Vycw0KDQpEcmFmdCBDaGFydGVyOg0KDQpQcm9w b3NlZCBXb3JraW5nIEdyb3VwIENoYXJ0ZXINCg0KQ2hhaXJzOg0KVEJEDQpUQkQNCg0KU2VjdXJp dHkgQXJlYSBEaXJlY3RvcnM6DQogICAgIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4+DQogICAgIFNlYW4g VHVybmVyIDx0dXJuZXJzQGllY2EuY29tPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPj4NCg0KU2Vj dXJpdHkgQXJlYSBBZHZpc29yOg0KICAgICBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbTxt YWlsdG86dHVybmVyc0BpZWNhLmNvbT4+DQoNCk1haWxpbmcgTGlzdHM6DQogICAgIEdlbmVyYWwg RGlzY3Vzc2lvbjogc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCiAgICAgVG8g U3Vic2NyaWJlOiAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Fj bQ0KICAgICBBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zYWNtDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANCg0KU2VjdXJpbmcg aW5mb3JtYXRpb24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHByb2Nlc3MsIGFuZCB0cmFu c21pdCB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWNvbWUgYSBjaGFsbGVuZ2luZyB0YXNrIGZvciBv cmdhbml6YXRpb25zIG9mIGFsbCBzaXplcywgYW5kIHdlIGZpbmQgdGhhdCBzZWN1cml0eSBwcmFj dGl0aW9uZXJzIHNwZW5kIG1vc3Qgb2YgdGhlaXIgdGltZSBvbiBtYW51YWwgcHJvY2Vzc2VzIHJl bGVnYXRpbmcgdGhlbSB0byBpbmVmZmVjdGl2ZW5lc3MuIFNlY3VyaXR5IGF1dG9tYXRpb24gdG8g dmVyaWZ5IHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aXRoIHRoZSBhYmlsaXR5IHRvIHByaW9yaXRp emUgcmlzayBiYXNlZCBvbiBpbmNyZWFzZWQgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGZyb20gc2hh cmVkIGludGVsbGlnZW5jZSBpcyB0aGUga2V5IHRvIGVzY2FwaW5nIHRoaXMgcnV0LiBUaGlzIHdv cmtpbmcgZ3JvdXAgd2lsbCBkZXZlbG9wIHNlY3VyaXR5IGF1dG9tYXRpb24gc3RhbmRhcmRzIGlu IHN1cHBvcnQgb2YgaW5mb3JtYXRpb24gc2VjdXJpdHkgcHJvY2Vzc2VzIGFuZCBwcmFjdGljZXMg d2hlcmUgcHJhY3RpY2FsLiBUaGVzZSBzdGFuZGFyZHMgd2lsbCBoZWxwIHNlY3VyaXR5IHByYWN0 aXRpb25lcnMgdG8gYmUgYmV0dGVyIHV0aWxpemVkIHdpdGhpbiB0aGVpciBvcmdhbml6YXRpb25z IGJ5IGF1dG9tYXRpbmcgcm91dGluZSB0YXNrcyByZWxhdGVkIHRvIGVuZHBvaW50IGFuZCBzZXJ2 ZXIgc2VjdXJpdHkgc28gdGhhdCBwcmFjdGl0aW9uZXJzIGNhbiBmb2N1cyBvbiBtb3JlIGFkdmFu Y2VkIHRhc2tzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgdG8gYWRkcmVzcyBl bnRlcnByaXNlIHVzZSBjYXNlcy4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhY2hpZXZlIHRo aXMgYnkgY29uc3VtaW5nIHNoYXJlZCBpbnRlbGxpZ2VuY2UgYW5kIGNvbnRpbnVpbmcgKHdpdGgg Y29vcGVyYXRpb24pIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIHdvcmsgYWxyZWFkeSBwZXJmb3Jt ZWQgYnkgdmFyaW91cyBvcmdhbml6YXRpb25zIGFyb3VuZCB0aGUgd29ybGQuICBUaGUgaW5pdGlh bCB3b3JrIGhhcyBiZWVuIGZydWl0ZnVsLCBhbmQgdGhlIGRhdGEgZm9ybWF0cyBwcmV2aW91c2x5 IHB1Ymxpc2hlZCBhcmUgcmVhZHkgZm9yIGV4cGFuc2lvbiBvbiB0aGUgaW50ZXJuYXRpb25hbCBz dGFnZS4gT2YgcGFydGljdWxhciBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRo ZSBzZWN1cml0eSBhdXRvbWF0aW9uIHNwZWNpZmljYXRpb25zIHN1cHBvcnRpbmcgYXNzZXQsIGNo YW5nZSwgY29uZmlndXJhdGlvbiwgYW5kIHZ1bG5lcmFiaWxpdHkgbWFuYWdlbWVudC4gT2YgYWRk aXRpb25hbCBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRoZSBlbWVyZ2luZyBz ZWN1cml0eSBhdXRvbWF0aW9uIGludGVyZmFjZXMgYW5kIGRhdGEgZm9ybWF0cyByZWxhdGluZyB0 byBldmVudCBtYW5hZ2VtZW50IGFuZCBjb250aW51b3VzIGFzc2Vzc21lbnQuICBUaGUgY29udGlu dW91cyBhc3Nlc3NtZW50IGNhcGFiaWxpdGllcyBlbmFibGUgb3JnYW5pemF0aW9uYWwgc2l0dWF0 aW9uYWwgYXdhcmVuZXNzIHRocm91Z2ggZnJlcXVlbnQgc25hcHNob3RzIG9mIHRoZSBvcGVyYXRp bmcgc3RhdGUgb2YgdGhlaXIgZW52aXJvbm1lbnQsIHdpdGggcmlzayBwcmlvcml0aXplZCBiYXNl ZCBvbiBjb25zdW1lZCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBzaGFyZWQgaW50ZWxsaWdlbmNl ICh2dWxuZXJhYmlsaXRpZXMsIHRocmVhdHMsIGV0Yy4pLg0KDQpCeSB1bmRlcnRha2luZyB0aGlz IHdvcmssIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBjYXRlZ29yaWVzIG9m IHByb2JsZW1zIGluIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIGRvbWFpbjogZGVmaW5pbmcgZXhw cmVzc2lvbnMgZm9yIHBhcnRpY3VsYXIgZG9tYWluIGNvbmNlcHRzIChpLmUuIGRhdGEgZm9ybWF0 cyksIGVzdGFibGlzaGluZyBhIHN0YW5kYXJkcy1iYXNlZCBmb3VuZGF0aW9uIHN1cHBvcnRpbmcg dGhlIGN1cmF0aW9uIGFuZCBleGNoYW5nZSBvZiBzZWN1cml0eSBhdXRvbWF0aW9uIGNvbnRlbnQg Y29sbGVjdGlvbnMgaW4gY29udGVudCByZXBvc2l0b3JpZXMsIGFuZCBlbmFibGluZyBpbnRlcm9w ZXJhYmlsaXR5IHRocm91Z2ggdGhlIGRldmVsb3BtZW50IGFuZCB1c2Ugb2Ygc3RhbmRhcmQgaW50 ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzLiBDb250ZW50IGJhc2VkIG9uIHJp Y2ggZGF0YSBzdGFuZGFyZHMgYW5kIHByb3RvY29scyB3aWxsIHByb3ZpZGUgdGhlIGF1dGhvcml0 YXRpdmUgaW5zdHJ1Y3Rpb25zIG5lZWRlZCBieSBkYXRhLWRyaXZlbiB0b29scyB0byBlbmFibGUg dGhlIGF1dG9tYXRlZCBjb2xsZWN0aW9uIGFuZCBleGNoYW5nZSBvZiBjb25maWd1cmF0aW9uIGFu ZCB2dWxuZXJhYmlsaXR5IGRhdGEgcGVydGFpbmluZyB0byBlbnRlcnByaXNlIGFzc2V0cy4gSW5m b3JtYXRpb24gcHJvZHVjZWQgYnkgdGhlc2UgdG9vbHMgd2lsbCBwcm92aWRlIGFjY3VyYXRlIGFu ZCB0aW1lbHkgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGluIHN1cHBvcnQgb2Ygb3JnYW5pemF0aW9u YWwgZGVjaXNpb24gbWFraW5nLg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm92aWRlIHNv bHV0aW9ucyB0byB0aGVzZSBjYXRlZ29yaWVzIG9mIHByb2JsZW1zIGFuZCB0aGUgbWFpbiBhcmVh cyBvZiBmb2N1cyBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIGFyZSBkZXNjcmliZWQgYXMgZm9sbG93 czoNCg0KMS4gRGVmaW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRvcHRpb24s IG9yIGNyZWF0aW9uLCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgdGhl IHB1cnBvc2Ugb2YgYXNzZXNzaW5nIGFuZCBhZ2dyZWdhdGluZyBkZXZpY2Ugc3RhdGVzIGFuZCBj b21wYXJpbmcgdGhlc2UgZGV2aWNlIHN0YXRlcyBhZ2FpbnN0IGV4cGVjdGVkIHZhbHVlcywgYW5k IHJlcG9ydGluZyBvbiB0aG9zZSByZXN1bHRzIGluIGEgcHJlZGVmaW5lZCBvciBhZCBob2MgbWFu bmVyLiAgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBuZWNlc3NhcnkgbGFuZ3VhZ2Ug YW5kIGRhdGEgZm9ybWF0IHNwZWNpZmljYXRpb25zLg0KDQoyLiBEZWZpbmUsIGVpdGhlciBieSBu b3JtYXRpdmUgcmVmZXJlbmNlLCBhZG9wdGlvbiwgb3IgY3JlYXRpb24sIGEgc2V0IG9mIHN0YW5k YXJkcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGNvbnRpbnVvdXNseSBhc3Nlc3MgYW5kIHJlcG9ydCBv biB0aGUgc3RhdGUgb2Ygc3lzdGVtcywgY29tcG9zZWQgb2YgbWFueSBkaWZmZXJlbnQgdHlwZXMg b2YgZGV2aWNlcyBhbmQgbmV0d29ya3MsIG9wZXJhdGVkIGJ5IHZhcnlpbmcgcGVyc29ubmVsLCB0 byBlbnN1cmUgc2VjdXJpdHkgcHJvY2VzcyBlZmZlY3RpdmVuZXNzIGluIGEgcHJlLWRlZmluZWQg b3IgYWQtaG9jIG1hbm5lci4gIFRoaXMgYXJlYSBvZiBmb2N1cyBwcm92aWRlcyBmb3IgaW50ZWdy YXRpb24gcHJvdG9jb2xzIHN1cHBvcnRpbmcgcGx1ZyBhbmQgcGxheSBjb250aW51b3VzIGFzc2Vz c21lbnQgYW5kIHNlY3VyaXR5IGF1dG9tYXRpb24gbmV0d29ya2luZy4NCg0KVGhpcyB3b3JraW5n IGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZXMgaW4gdHdvIHBoYXNl czoNCg0KUGhhc2UgT25lDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcg YXNzZXQgZGVzY3JpcHRpb24gZm9ybWF0DQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNw ZWNpZnlpbmcgYXNzZXQgaWRlbnRpZmljYXRpb24NCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1l bnQgc3BlY2lmeWluZyBwbGF0Zm9ybSBuYW1pbmcNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1l bnQgc3BlY2lmeWluZyBwbGF0Zm9ybSBtYXRjaGluZw0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1 bWVudCBzcGVjaWZ5aW5nIHBsYXRmb3JtIGFwcGxpY2FiaWxpdHkNCi0gQSBTdGFuZGFyZHMgVHJh Y2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhIGNvbnRyb2wgZnJhbWV3b3JrIHJlcHJlc2VudGF0aW9u IGZvcm1hdC4NCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBiZW5jaG1h cmsgY29uZmlndXJhdGlvbiByZXByZXNlbnRhdGlvbg0KLSBBbiBJbmZvcm1hdGlvbmFsIGRvY3Vt ZW50IHN0YXRpbmcgZ3VpZGVsaW5lcyAvIHJlcXVpcmVtZW50cyBmb3Igc3BlY2lmeWluZyBjaGVj a2luZyBsYW5ndWFnZXMNCi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cyBzcGVjaWZ5aW5nIGRl dmljZSBzdGF0ZSBjaGVja2luZyBsYW5ndWFnZXMNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1l bnQgc3BlY2lmeWluZyBhbiBpbnRlcnJvZ2F0aXZlIGNoZWNraW5nIGxhbmd1YWdlDQotIEEgU3Rh bmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYXNzZXQgcmVwb3J0aW5nIGluZm9ybWF0 aW9uDQotIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmliaW5nIGhvdyB0byB1c2UgdGhl IGxhbmd1YWdlcyBhbmQgb3RoZXIgY29udGVudCBkZWZpbmVkIGluIHRoaXMgZ3JvdXAgd2l0aCB0 aGUgTkVBIHByb3RvY29scw0KDQpQaGFzZSBUd28NCi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50 IHNwZWNpZnlpbmcgc2VjdXJpdHkgYXV0b21hdGlvbi9jb250aW51b3VzIGFzc2Vzc21lbnQgaW50 ZXJmYWNlcw0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGNvbW11bmlj YXRpb24gcHJvdG9jb2xzIHVzZWQgZm9yIHNlY3VyaXR5IGF1dG9tYXRpb24gYW5kIGNvbnRpbnVv dXMgYXNzZXNzbWVudA0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmliaW5nIHRo ZSBtZXNzYWdlcyBhbmQgbmV0d29yayBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGluZyBzZWN1cml0 eSBhdXRvbWF0aW9uIGNvbnRlbnQgIChjb250ZW50IHJlcG9zaXRvcnkpDQotIEEgU3RhbmRhcmRz IFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIGZvcm1hdHMgZm9y IHNlY3VyZWx5IHNoYXJpbmcgZHluYW1pYyBuZXR3b3JrIHN0YXRlIGluZm9ybWF0aW9uIGFtb25n IHNlY3VyaXR5IHN5c3RlbXMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2FjbSBt YWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg== --_000_69F1FC52EB080B4983863BD1602520D80BD1D17AIMCMBX02MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk15IGFwb2xvZ2llcyBmb3IgdGhlIGxhdGUgcmVzcG9uc2UsIEkgZGlkbuKAmXQgZ2V0IHRvIHRo aXMgZW1haWwgdW50aWwganVzdCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBhbiBvcmlnaW5hbCBhdXRob3Ig Zm9yIHRoZSBBU1Igc3BlYywgSeKAmWQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiBicmluZ2luZyBB U1IgdG8gdGhlIElFVEYuIElzIHRoYXQgYSBwb3NzaWJpbGl0eT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlv dS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU1hcmsgRGF2aWRzb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPmRhdmlkLm9saXZhQHZlcml6b24ubmV0PGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDEyOjE3IFBNPGJyPg0KPGI+VG86PC9i PiBkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292OyBzYWNtQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbc2FjbV0gRlc6IFNBQ00gQm9GIFJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwO0RhdmlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgd291bGQgbGlrZSB0byB0YWtl IG9uIEFTUiAoSSBwcmVzc3VtZSB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgSVIgNzg0OCBmb3IgZnV0 dXJlIFNDQVAvU0FDTSB2ZXJzaW9ucykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2hpY2ggaW4g ZmFjdCwgYnJpbmdzIHVwIGEgcXVlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SW4gdGVy bXMgb2YgbWF0dXJpdHksIGhvdyBkbyB5b3Uga25vdyB3aGljaCBJbnRlcmFnZW5jeSBSZXBvcnRz IHdpbGwgYmUgcGFydCBvZiBmdXR1cmUgU0FDTS9TQ0FQIHZlcnNpb25zPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkRhdmlkIE9saXZhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiAw OS8xMi8xMiwgV2FsdGVybWlyZSwgRGF2aWQgQS4mbHQ7ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdv diZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SSBzZW50IGluIGEgcmVxdWVzdCB0byBob2xkIGEgU0FDTSBC b0YgYXQgdGhlIElFVEYgODUgbWVldGluZyBpbiBBdGxhbnRhLCBHQS4mbmJzcDsgVGhlIGRldGFp bHMgYXJlIGJlbG93IGZvciBhbnlvbmUgaW50ZXJlc3RlZC4mbmJzcDsgQXQgdGhpcyBwb2ludCB3 ZSBuZWVkIHRvIGNvbXBsZXRlIHByZXBhcmF0aW9ucyBmb3IgdGhlIEJvRi4mbmJzcDsgVG8gYmUg c3VjY2Vzc2Z1bCwgd2Ugd2lsbCBuZWVkIHlvdXIgcGFydGljaXBhdGlvbg0KIGluIHRoZSBCb0Yg YW5kIHlvdXIgaGVscCBnZXR0aW5nIHJlYWR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SGVyZSBhcmUgbWVldGluZyBkZXRhaWxzIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBtYWtp bmcgdHJhdmVsIGFycmFuZ2VtZW50czo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NS9pbmRleC5odG1sIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg1L2luZGV4Lmh0bWw8L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BdCB0aGlzIHBvaW50IHdlIG5lZWQgYWRkaXRp b25hbCBkcmFmdHMgdG8gYmUgc3VibWl0dGVkIHRvIGF1Z21lbnQgdGhlIGFnZW5kYSBhbmQgc3Vw cG9ydCB0aGUgQm9GLiZuYnNwOyBJ4oCZZCBiZSBoYXBweSB0byB3b3JrIHdpdGggYW55b25lIGlu dGVyZXN0ZWQgaW4gcHJlcGFyaW5nIGRyYWZ0cyBmb3IgYW55IG9mIHRoZSBleGlzdGluZyBzcGVj aWZpY2F0aW9ucyBpbiB0aGlzIGFyZWEgKGUuZy4gQ1BFLCBBc3NldA0KIElkZW50aWZpY2F0aW9u LCBBUkYsIEFTUiwgZXRjLikmbmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5IGRvIGEgZGlyZWN0IGNv bnZlcnNpb24gb2YgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgZm9yIC0wMCB2ZXJzaW9ucyBiZWZv cmUgbWFraW5nIGFueSBjaGFuZ2VzLiZuYnNwOyBUaGUgLTAwIGRlYWRsaW5lIGZvciB0aGUgSUVU RiA4NSBtZWV0aW5nIGlzIDEwLzE1IHdpdGggYW55IHVwZGF0ZWQgZHJhZnRzIGR1ZSBhIHdlZWsg bGF0ZXIgb24gMTAvMjIuJm5ic3A7IEFueSB2b2x1bnRlZXJzPw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5XZSB3aWxsIGFsc28gbmVlZCBzcGVha2VycyB0byBwcmVzZW50IGRyYWZ0 cy4mbmJzcDsgUGxlYXNlIGxldCBtZSBvciBLYXRobGVlbiBrbm93IGlmIHlvdSBhcmUgaW50ZXJl c3RlZCBpbiBtYWtpbmcgYSBzaG9ydCBwcmVzZW50YXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5XZSBhbHNvIG5lZWQgdG8gY29udGludWUgdG8gcmVmaW5lIHRoZSBjaGFydGVy IChpbmNsdWRlZCBiZWxvdykgYW5kIHVzZSBjYXNlIGRvY3VtZW50cy4gQW55IGFkZGl0aW9uYWwg Y29tbWVudHMvY2hhbmdlcyB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNpbmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGF2ZTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gV2FsdGVybWlyZSwgRGF2aWQgQS4NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiA2OjQ1IFBNPGJyPg0KPGI+VG86PC9i PiAnPGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2Js YW5rIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPic7ICc8YSBocmVmPSJtYWlsdG86dHVy bmVyc0BpZWNhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR1cm5lcnNAaWVjYS5jb208L2E+JzsgJ01v cmlhcnR5LCBLYXRobGVlbic8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU0FDTSBCb0YgUmVxdWVzdDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UGxlYXNlIGZpbmQgdGhlIG91ciByZXF1ZXN0IGZvciBhIFdHIGZvcm1hdGlvbiBC b0YgYmVsb3cuJm5ic3A7IEkgaGF2ZSBhbHNvIGluY2x1ZGVkIGEgZHJhZnQgY2hhcnRlciB0aGF0 IHdlIGhhdmUgYmVlbiBkZXZlbG9waW5nIHdpdGggZmVlZGJhY2sgZnJvbSB0aGUgU0FDTSBsaXN0 LiZuYnNwOyBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBp ZiB5b3Ugd291bGQgbGlrZSBhbnkgYWRkaXRpb25hbA0KIGRldGFpbHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhdmUgV2Fs dGVybWlyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CT0YgZnVsbCBu YW1lOiBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3JpbmcgW1NBQ01d PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BUkVBOiBTZWN1cml0eTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Qk9GIENoYWlyczogS2F0aGxlZW4gTW9yaWFydHkg KDxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tIiB0YXJnZXQ9Il9ibGFu ayI+a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTwvYT4pPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2aWQgV2FsdGVybWlyZSAoPGEgaHJlZj0ibWFpbHRvOmRh dmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiIHRhcmdldD0iX2JsYW5rIj5kYXZpZC53YWx0ZXJtaXJl QG5pc3QuZ292PC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFnZW5kYTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+KiBSZXZpZXcgdGhlIGRyYWZ0IGNoYXJ0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiogUmV2aWV3IGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2Ut Y2FzZXMtMDIgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4qIFJldmlldyBkcmFm dHMgc3VibWl0dGVkIGluIHN1cHBvcnQgb2YgdGhlIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIGRyYWZ0LXdhbHRlcm1pcmUtY29udGVudC1yZXBvc2l0 b3J5LTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBNb3JlIGV4 cGVjdGVkIGJlZm9yZSAtMDAgZGVhZGxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnVsbCBEZXNjcmlw dGlvbiBvZiBCT0Y6IFRoZSBTQUNNIEJvRiBpcyBpbnRlbmRlZCB0byBwcm9ncmVzcyB0aGUgd29y ayBmcm9tIHRoZSBTQUNNIG1haWxpbmcgbGlzdCB0byBzb2xpZGlmeSBkaXNjdXNzaW9ucyBvbiBh IHByb3Bvc2VkIGNoYXJ0ZXIsIHVzZSBjYXNlcyBhbmQgbWlsZXN0b25lcyBpbiBzdXBwb3J0IG9m IG1vdmluZyB0byBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNPTkZM SUNUUyB0byBhdm9pZDogU0FBRywgTUlMRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+RXhwZWN0ZWQgQXR0ZW5kYW5jZTogNDAsIG5vdCBzdXJlIHdoYXQgdGhlIHByZXZpb3VzIGF0 dGVuZGFuY2Ugd2FzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U3BlY2lhbCBS ZXF1ZXN0czogTWVldGVjaG8gc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+TnVtYmVyIG9mIHNlc3Npb25zOiAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5MZW5ndGggb2Ygc2Vzc2lvbjogMiBob3VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EcmFmdCBDaGFy dGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Qcm9wb3NlZCBXb3JraW5nIEdyb3VwIENoYXJ0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Q2hhaXJzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ VEJEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UQkQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+U2VjdXJpdHkgQXJlYSBEaXJlY3RvcnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVm PSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJt YWlsdG86dHVybmVyc0BpZWNhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR1cm5lcnNAaWVjYS5jb208 L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN1cml0eSBBcmVhIEFkdmlzb3I6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VhbiBU dXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dHVybmVyc0BpZWNhLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1haWxpbmcgTGlz dHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR2VuZXJhbCBEaXNjdXNzaW9uOiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPg0Kc2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbyBTdWJzY3JpYmU6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcmNoaXZlOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2FjbSIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY208L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+U2VjdXJpbmcgaW5mb3JtYXRpb24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHBy b2Nlc3MsIGFuZCB0cmFuc21pdCB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWNvbWUgYSBjaGFsbGVu Z2luZyB0YXNrIGZvciBvcmdhbml6YXRpb25zIG9mIGFsbCBzaXplcywgYW5kIHdlIGZpbmQgdGhh dCBzZWN1cml0eSBwcmFjdGl0aW9uZXJzIHNwZW5kIG1vc3Qgb2YgdGhlaXIgdGltZSBvbiBtYW51 YWwgcHJvY2Vzc2VzDQogcmVsZWdhdGluZyB0aGVtIHRvIGluZWZmZWN0aXZlbmVzcy4gU2VjdXJp dHkgYXV0b21hdGlvbiB0byB2ZXJpZnkgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIHdpdGggdGhlIGFi aWxpdHkgdG8gcHJpb3JpdGl6ZSByaXNrIGJhc2VkIG9uIGluY3JlYXNlZCBzaXR1YXRpb25hbCBh d2FyZW5lc3MgZnJvbSBzaGFyZWQgaW50ZWxsaWdlbmNlIGlzIHRoZSBrZXkgdG8gZXNjYXBpbmcg dGhpcyBydXQuIFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Agc2VjdXJpdHkNCiBhdXRv bWF0aW9uIHN0YW5kYXJkcyBpbiBzdXBwb3J0IG9mIGluZm9ybWF0aW9uIHNlY3VyaXR5IHByb2Nl c3NlcyBhbmQgcHJhY3RpY2VzIHdoZXJlIHByYWN0aWNhbC4gVGhlc2Ugc3RhbmRhcmRzIHdpbGwg aGVscCBzZWN1cml0eSBwcmFjdGl0aW9uZXJzIHRvIGJlIGJldHRlciB1dGlsaXplZCB3aXRoaW4g dGhlaXIgb3JnYW5pemF0aW9ucyBieSBhdXRvbWF0aW5nIHJvdXRpbmUgdGFza3MgcmVsYXRlZCB0 byBlbmRwb2ludCBhbmQgc2VydmVyIHNlY3VyaXR5DQogc28gdGhhdCBwcmFjdGl0aW9uZXJzIGNh biBmb2N1cyBvbiBtb3JlIGFkdmFuY2VkIHRhc2tzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGlz IHdvcmsgaXMgdG8gYWRkcmVzcyBlbnRlcnByaXNlIHVzZSBjYXNlcy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgd29ya2luZyBncm91cCB3aWxsIGFjaGlldmUgdGhpcyBieSBjb25zdW1pbmcgc2hh cmVkIGludGVsbGlnZW5jZSBhbmQgY29udGludWluZyAod2l0aCBjb29wZXJhdGlvbikgdGhlIHNl Y3VyaXR5IGF1dG9tYXRpb24gd29yayBhbHJlYWR5IHBlcmZvcm1lZCBieSB2YXJpb3VzIG9yZ2Fu aXphdGlvbnMgYXJvdW5kIHRoZSB3b3JsZC4mbmJzcDsgVGhlIGluaXRpYWwgd29yayBoYXMgYmVl biBmcnVpdGZ1bCwgYW5kDQogdGhlIGRhdGEgZm9ybWF0cyBwcmV2aW91c2x5IHB1Ymxpc2hlZCBh cmUgcmVhZHkgZm9yIGV4cGFuc2lvbiBvbiB0aGUgaW50ZXJuYXRpb25hbCBzdGFnZS4gT2YgcGFy dGljdWxhciBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRoZSBzZWN1cml0eSBh dXRvbWF0aW9uIHNwZWNpZmljYXRpb25zIHN1cHBvcnRpbmcgYXNzZXQsIGNoYW5nZSwgY29uZmln dXJhdGlvbiwgYW5kIHZ1bG5lcmFiaWxpdHkgbWFuYWdlbWVudC4gT2YgYWRkaXRpb25hbA0KIGlu dGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91cCBhcmUgdGhlIGVtZXJnaW5nIHNlY3VyaXR5IGF1 dG9tYXRpb24gaW50ZXJmYWNlcyBhbmQgZGF0YSBmb3JtYXRzIHJlbGF0aW5nIHRvIGV2ZW50IG1h bmFnZW1lbnQgYW5kIGNvbnRpbnVvdXMgYXNzZXNzbWVudC4mbmJzcDsgVGhlIGNvbnRpbnVvdXMg YXNzZXNzbWVudCBjYXBhYmlsaXRpZXMgZW5hYmxlIG9yZ2FuaXphdGlvbmFsIHNpdHVhdGlvbmFs IGF3YXJlbmVzcyB0aHJvdWdoIGZyZXF1ZW50IHNuYXBzaG90cw0KIG9mIHRoZSBvcGVyYXRpbmcg c3RhdGUgb2YgdGhlaXIgZW52aXJvbm1lbnQsIHdpdGggcmlzayBwcmlvcml0aXplZCBiYXNlZCBv biBjb25zdW1lZCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBzaGFyZWQgaW50ZWxsaWdlbmNlICh2 dWxuZXJhYmlsaXRpZXMsIHRocmVhdHMsIGV0Yy4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CeSB1bmRl cnRha2luZyB0aGlzIHdvcmssIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBj YXRlZ29yaWVzIG9mIHByb2JsZW1zIGluIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIGRvbWFpbjog ZGVmaW5pbmcgZXhwcmVzc2lvbnMgZm9yIHBhcnRpY3VsYXIgZG9tYWluIGNvbmNlcHRzIChpLmUu IGRhdGEgZm9ybWF0cyksIGVzdGFibGlzaGluZyBhIHN0YW5kYXJkcy1iYXNlZCBmb3VuZGF0aW9u DQogc3VwcG9ydGluZyB0aGUgY3VyYXRpb24gYW5kIGV4Y2hhbmdlIG9mIHNlY3VyaXR5IGF1dG9t YXRpb24gY29udGVudCBjb2xsZWN0aW9ucyBpbiBjb250ZW50IHJlcG9zaXRvcmllcywgYW5kIGVu YWJsaW5nIGludGVyb3BlcmFiaWxpdHkgdGhyb3VnaCB0aGUgZGV2ZWxvcG1lbnQgYW5kIHVzZSBv ZiBzdGFuZGFyZCBpbnRlcmZhY2VzIGFuZCBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMuIENvbnRl bnQgYmFzZWQgb24gcmljaCBkYXRhIHN0YW5kYXJkcw0KIGFuZCBwcm90b2NvbHMgd2lsbCBwcm92 aWRlIHRoZSBhdXRob3JpdGF0aXZlIGluc3RydWN0aW9ucyBuZWVkZWQgYnkgZGF0YS1kcml2ZW4g dG9vbHMgdG8gZW5hYmxlIHRoZSBhdXRvbWF0ZWQgY29sbGVjdGlvbiBhbmQgZXhjaGFuZ2Ugb2Yg Y29uZmlndXJhdGlvbiBhbmQgdnVsbmVyYWJpbGl0eSBkYXRhIHBlcnRhaW5pbmcgdG8gZW50ZXJw cmlzZSBhc3NldHMuIEluZm9ybWF0aW9uIHByb2R1Y2VkIGJ5IHRoZXNlIHRvb2xzIHdpbGwgcHJv dmlkZQ0KIGFjY3VyYXRlIGFuZCB0aW1lbHkgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGluIHN1cHBv cnQgb2Ygb3JnYW5pemF0aW9uYWwgZGVjaXNpb24gbWFraW5nLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRoaXMgd29ya2luZyBncm91cCB3aWxsIHByb3ZpZGUgc29sdXRpb25zIHRvIHRoZXNlIGNhdGVn b3JpZXMgb2YgcHJvYmxlbXMgYW5kIHRoZSBtYWluIGFyZWFzIG9mIGZvY3VzIGZvciB0aGlzIHdv cmtpbmcgZ3JvdXAgYXJlIGRlc2NyaWJlZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4x LiBEZWZpbmUsIGVpdGhlciBieSBub3JtYXRpdmUgcmVmZXJlbmNlLCBhZG9wdGlvbiwgb3IgY3Jl YXRpb24sIGEgc2V0IG9mIHN0YW5kYXJkcyB0aGF0IGNhbiBiZSB1c2VkIGZvciB0aGUgcHVycG9z ZSBvZiBhc3Nlc3NpbmcgYW5kIGFnZ3JlZ2F0aW5nIGRldmljZSBzdGF0ZXMgYW5kIGNvbXBhcmlu ZyB0aGVzZSBkZXZpY2Ugc3RhdGVzIGFnYWluc3QgZXhwZWN0ZWQgdmFsdWVzLCBhbmQgcmVwb3J0 aW5nDQogb24gdGhvc2UgcmVzdWx0cyBpbiBhIHByZWRlZmluZWQgb3IgYWQgaG9jIG1hbm5lci4m bmJzcDsgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBuZWNlc3NhcnkgbGFuZ3VhZ2Ug YW5kIGRhdGEgZm9ybWF0IHNwZWNpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiBEZWZp bmUsIGVpdGhlciBieSBub3JtYXRpdmUgcmVmZXJlbmNlLCBhZG9wdGlvbiwgb3IgY3JlYXRpb24s IGEgc2V0IG9mIHN0YW5kYXJkcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGNvbnRpbnVvdXNseSBhc3Nl c3MgYW5kIHJlcG9ydCBvbiB0aGUgc3RhdGUgb2Ygc3lzdGVtcywgY29tcG9zZWQgb2YgbWFueSBk aWZmZXJlbnQgdHlwZXMgb2YgZGV2aWNlcyBhbmQgbmV0d29ya3MsIG9wZXJhdGVkIGJ5IHZhcnlp bmcNCiBwZXJzb25uZWwsIHRvIGVuc3VyZSBzZWN1cml0eSBwcm9jZXNzIGVmZmVjdGl2ZW5lc3Mg aW4gYSBwcmUtZGVmaW5lZCBvciBhZC1ob2MgbWFubmVyLiZuYnNwOyBUaGlzIGFyZWEgb2YgZm9j dXMgcHJvdmlkZXMgZm9yIGludGVncmF0aW9uIHByb3RvY29scyBzdXBwb3J0aW5nIHBsdWcgYW5k IHBsYXkgY29udGludW91cyBhc3Nlc3NtZW50IGFuZCBzZWN1cml0eSBhdXRvbWF0aW9uIG5ldHdv cmtpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgd29ya2luZyBncm91cCB3aWxsIGFjaGlldmUg dGhlIGZvbGxvd2luZyBtaWxlc3RvbmVzIGluIHR3byBwaGFzZXM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlBoYXNlIE9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0YW5kYXJk cyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IGRlc2NyaXB0aW9uIGZvcm1hdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVu dCBzcGVjaWZ5aW5nIGFzc2V0IGlkZW50aWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZv cm0gbmFtaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRz IFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gbWF0Y2hpbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lm eWluZyBwbGF0Zm9ybSBhcHBsaWNhYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYSBjb250cm9sIGZy YW1ld29yayByZXByZXNlbnRhdGlvbiBmb3JtYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYmVuY2htYXJr IGNvbmZpZ3VyYXRpb24gcmVwcmVzZW50YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPi0gQW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCBzdGF0aW5nIGd1aWRlbGluZXMgLyBy ZXF1aXJlbWVudHMgZm9yIHNwZWNpZnlpbmcgY2hlY2tpbmcgbGFuZ3VhZ2VzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudHMgc3BlY2lm eWluZyBkZXZpY2Ugc3RhdGUgY2hlY2tpbmcgbGFuZ3VhZ2VzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYW4g aW50ZXJyb2dhdGl2ZSBjaGVja2luZyBsYW5ndWFnZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYXNzZXQg cmVwb3J0aW5nIGluZm9ybWF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgaG93IHRvIHVzZSB0aGUgbGFu Z3VhZ2VzIGFuZCBvdGhlciBjb250ZW50IGRlZmluZWQgaW4gdGhpcyBncm91cCB3aXRoIHRoZSBO RUEgcHJvdG9jb2xzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoYXNlIFR3bzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+LSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBz ZWN1cml0eSBhdXRvbWF0aW9uL2NvbnRpbnVvdXMgYXNzZXNzbWVudCBpbnRlcmZhY2VzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50 IHNwZWNpZnlpbmcgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgdXNlZCBmb3Igc2VjdXJpdHkgYXV0 b21hdGlvbiBhbmQgY29udGludW91cyBhc3Nlc3NtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIG1l c3NhZ2VzIGFuZCBuZXR3b3JrIHByb3RvY29scyBmb3IgZGlzdHJpYnV0aW5nIHNlY3VyaXR5IGF1 dG9tYXRpb24gY29udGVudCZuYnNwOyAoY29udGVudCByZXBvc2l0b3J5KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmli aW5nIHByb3RvY29scyBhbmQgZGF0YSBmb3JtYXRzIGZvciBzZWN1cmVseSBzaGFyaW5nIGR5bmFt aWMgbmV0d29yayBzdGF0ZSBpbmZvcm1hdGlvbiBhbW9uZyBzZWN1cml0eSBzeXN0ZW1zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNhY20gbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zYWNtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_69F1FC52EB080B4983863BD1602520D80BD1D17AIMCMBX02MITREOR_-- From amontville@tripwire.com Wed Sep 12 15:32:58 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3AC21F85AD for ; Wed, 12 Sep 2012 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, RCVD_IN_DNSWL_LOW=-1] 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 oVl23An0iEn7 for ; Wed, 12 Sep 2012 15:32:57 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0F21F8554 for ; Wed, 12 Sep 2012 15:32:56 -0700 (PDT) Received: from mail93-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Sep 2012 22:32:55 +0000 Received: from mail93-am1 (localhost [127.0.0.1]) by mail93-am1-R.bigfish.com (Postfix) with ESMTP id 0E0D526011A for ; Wed, 12 Sep 2012 22:32:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I1469Kc85ehc25dLd6eahzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdhbe3k1155h) Received: from mail93-am1 (localhost.localdomain [127.0.0.1]) by mail93-am1 (MessageSwitch) id 1347489172359258_2142; Wed, 12 Sep 2012 22:32:52 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.246]) by mail93-am1.bigfish.com (Postfix) with ESMTP id 55AFF46004A for ; Wed, 12 Sep 2012 22:32:52 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Sep 2012 22:32:47 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id C3721232122F for ; Wed, 12 Sep 2012 15:28:50 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id F331023211EA; Wed, 12 Sep 2012 15:28:49 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Sep 2012 15:35:58 -0700 Received: from PDXMB03.tripwire.com ([fe80::284f:fde0:d82f:4223]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 12 Sep 2012 15:32:44 -0700 From: Adam Montville To: "Davidson II, Mark S" , "david.oliva@verizon.net" , "david.waltermire@nist.gov" , "sacm@ietf.org" Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrAgAAta4A= Date: Wed, 12 Sep 2012 22:32:42 +0000 Message-ID: In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC765A7B4839amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 1cdaad0f-a21c-45cb-b5ca-9727895c2a07 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 22:32:58 -0000 --_000_CC765A7B4839amontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, We can have multiple authors on a single document. That said, if there's s= omething else David would be interested in bringing in (there's more than j= ust ASR to work on), then I would recommend that you bring in ASR and that = David work on a different document, such as ARF. I am, of course, assuming= that we all have limited time. It would be entirely acceptable for you an= d David to work on ASR and for either or both of you to work on others in a= ddition. Regards, Adam From: "", Mark S > Date: Wednesday, September 12, 2012 12:57 PM To: "david.oliva@verizon.net" >, "david.waltermire@nist.gov" >, "sacm@ietf.org" > Subject: Re: [sacm] FW: SACM BoF Request My apologies for the late response, I didn=92t get to this email until just= now. As an original author for the ASR spec, I=92d like to participate in bringi= ng ASR to the IETF. Is that a possibility? Thank you. -Mark Davidson From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of david.oliva@verizon.net Sent: Wednesday, September 12, 2012 12:17 PM To: david.waltermire@nist.gov; sacm@ietf.= org Subject: Re: [sacm] FW: SACM BoF Request David: I would like to take on ASR (I pressume you are talking about IR 7848 for f= uture SCAP/SACM versions). Which in fact, brings up a question. In terms of maturity, how do you know which Interagency Reports will be par= t of future SACM/SCAP versions? David Oliva On 09/12/12, Waltermire, David A.> wrote: I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, G= A. The details are below for anyone interested. At this point we need to = complete preparations for the BoF. To be successful, we will need your par= ticipation in the BoF and your help getting ready. Here are meeting details if you are interested in making travel arrangement= s: http://www.ietf.org/meeting/85/index.html At this point we need additional drafts to be submitted to augment the agen= da and support the BoF. I=92d be happy to work with anyone interested in p= reparing drafts for any of the existing specifications in this area (e.g. C= PE, Asset Identification, ARF, ASR, etc.) We should probably do a direct c= onversion of existing specifications for -00 versions before making any cha= nges. The -00 deadline for the IETF 85 meeting is 10/15 with any updated d= rafts due a week later on 10/22. Any volunteers? We will also need speakers to present drafts. Please let me or Kathleen kn= ow if you are interested in making a short presentation. We also need to continue to refine the charter (included below) and use cas= e documents. Any additional comments/changes would be appreciated. Sincerely, Dave From: Waltermire, David A. Sent: Monday, September 10, 2012 6:45 PM To: 'stephen.farrell@cs.tcd.ie'; 'turners= @ieca.com'; 'Moriarty, Kathleen' Subject: SACM BoF Request Please find the our request for a WG formation BoF below. I have also incl= uded a draft charter that we have been developing with feedback from the SA= CM list. Please let me know if you have any questions or if you would like= any additional details. Sincerely, Dave Waltermire -- BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from= the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation to verify= system configurations with the ability to prioritize risk based on increas= ed situational awareness from shared intelligence is the key to escaping th= is rut. This working group will develop security automation standards in su= pport of information security processes and practices where practical. Thes= e standards will help security practitioners to be better utilized within t= heir organizations by automating routine tasks related to endpoint and serv= er security so that practitioners can focus on more advanced tasks. The ini= tial focus of this work is to address enterprise use cases. The working group will achieve this by consuming shared intelligence and co= ntinuing (with cooperation) the security automation work already performed = by various organizations around the world. The initial work has been fruit= ful, and the data formats previously published are ready for expansion on t= he international stage. Of particular interest to this working group are th= e security automation specifications supporting asset, change, configuratio= n, and vulnerability management. Of additional interest to this working gro= up are the emerging security automation interfaces and data formats relatin= g to event management and continuous assessment. The continuous assessment= capabilities enable organizational situational awareness through frequent = snapshots of the operating state of their environment, with risk prioritize= d based on consumed information provided by shared intelligence (vulnerabil= ities, threats, etc.). By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories, and enabling interoperability thro= ugh the development and use of standard interfaces and communications proto= cols. Content based on rich data standards and protocols will provide the a= uthoritative instructions needed by data-driven tools to enable the automat= ed collection and exchange of configuration and vulnerability data pertaini= ng to enterprise assets. Information produced by these tools will provide a= ccurate and timely situational awareness in support of organizational decis= ion making. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing and aggregating devi= ce states and comparing these device states against expected values, and re= porting on those results in a predefined or ad hoc manner. This area of fo= cus provides for necessary language and data format specifications. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of= systems, composed of many different types of devices and networks, operate= d by varying personnel, to ensure security process effectiveness in a pre-d= efined or ad-hoc manner. This area of focus provides for integration proto= cols supporting plug and play continuous assessment and security automation= networking. This working group will achieve the following milestones in two phases: Phase One - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability - A Standards Track document specifying a control framework representation = format. - A Standards Track document specifying benchmark configuration representat= ion - An Informational document stating guidelines / requirements for specifyin= g checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other co= ntent defined in this group with the NEA protocols Phase Two - Standards Track document specifying security automation/continuous assess= ment interfaces - A Standards Track document specifying communication protocols used for se= curity automation and continuous assessment - A Standards Track document describing the messages and network protocols = for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems ________________________________ _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC765A7B4839amontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <514CE027AF38914885F07CAFF0E57DDE@tripwire.com> Content-Transfer-Encoding: quoted-printable
Mark,

We can have multiple authors on a single document.  That said, if= there's something else David would be interested in bringing in (there's m= ore than just ASR to work on), then I would recommend that you bring in ASR= and that David work on a different document, such as ARF.  I am, of course, assuming that we all have limited time= .  It would be entirely acceptable for you and David to work on ASR an= d for either or both of you to work on others in addition.

Regards,

Adam


My apologies for the late response= , I didn=92t get to this email until just now.

 

As an original author for the ASR = spec, I=92d like to participate in bringing ASR to the IETF. Is that a poss= ibility?

 

Thank you.

-Mark Davidson

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of david.oliva@= verizon.net
Sent: Wednesday, September 12, 2012 12:17 PM
To: david.waltermire@ni= st.gov; sacm@ietf.org
Subject: Re: [sacm] FW: SACM BoF Request

 

 David:

 

I would like to take = on ASR (I pressume you are talking about IR 7848 for future SCAP/SACM versi= ons).

 

Which in fact, brings= up a question.

 

In terms of maturity,= how do you know which Interagency Reports will be part of future SACM/SCAP= versions?

 

David Oliva

 

 

On 09/12/12, Waltermi= re, David A.<david.waltermi= re@nist.gov> wrote:

 

I sent in a request to hold a SACM BoF at the= IETF 85 meeting in Atlanta, GA.  The details are below for anyone int= erested.  At this point we need to complete preparations for the BoF.&= nbsp; To be successful, we will need your participation in the BoF and your help getting ready.=

 

Here are meeting details if you are intereste= d in making travel arrangements:

 

http://www.ietf.org/meeting/85/index.html

 

At this point we need additional drafts to be= submitted to augment the agenda and support the BoF.  I=92d be happy = to work with anyone interested in preparing drafts for any of the existing = specifications in this area (e.g. CPE, Asset Identification, ARF, ASR, etc.)  We should probably do a direct conve= rsion of existing specifications for -00 versions before making any changes= .  The -00 deadline for the IETF 85 meeting is 10/15 with any updated = drafts due a week later on 10/22.  Any volunteers?

 

We will also need speakers to present drafts.=   Please let me or Kathleen know if you are interested in making a sho= rt presentation.

 

We also need to continue to refine the charte= r (included below) and use case documents. Any additional comments/changes = would be appreciated.

 

Sincerely,=

Dave<= /o:p>

 

From: Waltermire, David A.
Sent: Monday, September 10, 2012 6:45 PM
To: '= stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moriarty, Kathleen'
Subject: SACM BoF Request

 

Please find the our request for a WG formation = BoF below.  I have also included a draft charter that we have been dev= eloping with feedback from the SACM list.  Please let me know if you h= ave any questions or if you would like any additional details.

 

Sincerely,

Dave Waltermire

 

--

 

BOF full name: Security Automation and Continuo= us Monitoring [SACM]

AREA: Security

BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com)

        = ;    David Waltermire (david.waltermire@nist.gov)<= /p>

Agenda:

 

* Review the draft charter

* Review draft-waltermire-sacm-use-cases-02

* Review drafts submitted in support of the cha= rter

  - draft-waltermire-content-repository-00=

  - More expected before -00 deadline=

 

Full Description of BOF: The SACM BoF is intend= ed to progress the work from the SACM mailing list to solidify discussions = on a proposed charter, use cases and milestones in support of moving to an = IETF working group.

 

CONFLICTS to avoid: SAAG, MILE

Expected Attendance: 40, not sure what the prev= ious attendance was?

Special Requests: Meetecho support

Number of sessions: 1

Length of session: 2 hours

 

Draft Charter:

 

Proposed Working Group Charter

 

Chairs:

TBD

TBD

 

Security Area Directors:

     Stephen Farrell <stephen.farrel= l@cs.tcd.ie>

     Sean Turner <turners@ieca.com>

 

Security Area Advisor:

     Sean Turner <turners@ieca.com>

 

Mailing Lists:

     General Discussion: sacm@ietf.org

     To Subscribe: &nb= sp;     http://www.ietf.org/mailman/listinfo/sacm

     Archive:  &n= bsp;         http://www.ietf.org/mail-archive/web/sacm

 

Description of Working Group<= /p>

 

Securing information and the systems that store= , process, and transmit that information has become a challenging task for = organizations of all sizes, and we find that security practitioners spend m= ost of their time on manual processes relegating them to ineffectiveness. Security automation to verify system c= onfigurations with the ability to prioritize risk based on increased situat= ional awareness from shared intelligence is the key to escaping this rut. T= his working group will develop security automation standards in support of information security processes and prac= tices where practical. These standards will help security practitioners to = be better utilized within their organizations by automating routine tasks r= elated to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus = of this work is to address enterprise use cases.

 

The working group will achieve this by consumin= g shared intelligence and continuing (with cooperation) the security automa= tion work already performed by various organizations around the world. = ; The initial work has been fruitful, and the data formats previously published are ready for expansion on the inter= national stage. Of particular interest to this working group are the securi= ty automation specifications supporting asset, change, configuration, and v= ulnerability management. Of additional interest to this working group are the emerging security automation interf= aces and data formats relating to event management and continuous assessmen= t.  The continuous assessment capabilities enable organizational situa= tional awareness through frequent snapshots of the operating state of their environment, with risk prioritized based o= n consumed information provided by shared intelligence (vulnerabilities, th= reats, etc.).

 

By undertaking this work, we recognize that the= re are multiple categories of problems in the security automation domain: d= efining expressions for particular domain concepts (i.e. data formats), est= ablishing a standards-based foundation supporting the curation and exchange of security automation content collec= tions in content repositories, and enabling interoperability through the de= velopment and use of standard interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritative instructions needed by data-d= riven tools to enable the automated collection and exchange of configuratio= n and vulnerability data pertaining to enterprise assets. Information produ= ced by these tools will provide accurate and timely situational awareness in support of organizational dec= ision making.

 

This working group will provide solutions to th= ese categories of problems and the main areas of focus for this working gro= up are described as follows:

 

1. Define, either by normative reference, adopt= ion, or creation, a set of standards that can be used for the purpose of as= sessing and aggregating device states and comparing these device states aga= inst expected values, and reporting on those results in a predefined or ad hoc manner.  This area of focu= s provides for necessary language and data format specifications.

 

2. Define, either by normative reference, adopt= ion, or creation, a set of standards that can be used to continuously asses= s and report on the state of systems, composed of many different types of d= evices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad= -hoc manner.  This area of focus provides for integration protocols su= pporting plug and play continuous assessment and security automation networ= king.

 

This working group will achieve the following m= ilestones in two phases:

 

Phase One

- A Standards Track document specifying asset d= escription format

- A Standards Track document specifying asset i= dentification

- A Standards Track document specifying platfor= m naming

- A Standards Track document specifying platfor= m matching

- A Standards Track document specifying platfor= m applicability

- A Standards Track document specifying a contr= ol framework representation format.

- A Standards Track document specifying benchma= rk configuration representation

- An Informational document stating guidelines = / requirements for specifying checking languages

- Standards Track documents specifying device s= tate checking languages

- A Standards Track document specifying an inte= rrogative checking language

- A Standards Track document specifying asset r= eporting information

- Standards Track document describing how to us= e the languages and other content defined in this group with the NEA protoc= ols

 

Phase Two

- Standards Track document specifying security = automation/continuous assessment interfaces

- A Standards Track document specifying communi= cation protocols used for security automation and continuous assessment

- A Standards Track document describing the mes= sages and network protocols for distributing security automation content&nb= sp; (content repository)

- A Standards Track document describing protoco= ls and data formats for securely sharing dynamic network state information = among security systems

 

 


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


--_000_CC765A7B4839amontvilletripwirecom_-- From david.waltermire@nist.gov Thu Sep 13 04:52:54 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0800D21F850D for ; Thu, 13 Sep 2012 04:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.804 X-Spam-Level: X-Spam-Status: No, score=-4.804 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, 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 EXPmxeedlJ0Y for ; Thu, 13 Sep 2012 04:52:52 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EBF1321F8446 for ; Thu, 13 Sep 2012 04:52:51 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 13 Sep 2012 07:52:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 13 Sep 2012 07:51:21 -0400 From: "Waltermire, David A." To: "Davidson II, Mark S" , "david.oliva@verizon.net" , "sacm@ietf.org" Date: Thu, 13 Sep 2012 07:52:48 -0400 Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrAgAAhkLA= Message-ID: References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> 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_D7A0423E5E193F40BE6E94126930C4930BA2733B4AMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 11:52:54 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA2733B4AMBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaywNCg0KVGhhdCB3b3VsZCBiZSBncmVhdCEgIFRoYW5rIHlvdSBmb3Igdm9sdW50ZWVyaW5n Lg0KDQpTaW5jZXJlbHksDQpEYXZlDQoNCkZyb206IERhdmlkc29uIElJLCBNYXJrIFMgW21haWx0 bzptZGF2aWRzb25AbWl0cmUub3JnXQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIw MTIgMzo1OCBQTQ0KVG86IGRhdmlkLm9saXZhQHZlcml6b24ubmV0OyBXYWx0ZXJtaXJlLCBEYXZp ZCBBLjsgc2FjbUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzYWNtXSBGVzogU0FDTSBCb0YgUmVx dWVzdA0KDQpNeSBhcG9sb2dpZXMgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLCBJIGRpZG7igJl0IGdl dCB0byB0aGlzIGVtYWlsIHVudGlsIGp1c3Qgbm93Lg0KDQpBcyBhbiBvcmlnaW5hbCBhdXRob3Ig Zm9yIHRoZSBBU1Igc3BlYywgSeKAmWQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiBicmluZ2luZyBB U1IgdG8gdGhlIElFVEYuIElzIHRoYXQgYSBwb3NzaWJpbGl0eT8NCg0KVGhhbmsgeW91Lg0KLU1h cmsgRGF2aWRzb24NCg0KRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWNtLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8bWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0 Pg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMTI6MTcgUE0NClRvOiBkYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pjsg c2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2FjbV0g Rlc6IFNBQ00gQm9GIFJlcXVlc3QNCg0KIERhdmlkOg0KDQpJIHdvdWxkIGxpa2UgdG8gdGFrZSBv biBBU1IgKEkgcHJlc3N1bWUgeW91IGFyZSB0YWxraW5nIGFib3V0IElSIDc4NDggZm9yIGZ1dHVy ZSBTQ0FQL1NBQ00gdmVyc2lvbnMpLg0KDQpXaGljaCBpbiBmYWN0LCBicmluZ3MgdXAgYSBxdWVz dGlvbi4NCg0KSW4gdGVybXMgb2YgbWF0dXJpdHksIGhvdyBkbyB5b3Uga25vdyB3aGljaCBJbnRl cmFnZW5jeSBSZXBvcnRzIHdpbGwgYmUgcGFydCBvZiBmdXR1cmUgU0FDTS9TQ0FQIHZlcnNpb25z Pw0KDQpEYXZpZCBPbGl2YQ0KDQoNCk9uIDA5LzEyLzEyLCBXYWx0ZXJtaXJlLCBEYXZpZCBBLjxk YXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292 Pj4gd3JvdGU6DQoNCkkgc2VudCBpbiBhIHJlcXVlc3QgdG8gaG9sZCBhIFNBQ00gQm9GIGF0IHRo ZSBJRVRGIDg1IG1lZXRpbmcgaW4gQXRsYW50YSwgR0EuICBUaGUgZGV0YWlscyBhcmUgYmVsb3cg Zm9yIGFueW9uZSBpbnRlcmVzdGVkLiAgQXQgdGhpcyBwb2ludCB3ZSBuZWVkIHRvIGNvbXBsZXRl IHByZXBhcmF0aW9ucyBmb3IgdGhlIEJvRi4gIFRvIGJlIHN1Y2Nlc3NmdWwsIHdlIHdpbGwgbmVl ZCB5b3VyIHBhcnRpY2lwYXRpb24gaW4gdGhlIEJvRiBhbmQgeW91ciBoZWxwIGdldHRpbmcgcmVh ZHkuDQoNCkhlcmUgYXJlIG1lZXRpbmcgZGV0YWlscyBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4g bWFraW5nIHRyYXZlbCBhcnJhbmdlbWVudHM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGlu Zy84NS9pbmRleC5odG1sDQoNCkF0IHRoaXMgcG9pbnQgd2UgbmVlZCBhZGRpdGlvbmFsIGRyYWZ0 cyB0byBiZSBzdWJtaXR0ZWQgdG8gYXVnbWVudCB0aGUgYWdlbmRhIGFuZCBzdXBwb3J0IHRoZSBC b0YuICBJ4oCZZCBiZSBoYXBweSB0byB3b3JrIHdpdGggYW55b25lIGludGVyZXN0ZWQgaW4gcHJl cGFyaW5nIGRyYWZ0cyBmb3IgYW55IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyBpbiB0 aGlzIGFyZWEgKGUuZy4gQ1BFLCBBc3NldCBJZGVudGlmaWNhdGlvbiwgQVJGLCBBU1IsIGV0Yy4p ICBXZSBzaG91bGQgcHJvYmFibHkgZG8gYSBkaXJlY3QgY29udmVyc2lvbiBvZiBleGlzdGluZyBz cGVjaWZpY2F0aW9ucyBmb3IgLTAwIHZlcnNpb25zIGJlZm9yZSBtYWtpbmcgYW55IGNoYW5nZXMu ICBUaGUgLTAwIGRlYWRsaW5lIGZvciB0aGUgSUVURiA4NSBtZWV0aW5nIGlzIDEwLzE1IHdpdGgg YW55IHVwZGF0ZWQgZHJhZnRzIGR1ZSBhIHdlZWsgbGF0ZXIgb24gMTAvMjIuICBBbnkgdm9sdW50 ZWVycz8NCg0KV2Ugd2lsbCBhbHNvIG5lZWQgc3BlYWtlcnMgdG8gcHJlc2VudCBkcmFmdHMuICBQ bGVhc2UgbGV0IG1lIG9yIEthdGhsZWVuIGtub3cgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIG1h a2luZyBhIHNob3J0IHByZXNlbnRhdGlvbi4NCg0KV2UgYWxzbyBuZWVkIHRvIGNvbnRpbnVlIHRv IHJlZmluZSB0aGUgY2hhcnRlciAoaW5jbHVkZWQgYmVsb3cpIGFuZCB1c2UgY2FzZSBkb2N1bWVu dHMuIEFueSBhZGRpdGlvbmFsIGNvbW1lbnRzL2NoYW5nZXMgd291bGQgYmUgYXBwcmVjaWF0ZWQu DQoNClNpbmNlcmVseSwNCkRhdmUNCg0KRnJvbTogV2FsdGVybWlyZSwgRGF2aWQgQS4NClNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAyMDEyIDY6NDUgUE0NClRvOiAnc3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4nOyAndHVybmVyc0Bp ZWNhLmNvbTxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT4nOyAnTW9yaWFydHksIEthdGhsZWVuJw0K U3ViamVjdDogU0FDTSBCb0YgUmVxdWVzdA0KDQpQbGVhc2UgZmluZCB0aGUgb3VyIHJlcXVlc3Qg Zm9yIGEgV0cgZm9ybWF0aW9uIEJvRiBiZWxvdy4gIEkgaGF2ZSBhbHNvIGluY2x1ZGVkIGEgZHJh ZnQgY2hhcnRlciB0aGF0IHdlIGhhdmUgYmVlbiBkZXZlbG9waW5nIHdpdGggZmVlZGJhY2sgZnJv bSB0aGUgU0FDTSBsaXN0LiAgUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVz dGlvbnMgb3IgaWYgeW91IHdvdWxkIGxpa2UgYW55IGFkZGl0aW9uYWwgZGV0YWlscy4NCg0KU2lu Y2VyZWx5LA0KRGF2ZSBXYWx0ZXJtaXJlDQoNCi0tDQoNCkJPRiBmdWxsIG5hbWU6IFNlY3VyaXR5 IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyBbU0FDTV0NCkFSRUE6IFNlY3Vy aXR5DQpCT0YgQ2hhaXJzOiBLYXRobGVlbiBNb3JpYXJ0eSAoa2F0aGxlZW4ubW9yaWFydHlAZW1j LmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbT4pDQogICAgICAgICAgICBEYXZp ZCBXYWx0ZXJtaXJlIChkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZpZC53YWx0 ZXJtaXJlQG5pc3QuZ292PikNCkFnZW5kYToNCg0KKiBSZXZpZXcgdGhlIGRyYWZ0IGNoYXJ0ZXIN CiogUmV2aWV3IGRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDINCiogUmV2aWV3IGRy YWZ0cyBzdWJtaXR0ZWQgaW4gc3VwcG9ydCBvZiB0aGUgY2hhcnRlcg0KICAtIGRyYWZ0LXdhbHRl cm1pcmUtY29udGVudC1yZXBvc2l0b3J5LTAwDQogIC0gTW9yZSBleHBlY3RlZCBiZWZvcmUgLTAw IGRlYWRsaW5lDQoNCkZ1bGwgRGVzY3JpcHRpb24gb2YgQk9GOiBUaGUgU0FDTSBCb0YgaXMgaW50 ZW5kZWQgdG8gcHJvZ3Jlc3MgdGhlIHdvcmsgZnJvbSB0aGUgU0FDTSBtYWlsaW5nIGxpc3QgdG8g c29saWRpZnkgZGlzY3Vzc2lvbnMgb24gYSBwcm9wb3NlZCBjaGFydGVyLCB1c2UgY2FzZXMgYW5k IG1pbGVzdG9uZXMgaW4gc3VwcG9ydCBvZiBtb3ZpbmcgdG8gYW4gSUVURiB3b3JraW5nIGdyb3Vw Lg0KDQpDT05GTElDVFMgdG8gYXZvaWQ6IFNBQUcsIE1JTEUNCkV4cGVjdGVkIEF0dGVuZGFuY2U6 IDQwLCBub3Qgc3VyZSB3aGF0IHRoZSBwcmV2aW91cyBhdHRlbmRhbmNlIHdhcz8NClNwZWNpYWwg UmVxdWVzdHM6IE1lZXRlY2hvIHN1cHBvcnQNCk51bWJlciBvZiBzZXNzaW9uczogMQ0KTGVuZ3Ro IG9mIHNlc3Npb246IDIgaG91cnMNCg0KRHJhZnQgQ2hhcnRlcjoNCg0KUHJvcG9zZWQgV29ya2lu ZyBHcm91cCBDaGFydGVyDQoNCkNoYWlyczoNClRCRA0KVEJEDQoNClNlY3VyaXR5IEFyZWEgRGly ZWN0b3JzOg0KICAgICBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8 bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+Pg0KICAgICBTZWFuIFR1cm5lciA8dHVy bmVyc0BpZWNhLmNvbTxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT4+DQoNClNlY3VyaXR5IEFyZWEg QWR2aXNvcjoNCiAgICAgU2VhbiBUdXJuZXIgPHR1cm5lcnNAaWVjYS5jb208bWFpbHRvOnR1cm5l cnNAaWVjYS5jb20+Pg0KDQpNYWlsaW5nIExpc3RzOg0KICAgICBHZW5lcmFsIERpc2N1c3Npb246 IHNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQogICAgIFRvIFN1YnNjcmliZTog ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCiAgICAgQXJj aGl2ZTogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2Fj bQ0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClNlY3VyaW5nIGluZm9ybWF0aW9u IGFuZCB0aGUgc3lzdGVtcyB0aGF0IHN0b3JlLCBwcm9jZXNzLCBhbmQgdHJhbnNtaXQgdGhhdCBp bmZvcm1hdGlvbiBoYXMgYmVjb21lIGEgY2hhbGxlbmdpbmcgdGFzayBmb3Igb3JnYW5pemF0aW9u cyBvZiBhbGwgc2l6ZXMsIGFuZCB3ZSBmaW5kIHRoYXQgc2VjdXJpdHkgcHJhY3RpdGlvbmVycyBz cGVuZCBtb3N0IG9mIHRoZWlyIHRpbWUgb24gbWFudWFsIHByb2Nlc3NlcyByZWxlZ2F0aW5nIHRo ZW0gdG8gaW5lZmZlY3RpdmVuZXNzLiBTZWN1cml0eSBhdXRvbWF0aW9uIHRvIHZlcmlmeSBzeXN0 ZW0gY29uZmlndXJhdGlvbnMgd2l0aCB0aGUgYWJpbGl0eSB0byBwcmlvcml0aXplIHJpc2sgYmFz ZWQgb24gaW5jcmVhc2VkIHNpdHVhdGlvbmFsIGF3YXJlbmVzcyBmcm9tIHNoYXJlZCBpbnRlbGxp Z2VuY2UgaXMgdGhlIGtleSB0byBlc2NhcGluZyB0aGlzIHJ1dC4gVGhpcyB3b3JraW5nIGdyb3Vw IHdpbGwgZGV2ZWxvcCBzZWN1cml0eSBhdXRvbWF0aW9uIHN0YW5kYXJkcyBpbiBzdXBwb3J0IG9m IGluZm9ybWF0aW9uIHNlY3VyaXR5IHByb2Nlc3NlcyBhbmQgcHJhY3RpY2VzIHdoZXJlIHByYWN0 aWNhbC4gVGhlc2Ugc3RhbmRhcmRzIHdpbGwgaGVscCBzZWN1cml0eSBwcmFjdGl0aW9uZXJzIHRv IGJlIGJldHRlciB1dGlsaXplZCB3aXRoaW4gdGhlaXIgb3JnYW5pemF0aW9ucyBieSBhdXRvbWF0 aW5nIHJvdXRpbmUgdGFza3MgcmVsYXRlZCB0byBlbmRwb2ludCBhbmQgc2VydmVyIHNlY3VyaXR5 IHNvIHRoYXQgcHJhY3RpdGlvbmVycyBjYW4gZm9jdXMgb24gbW9yZSBhZHZhbmNlZCB0YXNrcy4g VGhlIGluaXRpYWwgZm9jdXMgb2YgdGhpcyB3b3JrIGlzIHRvIGFkZHJlc3MgZW50ZXJwcmlzZSB1 c2UgY2FzZXMuDQoNClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGlzIGJ5IGNvbnN1 bWluZyBzaGFyZWQgaW50ZWxsaWdlbmNlIGFuZCBjb250aW51aW5nICh3aXRoIGNvb3BlcmF0aW9u KSB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiB3b3JrIGFscmVhZHkgcGVyZm9ybWVkIGJ5IHZhcmlv dXMgb3JnYW5pemF0aW9ucyBhcm91bmQgdGhlIHdvcmxkLiAgVGhlIGluaXRpYWwgd29yayBoYXMg YmVlbiBmcnVpdGZ1bCwgYW5kIHRoZSBkYXRhIGZvcm1hdHMgcHJldmlvdXNseSBwdWJsaXNoZWQg YXJlIHJlYWR5IGZvciBleHBhbnNpb24gb24gdGhlIGludGVybmF0aW9uYWwgc3RhZ2UuIE9mIHBh cnRpY3VsYXIgaW50ZXJlc3QgdG8gdGhpcyB3b3JraW5nIGdyb3VwIGFyZSB0aGUgc2VjdXJpdHkg YXV0b21hdGlvbiBzcGVjaWZpY2F0aW9ucyBzdXBwb3J0aW5nIGFzc2V0LCBjaGFuZ2UsIGNvbmZp Z3VyYXRpb24sIGFuZCB2dWxuZXJhYmlsaXR5IG1hbmFnZW1lbnQuIE9mIGFkZGl0aW9uYWwgaW50 ZXJlc3QgdG8gdGhpcyB3b3JraW5nIGdyb3VwIGFyZSB0aGUgZW1lcmdpbmcgc2VjdXJpdHkgYXV0 b21hdGlvbiBpbnRlcmZhY2VzIGFuZCBkYXRhIGZvcm1hdHMgcmVsYXRpbmcgdG8gZXZlbnQgbWFu YWdlbWVudCBhbmQgY29udGludW91cyBhc3Nlc3NtZW50LiAgVGhlIGNvbnRpbnVvdXMgYXNzZXNz bWVudCBjYXBhYmlsaXRpZXMgZW5hYmxlIG9yZ2FuaXphdGlvbmFsIHNpdHVhdGlvbmFsIGF3YXJl bmVzcyB0aHJvdWdoIGZyZXF1ZW50IHNuYXBzaG90cyBvZiB0aGUgb3BlcmF0aW5nIHN0YXRlIG9m IHRoZWlyIGVudmlyb25tZW50LCB3aXRoIHJpc2sgcHJpb3JpdGl6ZWQgYmFzZWQgb24gY29uc3Vt ZWQgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgc2hhcmVkIGludGVsbGlnZW5jZSAodnVsbmVyYWJp bGl0aWVzLCB0aHJlYXRzLCBldGMuKS4NCg0KQnkgdW5kZXJ0YWtpbmcgdGhpcyB3b3JrLCB3ZSBy ZWNvZ25pemUgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgY2F0ZWdvcmllcyBvZiBwcm9ibGVtcyBp biB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBkb21haW46IGRlZmluaW5nIGV4cHJlc3Npb25zIGZv ciBwYXJ0aWN1bGFyIGRvbWFpbiBjb25jZXB0cyAoaS5lLiBkYXRhIGZvcm1hdHMpLCBlc3RhYmxp c2hpbmcgYSBzdGFuZGFyZHMtYmFzZWQgZm91bmRhdGlvbiBzdXBwb3J0aW5nIHRoZSBjdXJhdGlv biBhbmQgZXhjaGFuZ2Ugb2Ygc2VjdXJpdHkgYXV0b21hdGlvbiBjb250ZW50IGNvbGxlY3Rpb25z IGluIGNvbnRlbnQgcmVwb3NpdG9yaWVzLCBhbmQgZW5hYmxpbmcgaW50ZXJvcGVyYWJpbGl0eSB0 aHJvdWdoIHRoZSBkZXZlbG9wbWVudCBhbmQgdXNlIG9mIHN0YW5kYXJkIGludGVyZmFjZXMgYW5k IGNvbW11bmljYXRpb25zIHByb3RvY29scy4gQ29udGVudCBiYXNlZCBvbiByaWNoIGRhdGEgc3Rh bmRhcmRzIGFuZCBwcm90b2NvbHMgd2lsbCBwcm92aWRlIHRoZSBhdXRob3JpdGF0aXZlIGluc3Ry dWN0aW9ucyBuZWVkZWQgYnkgZGF0YS1kcml2ZW4gdG9vbHMgdG8gZW5hYmxlIHRoZSBhdXRvbWF0 ZWQgY29sbGVjdGlvbiBhbmQgZXhjaGFuZ2Ugb2YgY29uZmlndXJhdGlvbiBhbmQgdnVsbmVyYWJp bGl0eSBkYXRhIHBlcnRhaW5pbmcgdG8gZW50ZXJwcmlzZSBhc3NldHMuIEluZm9ybWF0aW9uIHBy b2R1Y2VkIGJ5IHRoZXNlIHRvb2xzIHdpbGwgcHJvdmlkZSBhY2N1cmF0ZSBhbmQgdGltZWx5IHNp dHVhdGlvbmFsIGF3YXJlbmVzcyBpbiBzdXBwb3J0IG9mIG9yZ2FuaXphdGlvbmFsIGRlY2lzaW9u IG1ha2luZy4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgcHJvdmlkZSBzb2x1dGlvbnMgdG8g dGhlc2UgY2F0ZWdvcmllcyBvZiBwcm9ibGVtcyBhbmQgdGhlIG1haW4gYXJlYXMgb2YgZm9jdXMg Zm9yIHRoaXMgd29ya2luZyBncm91cCBhcmUgZGVzY3JpYmVkIGFzIGZvbGxvd3M6DQoNCjEuIERl ZmluZSwgZWl0aGVyIGJ5IG5vcm1hdGl2ZSByZWZlcmVuY2UsIGFkb3B0aW9uLCBvciBjcmVhdGlv biwgYSBzZXQgb2Ygc3RhbmRhcmRzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHRoZSBwdXJwb3NlIG9m IGFzc2Vzc2luZyBhbmQgYWdncmVnYXRpbmcgZGV2aWNlIHN0YXRlcyBhbmQgY29tcGFyaW5nIHRo ZXNlIGRldmljZSBzdGF0ZXMgYWdhaW5zdCBleHBlY3RlZCB2YWx1ZXMsIGFuZCByZXBvcnRpbmcg b24gdGhvc2UgcmVzdWx0cyBpbiBhIHByZWRlZmluZWQgb3IgYWQgaG9jIG1hbm5lci4gIFRoaXMg YXJlYSBvZiBmb2N1cyBwcm92aWRlcyBmb3IgbmVjZXNzYXJ5IGxhbmd1YWdlIGFuZCBkYXRhIGZv cm1hdCBzcGVjaWZpY2F0aW9ucy4NCg0KMi4gRGVmaW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJl ZmVyZW5jZSwgYWRvcHRpb24sIG9yIGNyZWF0aW9uLCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBj YW4gYmUgdXNlZCB0byBjb250aW51b3VzbHkgYXNzZXNzIGFuZCByZXBvcnQgb24gdGhlIHN0YXRl IG9mIHN5c3RlbXMsIGNvbXBvc2VkIG9mIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMg YW5kIG5ldHdvcmtzLCBvcGVyYXRlZCBieSB2YXJ5aW5nIHBlcnNvbm5lbCwgdG8gZW5zdXJlIHNl Y3VyaXR5IHByb2Nlc3MgZWZmZWN0aXZlbmVzcyBpbiBhIHByZS1kZWZpbmVkIG9yIGFkLWhvYyBt YW5uZXIuICBUaGlzIGFyZWEgb2YgZm9jdXMgcHJvdmlkZXMgZm9yIGludGVncmF0aW9uIHByb3Rv Y29scyBzdXBwb3J0aW5nIHBsdWcgYW5kIHBsYXkgY29udGludW91cyBhc3Nlc3NtZW50IGFuZCBz ZWN1cml0eSBhdXRvbWF0aW9uIG5ldHdvcmtpbmcuDQoNClRoaXMgd29ya2luZyBncm91cCB3aWxs IGFjaGlldmUgdGhlIGZvbGxvd2luZyBtaWxlc3RvbmVzIGluIHR3byBwaGFzZXM6DQoNClBoYXNl IE9uZQ0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IGRlc2Ny aXB0aW9uIGZvcm1hdA0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFz c2V0IGlkZW50aWZpY2F0aW9uDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlp bmcgcGxhdGZvcm0gbmFtaW5nDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlp bmcgcGxhdGZvcm0gbWF0Y2hpbmcNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lm eWluZyBwbGF0Zm9ybSBhcHBsaWNhYmlsaXR5DQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50 IHNwZWNpZnlpbmcgYSBjb250cm9sIGZyYW1ld29yayByZXByZXNlbnRhdGlvbiBmb3JtYXQuDQot IEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYmVuY2htYXJrIGNvbmZpZ3Vy YXRpb24gcmVwcmVzZW50YXRpb24NCi0gQW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCBzdGF0aW5n IGd1aWRlbGluZXMgLyByZXF1aXJlbWVudHMgZm9yIHNwZWNpZnlpbmcgY2hlY2tpbmcgbGFuZ3Vh Z2VzDQotIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudHMgc3BlY2lmeWluZyBkZXZpY2Ugc3RhdGUg Y2hlY2tpbmcgbGFuZ3VhZ2VzDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlp bmcgYW4gaW50ZXJyb2dhdGl2ZSBjaGVja2luZyBsYW5ndWFnZQ0KLSBBIFN0YW5kYXJkcyBUcmFj ayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IHJlcG9ydGluZyBpbmZvcm1hdGlvbg0KLSBTdGFu ZGFyZHMgVHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyBob3cgdG8gdXNlIHRoZSBsYW5ndWFnZXMg YW5kIG90aGVyIGNvbnRlbnQgZGVmaW5lZCBpbiB0aGlzIGdyb3VwIHdpdGggdGhlIE5FQSBwcm90 b2NvbHMNCg0KUGhhc2UgVHdvDQotIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5n IHNlY3VyaXR5IGF1dG9tYXRpb24vY29udGludW91cyBhc3Nlc3NtZW50IGludGVyZmFjZXMNCi0g QSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBjb21tdW5pY2F0aW9uIHByb3Rv Y29scyB1c2VkIGZvciBzZWN1cml0eSBhdXRvbWF0aW9uIGFuZCBjb250aW51b3VzIGFzc2Vzc21l bnQNCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgbWVzc2FnZXMg YW5kIG5ldHdvcmsgcHJvdG9jb2xzIGZvciBkaXN0cmlidXRpbmcgc2VjdXJpdHkgYXV0b21hdGlv biBjb250ZW50ICAoY29udGVudCByZXBvc2l0b3J5KQ0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1 bWVudCBkZXNjcmliaW5nIHByb3RvY29scyBhbmQgZGF0YSBmb3JtYXRzIGZvciBzZWN1cmVseSBz aGFyaW5nIGR5bmFtaWMgbmV0d29yayBzdGF0ZSBpbmZvcm1hdGlvbiBhbW9uZyBzZWN1cml0eSBz eXN0ZW1zDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFpbGluZyBsaXN0 DQpzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zYWNtDQo= --_000_D7A0423E5E193F40BE6E94126930C4930BA2733B4AMBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+TWFyayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYXQgd291bGQgYmUg Z3JlYXQhwqAgVGhhbmsgeW91IGZvciB2b2x1bnRlZXJpbmcuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlNpbmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGF2ZTwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gRGF2aWRzb24gSUksIE1hcmsgUyBbbWFpbHRvOm1kYXZpZHNvbkBtaXRyZS5vcmddIDxi cj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMzo1OCBQTTxicj48 Yj5Ubzo8L2I+IGRhdmlkLm9saXZhQHZlcml6b24ubmV0OyBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsg c2FjbUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtzYWNtXSBGVzogU0FDTSBCb0Yg UmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+TXkgYXBvbG9naWVzIGZvciB0aGUgbGF0ZSByZXNwb25zZSwgSSBkaWRu4oCZdCBn ZXQgdG8gdGhpcyBlbWFpbCB1bnRpbCBqdXN0IG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFzIGFu IG9yaWdpbmFsIGF1dGhvciBmb3IgdGhlIEFTUiBzcGVjLCBJ4oCZZCBsaWtlIHRvIHBhcnRpY2lw YXRlIGluIGJyaW5naW5nIEFTUiB0byB0aGUgSUVURi4gSXMgdGhhdCBhIHBvc3NpYmlsaXR5Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tTWFyayBEYXZpZHNvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVm PSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86ZGF2 aWQub2xpdmFAdmVyaXpvbi5uZXQiPmRhdmlkLm9saXZhQHZlcml6b24ubmV0PC9hPjxicj48Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMTI6MTcgUE08YnI+PGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiI+ZGF2aWQud2Fs dGVybWlyZUBuaXN0LmdvdjwvYT47IDxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNt QGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBGVzogU0FDTSBCb0Yg UmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNw O0RhdmlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5JIHdvdWxkIGxpa2UgdG8gdGFrZSBvbiBB U1IgKEkgcHJlc3N1bWUgeW91IGFyZSB0YWxraW5nIGFib3V0IElSIDc4NDggZm9yIGZ1dHVyZSBT Q0FQL1NBQ00gdmVyc2lvbnMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5XaGljaCBpbiBmYWN0 LCBicmluZ3MgdXAgYSBxdWVzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SW4gdGVybXMg b2YgbWF0dXJpdHksIGhvdyBkbyB5b3Uga25vdyB3aGljaCBJbnRlcmFnZW5jeSBSZXBvcnRzIHdp bGwgYmUgcGFydCBvZiBmdXR1cmUgU0FDTS9TQ0FQIHZlcnNpb25zPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrJz5EYXZpZCBPbGl2YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5PbiAwOS8xMi8xMiwgV2FsdGVybWlyZSwgRGF2aWQg QS4mbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiPmRhdmlkLndh bHRlcm1pcmVAbmlzdC5nb3Y8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+SSBzZW50IGluIGEgcmVxdWVzdCB0byBob2xkIGEgU0FDTSBCb0YgYXQgdGhlIElFVEYgODUg bWVldGluZyBpbiBBdGxhbnRhLCBHQS4mbmJzcDsgVGhlIGRldGFpbHMgYXJlIGJlbG93IGZvciBh bnlvbmUgaW50ZXJlc3RlZC4mbmJzcDsgQXQgdGhpcyBwb2ludCB3ZSBuZWVkIHRvIGNvbXBsZXRl IHByZXBhcmF0aW9ucyBmb3IgdGhlIEJvRi4mbmJzcDsgVG8gYmUgc3VjY2Vzc2Z1bCwgd2Ugd2ls bCBuZWVkIHlvdXIgcGFydGljaXBhdGlvbiBpbiB0aGUgQm9GIGFuZCB5b3VyIGhlbHAgZ2V0dGlu ZyByZWFkeS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhlcmUgYXJlIG1lZXRpbmcgZGV0YWlscyBpZiB5 b3UgYXJlIGludGVyZXN0ZWQgaW4gbWFraW5nIHRyYXZlbCBhcnJhbmdlbWVudHM6PC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODUvaW5kZXgu aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NS9pbmRl eC5odG1sPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QXQgdGhpcyBwb2ludCB3ZSBuZWVkIGFkZGl0 aW9uYWwgZHJhZnRzIHRvIGJlIHN1Ym1pdHRlZCB0byBhdWdtZW50IHRoZSBhZ2VuZGEgYW5kIHN1 cHBvcnQgdGhlIEJvRi4mbmJzcDsgSeKAmWQgYmUgaGFwcHkgdG8gd29yayB3aXRoIGFueW9uZSBp bnRlcmVzdGVkIGluIHByZXBhcmluZyBkcmFmdHMgZm9yIGFueSBvZiB0aGUgZXhpc3Rpbmcgc3Bl Y2lmaWNhdGlvbnMgaW4gdGhpcyBhcmVhIChlLmcuIENQRSwgQXNzZXQgSWRlbnRpZmljYXRpb24s IEFSRiwgQVNSLCBldGMuKSZuYnNwOyBXZSBzaG91bGQgcHJvYmFibHkgZG8gYSBkaXJlY3QgY29u dmVyc2lvbiBvZiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyBmb3IgLTAwIHZlcnNpb25zIGJlZm9y ZSBtYWtpbmcgYW55IGNoYW5nZXMuJm5ic3A7IFRoZSAtMDAgZGVhZGxpbmUgZm9yIHRoZSBJRVRG IDg1IG1lZXRpbmcgaXMgMTAvMTUgd2l0aCBhbnkgdXBkYXRlZCBkcmFmdHMgZHVlIGEgd2VlayBs YXRlciBvbiAxMC8yMi4mbmJzcDsgQW55IHZvbHVudGVlcnM/IDwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ V2Ugd2lsbCBhbHNvIG5lZWQgc3BlYWtlcnMgdG8gcHJlc2VudCBkcmFmdHMuJm5ic3A7IFBsZWFz ZSBsZXQgbWUgb3IgS2F0aGxlZW4ga25vdyBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gbWFraW5n IGEgc2hvcnQgcHJlc2VudGF0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgYWxzbyBuZWVkIHRv IGNvbnRpbnVlIHRvIHJlZmluZSB0aGUgY2hhcnRlciAoaW5jbHVkZWQgYmVsb3cpIGFuZCB1c2Ug Y2FzZSBkb2N1bWVudHMuIEFueSBhZGRpdGlvbmFsIGNvbW1lbnRzL2NoYW5nZXMgd291bGQgYmUg YXBwcmVjaWF0ZWQuIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5TaW5jZXJlbHksPC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkRh dmU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gV2FsdGVybWlyZSwgRGF2aWQgQS4gPGJy PjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiA2OjQ1IFBNPGJyPjxiPlRv OjwvYj4gJzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIiB0YXJnZXQ9 Il9ibGFuayI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4nOyAnPGEgaHJlZj0ibWFpbHRv OnR1cm5lcnNAaWVjYS5jb20iIHRhcmdldD0iX2JsYW5rIj50dXJuZXJzQGllY2EuY29tPC9hPic7 ICdNb3JpYXJ0eSwgS2F0aGxlZW4nPGJyPjxiPlN1YmplY3Q6PC9iPiBTQUNNIEJvRiBSZXF1ZXN0 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlBsZWFz ZSBmaW5kIHRoZSBvdXIgcmVxdWVzdCBmb3IgYSBXRyBmb3JtYXRpb24gQm9GIGJlbG93LiZuYnNw OyBJIGhhdmUgYWxzbyBpbmNsdWRlZCBhIGRyYWZ0IGNoYXJ0ZXIgdGhhdCB3ZSBoYXZlIGJlZW4g ZGV2ZWxvcGluZyB3aXRoIGZlZWRiYWNrIGZyb20gdGhlIFNBQ00gbGlzdC4mbmJzcDsgUGxlYXNl IGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgb3IgaWYgeW91IHdvdWxkIGxp a2UgYW55IGFkZGl0aW9uYWwgZGV0YWlscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+RGF2ZSBXYWx0ZXJtaXJlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0tPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkJPRiBmdWxsIG5h bWU6IFNlY3VyaXR5IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyBbU0FDTV08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFSRUE6IFNlY3VyaXR5PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5CT0YgQ2hhaXJzOiBLYXRobGVlbiBNb3JpYXJ0eSAoPGEgaHJlZj0ibWFp bHRvOmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXRobGVlbi5t b3JpYXJ0eUBlbWMuY29tPC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBEYXZpZCBXYWx0ZXJtaXJlICg8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0 LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L2E+KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QWdlbmRhOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qIFJldmlldyB0aGUgZHJhZnQg Y2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KiBSZXZpZXcgZHJhZnQtd2FsdGVy bWlyZS1zYWNtLXVzZS1jYXNlcy0wMiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiogUmV2 aWV3IGRyYWZ0cyBzdWJtaXR0ZWQgaW4gc3VwcG9ydCBvZiB0aGUgY2hhcnRlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7IC0gZHJhZnQtd2FsdGVybWlyZS1jb250ZW50LXJlcG9z aXRvcnktMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyAtIE1vcmUgZXhwZWN0 ZWQgYmVmb3JlIC0wMCBkZWFkbGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5GdWxsIERlc2NyaXB0aW9uIG9mIEJPRjogVGhl IFNBQ00gQm9GIGlzIGludGVuZGVkIHRvIHByb2dyZXNzIHRoZSB3b3JrIGZyb20gdGhlIFNBQ00g bWFpbGluZyBsaXN0IHRvIHNvbGlkaWZ5IGRpc2N1c3Npb25zIG9uIGEgcHJvcG9zZWQgY2hhcnRl ciwgdXNlIGNhc2VzIGFuZCBtaWxlc3RvbmVzIGluIHN1cHBvcnQgb2YgbW92aW5nIHRvIGFuIElF VEYgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Q09ORkxJQ1RTIHRvIGF2b2lkOiBTQUFHLCBNSUxFPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5FeHBlY3RlZCBBdHRlbmRhbmNlOiA0MCwgbm90IHN1 cmUgd2hhdCB0aGUgcHJldmlvdXMgYXR0ZW5kYW5jZSB3YXM/PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5TcGVjaWFsIFJlcXVlc3RzOiBNZWV0ZWNobyBzdXBwb3J0PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5OdW1iZXIgb2Ygc2Vzc2lvbnM6IDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPkxlbmd0aCBvZiBzZXNzaW9uOiAyIGhvdXJzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkRyYWZ0IENoYXJ0ZXI6PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPlByb3Bvc2VkIFdvcmtpbmcgR3JvdXAgQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5DaGFpcnM6PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5UQkQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRCRDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5TZWN1cml0eSBBcmVhIERpcmVjdG9yczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0dXJu ZXJzQGllY2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+dHVybmVyc0BpZWNhLmNvbTwvYT4mZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPlNlY3VyaXR5IEFyZWEgQWR2aXNvcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR1 cm5lcnNAaWVjYS5jb20iIHRhcmdldD0iX2JsYW5rIj50dXJuZXJzQGllY2EuY29tPC9hPiZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+TWFpbGluZyBMaXN0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHZW5lcmFsIERpc2N1c3Npb246IDxhIGhyZWY9Im1haWx0bzpzYWNt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbyBTdWJzY3JpYmU6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJjaGl2ZTombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY20iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2FjbTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGVz Y3JpcHRpb24gb2YgV29ya2luZyBHcm91cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TZWN1cmluZyBpbmZvcm1hdGlvbiBhbmQg dGhlIHN5c3RlbXMgdGhhdCBzdG9yZSwgcHJvY2VzcywgYW5kIHRyYW5zbWl0IHRoYXQgaW5mb3Jt YXRpb24gaGFzIGJlY29tZSBhIGNoYWxsZW5naW5nIHRhc2sgZm9yIG9yZ2FuaXphdGlvbnMgb2Yg YWxsIHNpemVzLCBhbmQgd2UgZmluZCB0aGF0IHNlY3VyaXR5IHByYWN0aXRpb25lcnMgc3BlbmQg bW9zdCBvZiB0aGVpciB0aW1lIG9uIG1hbnVhbCBwcm9jZXNzZXMgcmVsZWdhdGluZyB0aGVtIHRv IGluZWZmZWN0aXZlbmVzcy4gU2VjdXJpdHkgYXV0b21hdGlvbiB0byB2ZXJpZnkgc3lzdGVtIGNv bmZpZ3VyYXRpb25zIHdpdGggdGhlIGFiaWxpdHkgdG8gcHJpb3JpdGl6ZSByaXNrIGJhc2VkIG9u IGluY3JlYXNlZCBzaXR1YXRpb25hbCBhd2FyZW5lc3MgZnJvbSBzaGFyZWQgaW50ZWxsaWdlbmNl IGlzIHRoZSBrZXkgdG8gZXNjYXBpbmcgdGhpcyBydXQuIFRoaXMgd29ya2luZyBncm91cCB3aWxs IGRldmVsb3Agc2VjdXJpdHkgYXV0b21hdGlvbiBzdGFuZGFyZHMgaW4gc3VwcG9ydCBvZiBpbmZv cm1hdGlvbiBzZWN1cml0eSBwcm9jZXNzZXMgYW5kIHByYWN0aWNlcyB3aGVyZSBwcmFjdGljYWwu IFRoZXNlIHN0YW5kYXJkcyB3aWxsIGhlbHAgc2VjdXJpdHkgcHJhY3RpdGlvbmVycyB0byBiZSBi ZXR0ZXIgdXRpbGl6ZWQgd2l0aGluIHRoZWlyIG9yZ2FuaXphdGlvbnMgYnkgYXV0b21hdGluZyBy b3V0aW5lIHRhc2tzIHJlbGF0ZWQgdG8gZW5kcG9pbnQgYW5kIHNlcnZlciBzZWN1cml0eSBzbyB0 aGF0IHByYWN0aXRpb25lcnMgY2FuIGZvY3VzIG9uIG1vcmUgYWR2YW5jZWQgdGFza3MuIFRoZSBp bml0aWFsIGZvY3VzIG9mIHRoaXMgd29yayBpcyB0byBhZGRyZXNzIGVudGVycHJpc2UgdXNlIGNh c2VzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhY2hpZXZlIHRoaXMgYnkgY29uc3Vt aW5nIHNoYXJlZCBpbnRlbGxpZ2VuY2UgYW5kIGNvbnRpbnVpbmcgKHdpdGggY29vcGVyYXRpb24p IHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIHdvcmsgYWxyZWFkeSBwZXJmb3JtZWQgYnkgdmFyaW91 cyBvcmdhbml6YXRpb25zIGFyb3VuZCB0aGUgd29ybGQuJm5ic3A7IFRoZSBpbml0aWFsIHdvcmsg aGFzIGJlZW4gZnJ1aXRmdWwsIGFuZCB0aGUgZGF0YSBmb3JtYXRzIHByZXZpb3VzbHkgcHVibGlz aGVkIGFyZSByZWFkeSBmb3IgZXhwYW5zaW9uIG9uIHRoZSBpbnRlcm5hdGlvbmFsIHN0YWdlLiBP ZiBwYXJ0aWN1bGFyIGludGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91cCBhcmUgdGhlIHNlY3Vy aXR5IGF1dG9tYXRpb24gc3BlY2lmaWNhdGlvbnMgc3VwcG9ydGluZyBhc3NldCwgY2hhbmdlLCBj b25maWd1cmF0aW9uLCBhbmQgdnVsbmVyYWJpbGl0eSBtYW5hZ2VtZW50LiBPZiBhZGRpdGlvbmFs IGludGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91cCBhcmUgdGhlIGVtZXJnaW5nIHNlY3VyaXR5 IGF1dG9tYXRpb24gaW50ZXJmYWNlcyBhbmQgZGF0YSBmb3JtYXRzIHJlbGF0aW5nIHRvIGV2ZW50 IG1hbmFnZW1lbnQgYW5kIGNvbnRpbnVvdXMgYXNzZXNzbWVudC4mbmJzcDsgVGhlIGNvbnRpbnVv dXMgYXNzZXNzbWVudCBjYXBhYmlsaXRpZXMgZW5hYmxlIG9yZ2FuaXphdGlvbmFsIHNpdHVhdGlv bmFsIGF3YXJlbmVzcyB0aHJvdWdoIGZyZXF1ZW50IHNuYXBzaG90cyBvZiB0aGUgb3BlcmF0aW5n IHN0YXRlIG9mIHRoZWlyIGVudmlyb25tZW50LCB3aXRoIHJpc2sgcHJpb3JpdGl6ZWQgYmFzZWQg b24gY29uc3VtZWQgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgc2hhcmVkIGludGVsbGlnZW5jZSAo dnVsbmVyYWJpbGl0aWVzLCB0aHJlYXRzLCBldGMuKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QnkgdW5kZXJ0YWtpbmcgdGhp cyB3b3JrLCB3ZSByZWNvZ25pemUgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgY2F0ZWdvcmllcyBv ZiBwcm9ibGVtcyBpbiB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBkb21haW46IGRlZmluaW5nIGV4 cHJlc3Npb25zIGZvciBwYXJ0aWN1bGFyIGRvbWFpbiBjb25jZXB0cyAoaS5lLiBkYXRhIGZvcm1h dHMpLCBlc3RhYmxpc2hpbmcgYSBzdGFuZGFyZHMtYmFzZWQgZm91bmRhdGlvbiBzdXBwb3J0aW5n IHRoZSBjdXJhdGlvbiBhbmQgZXhjaGFuZ2Ugb2Ygc2VjdXJpdHkgYXV0b21hdGlvbiBjb250ZW50 IGNvbGxlY3Rpb25zIGluIGNvbnRlbnQgcmVwb3NpdG9yaWVzLCBhbmQgZW5hYmxpbmcgaW50ZXJv cGVyYWJpbGl0eSB0aHJvdWdoIHRoZSBkZXZlbG9wbWVudCBhbmQgdXNlIG9mIHN0YW5kYXJkIGlu dGVyZmFjZXMgYW5kIGNvbW11bmljYXRpb25zIHByb3RvY29scy4gQ29udGVudCBiYXNlZCBvbiBy aWNoIGRhdGEgc3RhbmRhcmRzIGFuZCBwcm90b2NvbHMgd2lsbCBwcm92aWRlIHRoZSBhdXRob3Jp dGF0aXZlIGluc3RydWN0aW9ucyBuZWVkZWQgYnkgZGF0YS1kcml2ZW4gdG9vbHMgdG8gZW5hYmxl IHRoZSBhdXRvbWF0ZWQgY29sbGVjdGlvbiBhbmQgZXhjaGFuZ2Ugb2YgY29uZmlndXJhdGlvbiBh bmQgdnVsbmVyYWJpbGl0eSBkYXRhIHBlcnRhaW5pbmcgdG8gZW50ZXJwcmlzZSBhc3NldHMuIElu Zm9ybWF0aW9uIHByb2R1Y2VkIGJ5IHRoZXNlIHRvb2xzIHdpbGwgcHJvdmlkZSBhY2N1cmF0ZSBh bmQgdGltZWx5IHNpdHVhdGlvbmFsIGF3YXJlbmVzcyBpbiBzdXBwb3J0IG9mIG9yZ2FuaXphdGlv bmFsIGRlY2lzaW9uIG1ha2luZy4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoaXMgd29ya2luZyBncm91cCB3aWxsIHByb3Zp ZGUgc29sdXRpb25zIHRvIHRoZXNlIGNhdGVnb3JpZXMgb2YgcHJvYmxlbXMgYW5kIHRoZSBtYWlu IGFyZWFzIG9mIGZvY3VzIGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIGRlc2NyaWJlZCBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4xLiBEZWZpbmUsIGVpdGhlciBieSBub3JtYXRpdmUgcmVmZXJlbmNlLCBh ZG9wdGlvbiwgb3IgY3JlYXRpb24sIGEgc2V0IG9mIHN0YW5kYXJkcyB0aGF0IGNhbiBiZSB1c2Vk IGZvciB0aGUgcHVycG9zZSBvZiBhc3Nlc3NpbmcgYW5kIGFnZ3JlZ2F0aW5nIGRldmljZSBzdGF0 ZXMgYW5kIGNvbXBhcmluZyB0aGVzZSBkZXZpY2Ugc3RhdGVzIGFnYWluc3QgZXhwZWN0ZWQgdmFs dWVzLCBhbmQgcmVwb3J0aW5nIG9uIHRob3NlIHJlc3VsdHMgaW4gYSBwcmVkZWZpbmVkIG9yIGFk IGhvYyBtYW5uZXIuJm5ic3A7IFRoaXMgYXJlYSBvZiBmb2N1cyBwcm92aWRlcyBmb3IgbmVjZXNz YXJ5IGxhbmd1YWdlIGFuZCBkYXRhIGZvcm1hdCBzcGVjaWZpY2F0aW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Mi4gRGVm aW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRvcHRpb24sIG9yIGNyZWF0aW9u LCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCB0byBjb250aW51b3VzbHkgYXNz ZXNzIGFuZCByZXBvcnQgb24gdGhlIHN0YXRlIG9mIHN5c3RlbXMsIGNvbXBvc2VkIG9mIG1hbnkg ZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMgYW5kIG5ldHdvcmtzLCBvcGVyYXRlZCBieSB2YXJ5 aW5nIHBlcnNvbm5lbCwgdG8gZW5zdXJlIHNlY3VyaXR5IHByb2Nlc3MgZWZmZWN0aXZlbmVzcyBp biBhIHByZS1kZWZpbmVkIG9yIGFkLWhvYyBtYW5uZXIuJm5ic3A7IFRoaXMgYXJlYSBvZiBmb2N1 cyBwcm92aWRlcyBmb3IgaW50ZWdyYXRpb24gcHJvdG9jb2xzIHN1cHBvcnRpbmcgcGx1ZyBhbmQg cGxheSBjb250aW51b3VzIGFzc2Vzc21lbnQgYW5kIHNlY3VyaXR5IGF1dG9tYXRpb24gbmV0d29y a2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+VGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGUgZm9sbG93aW5n IG1pbGVzdG9uZXMgaW4gdHdvIHBoYXNlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+UGhhc2UgT25lPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYXNz ZXQgZGVzY3JpcHRpb24gZm9ybWF0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tIEEgU3Rh bmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYXNzZXQgaWRlbnRpZmljYXRpb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3Bl Y2lmeWluZyBwbGF0Zm9ybSBuYW1pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0gQSBT dGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBwbGF0Zm9ybSBtYXRjaGluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVj aWZ5aW5nIHBsYXRmb3JtIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn Pi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhIGNvbnRyb2wgZnJhbWV3 b3JrIHJlcHJlc2VudGF0aW9uIGZvcm1hdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0g QSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBiZW5jaG1hcmsgY29uZmlndXJh dGlvbiByZXByZXNlbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LSBBbiBJbmZv cm1hdGlvbmFsIGRvY3VtZW50IHN0YXRpbmcgZ3VpZGVsaW5lcyAvIHJlcXVpcmVtZW50cyBmb3Ig c3BlY2lmeWluZyBjaGVja2luZyBsYW5ndWFnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn Pi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cyBzcGVjaWZ5aW5nIGRldmljZSBzdGF0ZSBjaGVj a2luZyBsYW5ndWFnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0gQSBTdGFuZGFyZHMg VHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhbiBpbnRlcnJvZ2F0aXZlIGNoZWNraW5nIGxhbmd1 YWdlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1 bWVudCBzcGVjaWZ5aW5nIGFzc2V0IHJlcG9ydGluZyBpbmZvcm1hdGlvbiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgaG93 IHRvIHVzZSB0aGUgbGFuZ3VhZ2VzIGFuZCBvdGhlciBjb250ZW50IGRlZmluZWQgaW4gdGhpcyBn cm91cCB3aXRoIHRoZSBORUEgcHJvdG9jb2xzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlBoYXNlIFR3bzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+LSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBzZWN1 cml0eSBhdXRvbWF0aW9uL2NvbnRpbnVvdXMgYXNzZXNzbWVudCBpbnRlcmZhY2VzPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlp bmcgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgdXNlZCBmb3Igc2VjdXJpdHkgYXV0b21hdGlvbiBh bmQgY29udGludW91cyBhc3Nlc3NtZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tIEEg U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIG1lc3NhZ2VzIGFuZCBuZXR3 b3JrIHByb3RvY29scyBmb3IgZGlzdHJpYnV0aW5nIHNlY3VyaXR5IGF1dG9tYXRpb24gY29udGVu dCZuYnNwOyAoY29udGVudCByZXBvc2l0b3J5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmliaW5nIHByb3RvY29scyBhbmQgZGF0 YSBmb3JtYXRzIGZvciBzZWN1cmVseSBzaGFyaW5nIGR5bmFtaWMgbmV0d29yayBzdGF0ZSBpbmZv cm1hdGlvbiBhbW9uZyBzZWN1cml0eSBzeXN0ZW1zPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PGRpdiBjbGFzcz1Nc29O b3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+PGhyIHNpemU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj5zYWNtIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNhY21AaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930BA2733B4AMBCLUSTERxcha_-- From mdavidson@mitre.org Thu Sep 13 10:49:14 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8BE21F860E for ; Thu, 13 Sep 2012 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803, 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 mbOIxADnOar4 for ; Thu, 13 Sep 2012 10:49:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3B26221F860D for ; Thu, 13 Sep 2012 10:49:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7BBC821B191D; Thu, 13 Sep 2012 13:49:11 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AA3E521B1E17; Thu, 13 Sep 2012 13:49:08 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.34]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Thu, 13 Sep 2012 13:49:08 -0400 From: "Davidson II, Mark S" To: "Waltermire, David A." , "david.oliva@verizon.net" , "sacm@ietf.org" Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrAgAAhkLCAAU5B0A== Date: Thu, 13 Sep 2012 17:49:07 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80BD1E9AAIMCMBX02MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:49:14 -0000 --_000_69F1FC52EB080B4983863BD1602520D80BD1E9AAIMCMBX02MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91LiBJ4oCZbSBoYXBweSB0byB3b3JrIHdpdGggRGF2aWQgT2xpdmEgb24gdGhpcy4N Cg0KV2hhdCBpcyB0aGUgcHJvcGVyIHByb2NlZHVyZSBmb3IgZHJhZnRpbmcgdGhlIFJGQz8gSeKA mW0gbmV3IHRvIHRoZSBJRVRGLCBzbyBkaXJlY3Rpb24gd2lsbCBiZSBiZW5lZmljaWFsLiBBbHNv LCB3aGF0IHdvdWxkIHRoZSBncm91cCBuZWVkIGZyb20gYSBkYXRlcy9kZWxpdmVyYWJsZXMgcGVy c3BlY3RpdmU/DQoNCklmIGl04oCZcyBhY2NlcHRhYmxlLCBJ4oCZbGwgd29yayBvZmZsaW5lIHdp dGggRGF2aWQgTy4gYW5kIGNvbWUgYmFjayB0byB0aGUgZ3JvdXAgYXQgcmVndWxhciBpbnRlcnZh bHMgYXMgdGhlIHNjaGVkdWxlIGRlbWFuZHMuDQoNClRoYW5rIHlvdS4NCi1NYXJrDQoNCkZyb206 IFdhbHRlcm1pcmUsIERhdmlkIEEuIFttYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdl0N ClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTIgNzo1MyBBTQ0KVG86IERhdmlkc29u IElJLCBNYXJrIFM7IGRhdmlkLm9saXZhQHZlcml6b24ubmV0OyBzYWNtQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW3NhY21dIEZXOiBTQUNNIEJvRiBSZXF1ZXN0DQoNCk1hcmssDQoNClRoYXQgd291 bGQgYmUgZ3JlYXQhICBUaGFuayB5b3UgZm9yIHZvbHVudGVlcmluZy4NCg0KU2luY2VyZWx5LA0K RGF2ZQ0KDQpGcm9tOiBEYXZpZHNvbiBJSSwgTWFyayBTIFttYWlsdG86bWRhdmlkc29uQG1pdHJl Lm9yZ108bWFpbHRvOlttYWlsdG86bWRhdmlkc29uQG1pdHJlLm9yZ10+DQpTZW50OiBXZWRuZXNk YXksIFNlcHRlbWJlciAxMiwgMjAxMiAzOjU4IFBNDQpUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5u ZXQ8bWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0PjsgV2FsdGVybWlyZSwgRGF2aWQgQS47 IHNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NhY21d IEZXOiBTQUNNIEJvRiBSZXF1ZXN0DQoNCk15IGFwb2xvZ2llcyBmb3IgdGhlIGxhdGUgcmVzcG9u c2UsIEkgZGlkbuKAmXQgZ2V0IHRvIHRoaXMgZW1haWwgdW50aWwganVzdCBub3cuDQoNCkFzIGFu IG9yaWdpbmFsIGF1dGhvciBmb3IgdGhlIEFTUiBzcGVjLCBJ4oCZZCBsaWtlIHRvIHBhcnRpY2lw YXRlIGluIGJyaW5naW5nIEFTUiB0byB0aGUgSUVURi4gSXMgdGhhdCBhIHBvc3NpYmlsaXR5Pw0K DQpUaGFuayB5b3UuDQotTWFyayBEYXZpZHNvbg0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDxtYWlsdG86ZGF2aWQu b2xpdmFAdmVyaXpvbi5uZXQ+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiAx MjoxNyBQTQ0KVG86IGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRvOmRhdmlkLndhbHRl cm1pcmVAbmlzdC5nb3Y+OyBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtzYWNtXSBGVzogU0FDTSBCb0YgUmVxdWVzdA0KDQogRGF2aWQ6DQoNCkkgd291 bGQgbGlrZSB0byB0YWtlIG9uIEFTUiAoSSBwcmVzc3VtZSB5b3UgYXJlIHRhbGtpbmcgYWJvdXQg SVIgNzg0OCBmb3IgZnV0dXJlIFNDQVAvU0FDTSB2ZXJzaW9ucykuDQoNCldoaWNoIGluIGZhY3Qs IGJyaW5ncyB1cCBhIHF1ZXN0aW9uLg0KDQpJbiB0ZXJtcyBvZiBtYXR1cml0eSwgaG93IGRvIHlv dSBrbm93IHdoaWNoIEludGVyYWdlbmN5IFJlcG9ydHMgd2lsbCBiZSBwYXJ0IG9mIGZ1dHVyZSBT QUNNL1NDQVAgdmVyc2lvbnM/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDkvMTIvMTIsIFdhbHRl cm1pcmUsIERhdmlkIEEuPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRvOmRhdmlkLndh bHRlcm1pcmVAbmlzdC5nb3Y+PiB3cm90ZToNCg0KSSBzZW50IGluIGEgcmVxdWVzdCB0byBob2xk IGEgU0FDTSBCb0YgYXQgdGhlIElFVEYgODUgbWVldGluZyBpbiBBdGxhbnRhLCBHQS4gIFRoZSBk ZXRhaWxzIGFyZSBiZWxvdyBmb3IgYW55b25lIGludGVyZXN0ZWQuICBBdCB0aGlzIHBvaW50IHdl IG5lZWQgdG8gY29tcGxldGUgcHJlcGFyYXRpb25zIGZvciB0aGUgQm9GLiAgVG8gYmUgc3VjY2Vz c2Z1bCwgd2Ugd2lsbCBuZWVkIHlvdXIgcGFydGljaXBhdGlvbiBpbiB0aGUgQm9GIGFuZCB5b3Vy IGhlbHAgZ2V0dGluZyByZWFkeS4NCg0KSGVyZSBhcmUgbWVldGluZyBkZXRhaWxzIGlmIHlvdSBh cmUgaW50ZXJlc3RlZCBpbiBtYWtpbmcgdHJhdmVsIGFycmFuZ2VtZW50czoNCg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tZWV0aW5nLzg1L2luZGV4Lmh0bWwNCg0KQXQgdGhpcyBwb2ludCB3ZSBuZWVk IGFkZGl0aW9uYWwgZHJhZnRzIHRvIGJlIHN1Ym1pdHRlZCB0byBhdWdtZW50IHRoZSBhZ2VuZGEg YW5kIHN1cHBvcnQgdGhlIEJvRi4gIEnigJlkIGJlIGhhcHB5IHRvIHdvcmsgd2l0aCBhbnlvbmUg aW50ZXJlc3RlZCBpbiBwcmVwYXJpbmcgZHJhZnRzIGZvciBhbnkgb2YgdGhlIGV4aXN0aW5nIHNw ZWNpZmljYXRpb25zIGluIHRoaXMgYXJlYSAoZS5nLiBDUEUsIEFzc2V0IElkZW50aWZpY2F0aW9u LCBBUkYsIEFTUiwgZXRjLikgIFdlIHNob3VsZCBwcm9iYWJseSBkbyBhIGRpcmVjdCBjb252ZXJz aW9uIG9mIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGZvciAtMDAgdmVyc2lvbnMgYmVmb3JlIG1h a2luZyBhbnkgY2hhbmdlcy4gIFRoZSAtMDAgZGVhZGxpbmUgZm9yIHRoZSBJRVRGIDg1IG1lZXRp bmcgaXMgMTAvMTUgd2l0aCBhbnkgdXBkYXRlZCBkcmFmdHMgZHVlIGEgd2VlayBsYXRlciBvbiAx MC8yMi4gIEFueSB2b2x1bnRlZXJzPw0KDQpXZSB3aWxsIGFsc28gbmVlZCBzcGVha2VycyB0byBw cmVzZW50IGRyYWZ0cy4gIFBsZWFzZSBsZXQgbWUgb3IgS2F0aGxlZW4ga25vdyBpZiB5b3UgYXJl IGludGVyZXN0ZWQgaW4gbWFraW5nIGEgc2hvcnQgcHJlc2VudGF0aW9uLg0KDQpXZSBhbHNvIG5l ZWQgdG8gY29udGludWUgdG8gcmVmaW5lIHRoZSBjaGFydGVyIChpbmNsdWRlZCBiZWxvdykgYW5k IHVzZSBjYXNlIGRvY3VtZW50cy4gQW55IGFkZGl0aW9uYWwgY29tbWVudHMvY2hhbmdlcyB3b3Vs ZCBiZSBhcHByZWNpYXRlZC4NCg0KU2luY2VyZWx5LA0KRGF2ZQ0KDQpGcm9tOiBXYWx0ZXJtaXJl LCBEYXZpZCBBLg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgNjo0NSBQTQ0KVG86 ICdzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPic7ICd0dXJuZXJzQGllY2EuY29tPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPic7ICdNb3Jp YXJ0eSwgS2F0aGxlZW4nDQpTdWJqZWN0OiBTQUNNIEJvRiBSZXF1ZXN0DQoNClBsZWFzZSBmaW5k IHRoZSBvdXIgcmVxdWVzdCBmb3IgYSBXRyBmb3JtYXRpb24gQm9GIGJlbG93LiAgSSBoYXZlIGFs c28gaW5jbHVkZWQgYSBkcmFmdCBjaGFydGVyIHRoYXQgd2UgaGF2ZSBiZWVuIGRldmVsb3Bpbmcg d2l0aCBmZWVkYmFjayBmcm9tIHRoZSBTQUNNIGxpc3QuICBQbGVhc2UgbGV0IG1lIGtub3cgaWYg eW91IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBpZiB5b3Ugd291bGQgbGlrZSBhbnkgYWRkaXRpb25h bCBkZXRhaWxzLg0KDQpTaW5jZXJlbHksDQpEYXZlIFdhbHRlcm1pcmUNCg0KLS0NCg0KQk9GIGZ1 bGwgbmFtZTogU2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGludW91cyBNb25pdG9yaW5nIFtT QUNNXQ0KQVJFQTogU2VjdXJpdHkNCkJPRiBDaGFpcnM6IEthdGhsZWVuIE1vcmlhcnR5IChrYXRo bGVlbi5tb3JpYXJ0eUBlbWMuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPikN CiAgICAgICAgICAgIERhdmlkIFdhbHRlcm1pcmUgKGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8 bWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+KQ0KQWdlbmRhOg0KDQoqIFJldmlldyB0 aGUgZHJhZnQgY2hhcnRlcg0KKiBSZXZpZXcgZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNl cy0wMg0KKiBSZXZpZXcgZHJhZnRzIHN1Ym1pdHRlZCBpbiBzdXBwb3J0IG9mIHRoZSBjaGFydGVy DQogIC0gZHJhZnQtd2FsdGVybWlyZS1jb250ZW50LXJlcG9zaXRvcnktMDANCiAgLSBNb3JlIGV4 cGVjdGVkIGJlZm9yZSAtMDAgZGVhZGxpbmUNCg0KRnVsbCBEZXNjcmlwdGlvbiBvZiBCT0Y6IFRo ZSBTQUNNIEJvRiBpcyBpbnRlbmRlZCB0byBwcm9ncmVzcyB0aGUgd29yayBmcm9tIHRoZSBTQUNN IG1haWxpbmcgbGlzdCB0byBzb2xpZGlmeSBkaXNjdXNzaW9ucyBvbiBhIHByb3Bvc2VkIGNoYXJ0 ZXIsIHVzZSBjYXNlcyBhbmQgbWlsZXN0b25lcyBpbiBzdXBwb3J0IG9mIG1vdmluZyB0byBhbiBJ RVRGIHdvcmtpbmcgZ3JvdXAuDQoNCkNPTkZMSUNUUyB0byBhdm9pZDogU0FBRywgTUlMRQ0KRXhw ZWN0ZWQgQXR0ZW5kYW5jZTogNDAsIG5vdCBzdXJlIHdoYXQgdGhlIHByZXZpb3VzIGF0dGVuZGFu Y2Ugd2FzPw0KU3BlY2lhbCBSZXF1ZXN0czogTWVldGVjaG8gc3VwcG9ydA0KTnVtYmVyIG9mIHNl c3Npb25zOiAxDQpMZW5ndGggb2Ygc2Vzc2lvbjogMiBob3Vycw0KDQpEcmFmdCBDaGFydGVyOg0K DQpQcm9wb3NlZCBXb3JraW5nIEdyb3VwIENoYXJ0ZXINCg0KQ2hhaXJzOg0KVEJEDQpUQkQNCg0K U2VjdXJpdHkgQXJlYSBEaXJlY3RvcnM6DQogICAgIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4+DQogICAg IFNlYW4gVHVybmVyIDx0dXJuZXJzQGllY2EuY29tPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPj4N Cg0KU2VjdXJpdHkgQXJlYSBBZHZpc29yOg0KICAgICBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNh LmNvbTxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT4+DQoNCk1haWxpbmcgTGlzdHM6DQogICAgIEdl bmVyYWwgRGlzY3Vzc2lvbjogc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCiAg ICAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FjbQ0KICAgICBBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zYWNtDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANCg0KU2Vj dXJpbmcgaW5mb3JtYXRpb24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHByb2Nlc3MsIGFu ZCB0cmFuc21pdCB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWNvbWUgYSBjaGFsbGVuZ2luZyB0YXNr IGZvciBvcmdhbml6YXRpb25zIG9mIGFsbCBzaXplcywgYW5kIHdlIGZpbmQgdGhhdCBzZWN1cml0 eSBwcmFjdGl0aW9uZXJzIHNwZW5kIG1vc3Qgb2YgdGhlaXIgdGltZSBvbiBtYW51YWwgcHJvY2Vz c2VzIHJlbGVnYXRpbmcgdGhlbSB0byBpbmVmZmVjdGl2ZW5lc3MuIFNlY3VyaXR5IGF1dG9tYXRp b24gdG8gdmVyaWZ5IHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aXRoIHRoZSBhYmlsaXR5IHRvIHBy aW9yaXRpemUgcmlzayBiYXNlZCBvbiBpbmNyZWFzZWQgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGZy b20gc2hhcmVkIGludGVsbGlnZW5jZSBpcyB0aGUga2V5IHRvIGVzY2FwaW5nIHRoaXMgcnV0LiBU aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXZlbG9wIHNlY3VyaXR5IGF1dG9tYXRpb24gc3RhbmRh cmRzIGluIHN1cHBvcnQgb2YgaW5mb3JtYXRpb24gc2VjdXJpdHkgcHJvY2Vzc2VzIGFuZCBwcmFj dGljZXMgd2hlcmUgcHJhY3RpY2FsLiBUaGVzZSBzdGFuZGFyZHMgd2lsbCBoZWxwIHNlY3VyaXR5 IHByYWN0aXRpb25lcnMgdG8gYmUgYmV0dGVyIHV0aWxpemVkIHdpdGhpbiB0aGVpciBvcmdhbml6 YXRpb25zIGJ5IGF1dG9tYXRpbmcgcm91dGluZSB0YXNrcyByZWxhdGVkIHRvIGVuZHBvaW50IGFu ZCBzZXJ2ZXIgc2VjdXJpdHkgc28gdGhhdCBwcmFjdGl0aW9uZXJzIGNhbiBmb2N1cyBvbiBtb3Jl IGFkdmFuY2VkIHRhc2tzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgdG8gYWRk cmVzcyBlbnRlcnByaXNlIHVzZSBjYXNlcy4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhY2hp ZXZlIHRoaXMgYnkgY29uc3VtaW5nIHNoYXJlZCBpbnRlbGxpZ2VuY2UgYW5kIGNvbnRpbnVpbmcg KHdpdGggY29vcGVyYXRpb24pIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIHdvcmsgYWxyZWFkeSBw ZXJmb3JtZWQgYnkgdmFyaW91cyBvcmdhbml6YXRpb25zIGFyb3VuZCB0aGUgd29ybGQuICBUaGUg aW5pdGlhbCB3b3JrIGhhcyBiZWVuIGZydWl0ZnVsLCBhbmQgdGhlIGRhdGEgZm9ybWF0cyBwcmV2 aW91c2x5IHB1Ymxpc2hlZCBhcmUgcmVhZHkgZm9yIGV4cGFuc2lvbiBvbiB0aGUgaW50ZXJuYXRp b25hbCBzdGFnZS4gT2YgcGFydGljdWxhciBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAg YXJlIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIHNwZWNpZmljYXRpb25zIHN1cHBvcnRpbmcgYXNz ZXQsIGNoYW5nZSwgY29uZmlndXJhdGlvbiwgYW5kIHZ1bG5lcmFiaWxpdHkgbWFuYWdlbWVudC4g T2YgYWRkaXRpb25hbCBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIHRoZSBlbWVy Z2luZyBzZWN1cml0eSBhdXRvbWF0aW9uIGludGVyZmFjZXMgYW5kIGRhdGEgZm9ybWF0cyByZWxh dGluZyB0byBldmVudCBtYW5hZ2VtZW50IGFuZCBjb250aW51b3VzIGFzc2Vzc21lbnQuICBUaGUg Y29udGludW91cyBhc3Nlc3NtZW50IGNhcGFiaWxpdGllcyBlbmFibGUgb3JnYW5pemF0aW9uYWwg c2l0dWF0aW9uYWwgYXdhcmVuZXNzIHRocm91Z2ggZnJlcXVlbnQgc25hcHNob3RzIG9mIHRoZSBv cGVyYXRpbmcgc3RhdGUgb2YgdGhlaXIgZW52aXJvbm1lbnQsIHdpdGggcmlzayBwcmlvcml0aXpl ZCBiYXNlZCBvbiBjb25zdW1lZCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBzaGFyZWQgaW50ZWxs aWdlbmNlICh2dWxuZXJhYmlsaXRpZXMsIHRocmVhdHMsIGV0Yy4pLg0KDQpCeSB1bmRlcnRha2lu ZyB0aGlzIHdvcmssIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBjYXRlZ29y aWVzIG9mIHByb2JsZW1zIGluIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIGRvbWFpbjogZGVmaW5p bmcgZXhwcmVzc2lvbnMgZm9yIHBhcnRpY3VsYXIgZG9tYWluIGNvbmNlcHRzIChpLmUuIGRhdGEg Zm9ybWF0cyksIGVzdGFibGlzaGluZyBhIHN0YW5kYXJkcy1iYXNlZCBmb3VuZGF0aW9uIHN1cHBv cnRpbmcgdGhlIGN1cmF0aW9uIGFuZCBleGNoYW5nZSBvZiBzZWN1cml0eSBhdXRvbWF0aW9uIGNv bnRlbnQgY29sbGVjdGlvbnMgaW4gY29udGVudCByZXBvc2l0b3JpZXMsIGFuZCBlbmFibGluZyBp bnRlcm9wZXJhYmlsaXR5IHRocm91Z2ggdGhlIGRldmVsb3BtZW50IGFuZCB1c2Ugb2Ygc3RhbmRh cmQgaW50ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzLiBDb250ZW50IGJhc2Vk IG9uIHJpY2ggZGF0YSBzdGFuZGFyZHMgYW5kIHByb3RvY29scyB3aWxsIHByb3ZpZGUgdGhlIGF1 dGhvcml0YXRpdmUgaW5zdHJ1Y3Rpb25zIG5lZWRlZCBieSBkYXRhLWRyaXZlbiB0b29scyB0byBl bmFibGUgdGhlIGF1dG9tYXRlZCBjb2xsZWN0aW9uIGFuZCBleGNoYW5nZSBvZiBjb25maWd1cmF0 aW9uIGFuZCB2dWxuZXJhYmlsaXR5IGRhdGEgcGVydGFpbmluZyB0byBlbnRlcnByaXNlIGFzc2V0 cy4gSW5mb3JtYXRpb24gcHJvZHVjZWQgYnkgdGhlc2UgdG9vbHMgd2lsbCBwcm92aWRlIGFjY3Vy YXRlIGFuZCB0aW1lbHkgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIGluIHN1cHBvcnQgb2Ygb3JnYW5p emF0aW9uYWwgZGVjaXNpb24gbWFraW5nLg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm92 aWRlIHNvbHV0aW9ucyB0byB0aGVzZSBjYXRlZ29yaWVzIG9mIHByb2JsZW1zIGFuZCB0aGUgbWFp biBhcmVhcyBvZiBmb2N1cyBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIGFyZSBkZXNjcmliZWQgYXMg Zm9sbG93czoNCg0KMS4gRGVmaW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRv cHRpb24sIG9yIGNyZWF0aW9uLCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCBm b3IgdGhlIHB1cnBvc2Ugb2YgYXNzZXNzaW5nIGFuZCBhZ2dyZWdhdGluZyBkZXZpY2Ugc3RhdGVz IGFuZCBjb21wYXJpbmcgdGhlc2UgZGV2aWNlIHN0YXRlcyBhZ2FpbnN0IGV4cGVjdGVkIHZhbHVl cywgYW5kIHJlcG9ydGluZyBvbiB0aG9zZSByZXN1bHRzIGluIGEgcHJlZGVmaW5lZCBvciBhZCBo b2MgbWFubmVyLiAgVGhpcyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBuZWNlc3NhcnkgbGFu Z3VhZ2UgYW5kIGRhdGEgZm9ybWF0IHNwZWNpZmljYXRpb25zLg0KDQoyLiBEZWZpbmUsIGVpdGhl ciBieSBub3JtYXRpdmUgcmVmZXJlbmNlLCBhZG9wdGlvbiwgb3IgY3JlYXRpb24sIGEgc2V0IG9m IHN0YW5kYXJkcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGNvbnRpbnVvdXNseSBhc3Nlc3MgYW5kIHJl cG9ydCBvbiB0aGUgc3RhdGUgb2Ygc3lzdGVtcywgY29tcG9zZWQgb2YgbWFueSBkaWZmZXJlbnQg dHlwZXMgb2YgZGV2aWNlcyBhbmQgbmV0d29ya3MsIG9wZXJhdGVkIGJ5IHZhcnlpbmcgcGVyc29u bmVsLCB0byBlbnN1cmUgc2VjdXJpdHkgcHJvY2VzcyBlZmZlY3RpdmVuZXNzIGluIGEgcHJlLWRl ZmluZWQgb3IgYWQtaG9jIG1hbm5lci4gIFRoaXMgYXJlYSBvZiBmb2N1cyBwcm92aWRlcyBmb3Ig aW50ZWdyYXRpb24gcHJvdG9jb2xzIHN1cHBvcnRpbmcgcGx1ZyBhbmQgcGxheSBjb250aW51b3Vz IGFzc2Vzc21lbnQgYW5kIHNlY3VyaXR5IGF1dG9tYXRpb24gbmV0d29ya2luZy4NCg0KVGhpcyB3 b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZXMgaW4gdHdv IHBoYXNlczoNCg0KUGhhc2UgT25lDQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNp ZnlpbmcgYXNzZXQgZGVzY3JpcHRpb24gZm9ybWF0DQotIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3Vt ZW50IHNwZWNpZnlpbmcgYXNzZXQgaWRlbnRpZmljYXRpb24NCi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBwbGF0Zm9ybSBuYW1pbmcNCi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBwbGF0Zm9ybSBtYXRjaGluZw0KLSBBIFN0YW5kYXJkcyBUcmFj ayBkb2N1bWVudCBzcGVjaWZ5aW5nIHBsYXRmb3JtIGFwcGxpY2FiaWxpdHkNCi0gQSBTdGFuZGFy ZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBhIGNvbnRyb2wgZnJhbWV3b3JrIHJlcHJlc2Vu dGF0aW9uIGZvcm1hdC4NCi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBi ZW5jaG1hcmsgY29uZmlndXJhdGlvbiByZXByZXNlbnRhdGlvbg0KLSBBbiBJbmZvcm1hdGlvbmFs IGRvY3VtZW50IHN0YXRpbmcgZ3VpZGVsaW5lcyAvIHJlcXVpcmVtZW50cyBmb3Igc3BlY2lmeWlu ZyBjaGVja2luZyBsYW5ndWFnZXMNCi0gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cyBzcGVjaWZ5 aW5nIGRldmljZSBzdGF0ZSBjaGVja2luZyBsYW5ndWFnZXMNCi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBhbiBpbnRlcnJvZ2F0aXZlIGNoZWNraW5nIGxhbmd1YWdlDQot IEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYXNzZXQgcmVwb3J0aW5nIGlu Zm9ybWF0aW9uDQotIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmliaW5nIGhvdyB0byB1 c2UgdGhlIGxhbmd1YWdlcyBhbmQgb3RoZXIgY29udGVudCBkZWZpbmVkIGluIHRoaXMgZ3JvdXAg d2l0aCB0aGUgTkVBIHByb3RvY29scw0KDQpQaGFzZSBUd28NCi0gU3RhbmRhcmRzIFRyYWNrIGRv Y3VtZW50IHNwZWNpZnlpbmcgc2VjdXJpdHkgYXV0b21hdGlvbi9jb250aW51b3VzIGFzc2Vzc21l bnQgaW50ZXJmYWNlcw0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGNv bW11bmljYXRpb24gcHJvdG9jb2xzIHVzZWQgZm9yIHNlY3VyaXR5IGF1dG9tYXRpb24gYW5kIGNv bnRpbnVvdXMgYXNzZXNzbWVudA0KLSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBkZXNjcmli aW5nIHRoZSBtZXNzYWdlcyBhbmQgbmV0d29yayBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGluZyBz ZWN1cml0eSBhdXRvbWF0aW9uIGNvbnRlbnQgIChjb250ZW50IHJlcG9zaXRvcnkpDQotIEEgU3Rh bmRhcmRzIFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIGZvcm1h dHMgZm9yIHNlY3VyZWx5IHNoYXJpbmcgZHluYW1pYyBuZXR3b3JrIHN0YXRlIGluZm9ybWF0aW9u IGFtb25nIHNlY3VyaXR5IHN5c3RlbXMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg== --_000_69F1FC52EB080B4983863BD1602520D80BD1E9AAIMCMBX02MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UuIEnigJltIGhh cHB5IHRvIHdvcmsgd2l0aCBEYXZpZCBPbGl2YSBvbiB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hhdCBpcyB0 aGUgcHJvcGVyIHByb2NlZHVyZSBmb3IgZHJhZnRpbmcgdGhlIFJGQz8gSeKAmW0gbmV3IHRvIHRo ZSBJRVRGLCBzbyBkaXJlY3Rpb24gd2lsbCBiZSBiZW5lZmljaWFsLiBBbHNvLCB3aGF0IHdvdWxk IHRoZSBncm91cCBuZWVkIGZyb20gYSBkYXRlcy9kZWxpdmVyYWJsZXMNCiBwZXJzcGVjdGl2ZT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPklmIGl04oCZcyBhY2NlcHRhYmxlLCBJ4oCZbGwgd29yayBvZmZsaW5lIHdpdGgg RGF2aWQgTy4gYW5kIGNvbWUgYmFjayB0byB0aGUgZ3JvdXAgYXQgcmVndWxhciBpbnRlcnZhbHMg YXMgdGhlIHNjaGVkdWxlIGRlbWFuZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPi1NYXJrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFdhbHRlcm1pcmUsIERhdmlkIEEuIFttYWlsdG86ZGF2aWQud2FsdGVybWly ZUBuaXN0Lmdvdl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAy MDEyIDc6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkc29uIElJLCBNYXJrIFM7IGRhdmlkLm9s aXZhQHZlcml6b24ubmV0OyBzYWNtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb c2FjbV0gRlc6IFNBQ00gQm9GIFJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXJr LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGF0IHdvdWxkIGJlIGdyZWF0ISZuYnNwOyBUaGFuayB5b3UgZm9yIHZvbHVudGVlcmlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IERhdmlkc29uIElJLCBNYXJrIFMNCjxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOm1kYXZpZHNvbkBtaXRyZS5vcmddIj5bbWFpbHRvOm1kYXZpZHNvbkBtaXRyZS5vcmddPC9h PiA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMzo1OCBQ TTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0 Ij5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDwvYT47IFdhbHRlcm1pcmUsIERhdmlkIEEuOw0KPGEg aHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbc2FjbV0gRlc6IFNBQ00gQm9GIFJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5NeSBhcG9sb2dpZXMgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLCBJIGRpZG7igJl0 IGdldCB0byB0aGlzIGVtYWlsIHVudGlsIGp1c3Qgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBhbiBvcmlnaW5hbCBhdXRo b3IgZm9yIHRoZSBBU1Igc3BlYywgSeKAmWQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiBicmluZ2lu ZyBBU1IgdG8gdGhlIElFVEYuIElzIHRoYXQgYSBwb3NzaWJpbGl0eT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU1h cmsgRGF2aWRzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVm PSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOmRh dmlkLm9saXZhQHZlcml6b24ubmV0Ij5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDwvYT48YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMTI6MTcgUE08YnI+DQo8 Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Ij5kYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3Jn Ij5zYWNtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21dIEZXOiBT QUNNIEJvRiBSZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwO0RhdmlkOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+SSB3b3VsZCBsaWtlIHRvIHRha2Ugb24gQVNSIChJIHByZXNzdW1l IHlvdSBhcmUgdGFsa2luZyBhYm91dCBJUiA3ODQ4IGZvciBmdXR1cmUgU0NBUC9TQUNNIHZlcnNp b25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoaWNoIGluIGZhY3QsIGJyaW5ncyB1cCBh IHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SW4gdGVybXMgb2YgbWF0dXJpdHks IGhvdyBkbyB5b3Uga25vdyB3aGljaCBJbnRlcmFnZW5jeSBSZXBvcnRzIHdpbGwgYmUgcGFydCBv ZiBmdXR1cmUgU0FDTS9TQ0FQIHZlcnNpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGF2 aWQgT2xpdmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIDA5LzEyLzEyLCBX YWx0ZXJtaXJlLCBEYXZpZCBBLiZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBu aXN0LmdvdiI+ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SSBzZW50IGluIGEgcmVxdWVzdCB0byBob2xkIGEgU0FDTSBCb0YgYXQgdGhlIElFVEYgODUg bWVldGluZyBpbiBBdGxhbnRhLCBHQS4mbmJzcDsgVGhlIGRldGFpbHMgYXJlIGJlbG93IGZvciBh bnlvbmUgaW50ZXJlc3RlZC4mbmJzcDsgQXQgdGhpcyBwb2ludCB3ZSBuZWVkIHRvIGNvbXBsZXRl IHByZXBhcmF0aW9ucyBmb3IgdGhlIEJvRi4mbmJzcDsgVG8gYmUgc3VjY2Vzc2Z1bCwgd2Ugd2ls bCBuZWVkIHlvdXIgcGFydGljaXBhdGlvbg0KIGluIHRoZSBCb0YgYW5kIHlvdXIgaGVscCBnZXR0 aW5nIHJlYWR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IZXJlIGFyZSBtZWV0 aW5nIGRldGFpbHMgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIG1ha2luZyB0cmF2ZWwgYXJyYW5n ZW1lbnRzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL21lZXRpbmcvODUvaW5kZXguaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NS9pbmRleC5odG1sPC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5BdCB0aGlzIHBvaW50IHdlIG5lZWQgYWRkaXRpb25hbCBkcmFmdHMg dG8gYmUgc3VibWl0dGVkIHRvIGF1Z21lbnQgdGhlIGFnZW5kYSBhbmQgc3VwcG9ydCB0aGUgQm9G LiZuYnNwOyBJ4oCZZCBiZSBoYXBweSB0byB3b3JrIHdpdGggYW55b25lIGludGVyZXN0ZWQgaW4g cHJlcGFyaW5nIGRyYWZ0cyBmb3IgYW55IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyBp biB0aGlzIGFyZWEgKGUuZy4gQ1BFLCBBc3NldA0KIElkZW50aWZpY2F0aW9uLCBBUkYsIEFTUiwg ZXRjLikmbmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5IGRvIGEgZGlyZWN0IGNvbnZlcnNpb24gb2Yg ZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgZm9yIC0wMCB2ZXJzaW9ucyBiZWZvcmUgbWFraW5nIGFu eSBjaGFuZ2VzLiZuYnNwOyBUaGUgLTAwIGRlYWRsaW5lIGZvciB0aGUgSUVURiA4NSBtZWV0aW5n IGlzIDEwLzE1IHdpdGggYW55IHVwZGF0ZWQgZHJhZnRzIGR1ZSBhIHdlZWsgbGF0ZXIgb24gMTAv MjIuJm5ic3A7IEFueSB2b2x1bnRlZXJzPw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPldlIHdpbGwgYWxzbyBuZWVkIHNwZWFrZXJzIHRvIHByZXNlbnQgZHJhZnRzLiZuYnNwOyBQ bGVhc2UgbGV0IG1lIG9yIEthdGhsZWVuIGtub3cgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIG1h a2luZyBhIHNob3J0IHByZXNlbnRhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+V2UgYWxzbyBuZWVkIHRvIGNvbnRpbnVlIHRvIHJlZmluZSB0aGUgY2hhcnRlciAoaW5jbHVk ZWQgYmVsb3cpIGFuZCB1c2UgY2FzZSBkb2N1bWVudHMuIEFueSBhZGRpdGlvbmFsIGNvbW1lbnRz L2NoYW5nZXMgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlNpbmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhdmU8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4gV2FsdGVybWlyZSwgRGF2aWQgQS4NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiA2OjQ1IFBNPGJyPg0KPGI+VG86PC9iPiAn PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5r Ij5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPic7ICc8YSBocmVmPSJtYWlsdG86dHVybmVy c0BpZWNhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR1cm5lcnNAaWVjYS5jb208L2E+JzsgJ01vcmlh cnR5LCBLYXRobGVlbic8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU0FDTSBCb0YgUmVxdWVzdDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5QbGVhc2UgZmluZCB0aGUgb3VyIHJlcXVlc3QgZm9yIGEgV0cgZm9ybWF0aW9uIEJv RiBiZWxvdy4mbmJzcDsgSSBoYXZlIGFsc28gaW5jbHVkZWQgYSBkcmFmdCBjaGFydGVyIHRoYXQg d2UgaGF2ZSBiZWVuIGRldmVsb3Bpbmcgd2l0aCBmZWVkYmFjayBmcm9tIHRoZSBTQUNNIGxpc3Qu Jm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIGlm IHlvdSB3b3VsZCBsaWtlIGFueSBhZGRpdGlvbmFsDQogZGV0YWlscy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5TaW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGF2ZSBX YWx0ZXJtaXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CT0Yg ZnVsbCBuYW1lOiBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3Jpbmcg W1NBQ01dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QVJFQTogU2VjdXJpdHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CT0YgQ2hhaXJzOiBLYXRobGVlbiBN b3JpYXJ0eSAoPGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20iIHRhcmdl dD0iX2JsYW5rIj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9hPik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2aWQgV2FsdGVybWlyZSAoPGEgaHJlZj0i bWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiIHRhcmdldD0iX2JsYW5rIj5kYXZpZC53 YWx0ZXJtaXJlQG5pc3QuZ292PC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5BZ2VuZGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KiBSZXZpZXcgdGhlIGRyYWZ0IGNoYXJ0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4qIFJldmlldyBkcmFmdC13YWx0ZXJt aXJlLXNhY20tdXNlLWNhc2VzLTAyIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiogUmV2aWV3IGRyYWZ0cyBzdWJtaXR0ZWQgaW4gc3VwcG9ydCBvZiB0aGUgY2hhcnRlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIGRyYWZ0LXdhbHRlcm1pcmUt Y29udGVudC1yZXBvc2l0b3J5LTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7IC0gTW9yZSBleHBlY3RlZCBiZWZvcmUgLTAwIGRlYWRsaW5lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+RnVsbCBEZXNjcmlwdGlvbiBvZiBCT0Y6IFRoZSBTQUNNIEJvRiBpcyBpbnRlbmRlZCB0 byBwcm9ncmVzcyB0aGUgd29yayBmcm9tIHRoZSBTQUNNIG1haWxpbmcgbGlzdCB0byBzb2xpZGlm eSBkaXNjdXNzaW9ucyBvbiBhIHByb3Bvc2VkIGNoYXJ0ZXIsIHVzZSBjYXNlcyBhbmQgbWlsZXN0 b25lcyBpbiBzdXBwb3J0IG9mIG1vdmluZyB0byBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Q09ORkxJQ1RTIHRvIGF2b2lkOiBTQUFHLCBNSUxFPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RXhwZWN0ZWQgQXR0ZW5kYW5jZTogNDAsIG5vdCBzdXJl IHdoYXQgdGhlIHByZXZpb3VzIGF0dGVuZGFuY2Ugd2FzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlNwZWNpYWwgUmVxdWVzdHM6IE1lZXRlY2hvIHN1cHBvcnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OdW1iZXIgb2Ygc2Vzc2lvbnM6IDE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5MZW5ndGggb2Ygc2Vzc2lvbjogMiBob3VyczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkRyYWZ0IENoYXJ0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UHJvcG9z ZWQgV29ya2luZyBHcm91cCBDaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2hhaXJzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRCRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRCRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3VyaXR5IEFyZWEgRGlyZWN0 b3JzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwv YT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnR1cm5lcnNAaWVjYS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlNlY3VyaXR5IEFyZWEgQWR2aXNvcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+dHVybmVyc0BpZWNhLmNv bTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFpbGluZyBMaXN0czo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR2VuZXJhbCBE aXNjdXNzaW9uOiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0Kc2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG8gU3Vic2NyaWJlOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFyY2hpdmU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zYWNtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5EZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2Vj dXJpbmcgaW5mb3JtYXRpb24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHByb2Nlc3MsIGFu ZCB0cmFuc21pdCB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWNvbWUgYSBjaGFsbGVuZ2luZyB0YXNr IGZvciBvcmdhbml6YXRpb25zIG9mIGFsbCBzaXplcywgYW5kIHdlIGZpbmQgdGhhdCBzZWN1cml0 eSBwcmFjdGl0aW9uZXJzIHNwZW5kIG1vc3Qgb2YgdGhlaXIgdGltZSBvbiBtYW51YWwgcHJvY2Vz c2VzDQogcmVsZWdhdGluZyB0aGVtIHRvIGluZWZmZWN0aXZlbmVzcy4gU2VjdXJpdHkgYXV0b21h dGlvbiB0byB2ZXJpZnkgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIHdpdGggdGhlIGFiaWxpdHkgdG8g cHJpb3JpdGl6ZSByaXNrIGJhc2VkIG9uIGluY3JlYXNlZCBzaXR1YXRpb25hbCBhd2FyZW5lc3Mg ZnJvbSBzaGFyZWQgaW50ZWxsaWdlbmNlIGlzIHRoZSBrZXkgdG8gZXNjYXBpbmcgdGhpcyBydXQu IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Agc2VjdXJpdHkNCiBhdXRvbWF0aW9uIHN0 YW5kYXJkcyBpbiBzdXBwb3J0IG9mIGluZm9ybWF0aW9uIHNlY3VyaXR5IHByb2Nlc3NlcyBhbmQg cHJhY3RpY2VzIHdoZXJlIHByYWN0aWNhbC4gVGhlc2Ugc3RhbmRhcmRzIHdpbGwgaGVscCBzZWN1 cml0eSBwcmFjdGl0aW9uZXJzIHRvIGJlIGJldHRlciB1dGlsaXplZCB3aXRoaW4gdGhlaXIgb3Jn YW5pemF0aW9ucyBieSBhdXRvbWF0aW5nIHJvdXRpbmUgdGFza3MgcmVsYXRlZCB0byBlbmRwb2lu dCBhbmQgc2VydmVyIHNlY3VyaXR5DQogc28gdGhhdCBwcmFjdGl0aW9uZXJzIGNhbiBmb2N1cyBv biBtb3JlIGFkdmFuY2VkIHRhc2tzLiBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGlzIHdvcmsgaXMg dG8gYWRkcmVzcyBlbnRlcnByaXNlIHVzZSBjYXNlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgYWNoaWV2ZSB0aGlzIGJ5IGNvbnN1bWluZyBzaGFyZWQgaW50 ZWxsaWdlbmNlIGFuZCBjb250aW51aW5nICh3aXRoIGNvb3BlcmF0aW9uKSB0aGUgc2VjdXJpdHkg YXV0b21hdGlvbiB3b3JrIGFscmVhZHkgcGVyZm9ybWVkIGJ5IHZhcmlvdXMgb3JnYW5pemF0aW9u cyBhcm91bmQgdGhlIHdvcmxkLiZuYnNwOyBUaGUgaW5pdGlhbCB3b3JrIGhhcyBiZWVuIGZydWl0 ZnVsLCBhbmQNCiB0aGUgZGF0YSBmb3JtYXRzIHByZXZpb3VzbHkgcHVibGlzaGVkIGFyZSByZWFk eSBmb3IgZXhwYW5zaW9uIG9uIHRoZSBpbnRlcm5hdGlvbmFsIHN0YWdlLiBPZiBwYXJ0aWN1bGFy IGludGVyZXN0IHRvIHRoaXMgd29ya2luZyBncm91cCBhcmUgdGhlIHNlY3VyaXR5IGF1dG9tYXRp b24gc3BlY2lmaWNhdGlvbnMgc3VwcG9ydGluZyBhc3NldCwgY2hhbmdlLCBjb25maWd1cmF0aW9u LCBhbmQgdnVsbmVyYWJpbGl0eSBtYW5hZ2VtZW50LiBPZiBhZGRpdGlvbmFsDQogaW50ZXJlc3Qg dG8gdGhpcyB3b3JraW5nIGdyb3VwIGFyZSB0aGUgZW1lcmdpbmcgc2VjdXJpdHkgYXV0b21hdGlv biBpbnRlcmZhY2VzIGFuZCBkYXRhIGZvcm1hdHMgcmVsYXRpbmcgdG8gZXZlbnQgbWFuYWdlbWVu dCBhbmQgY29udGludW91cyBhc3Nlc3NtZW50LiZuYnNwOyBUaGUgY29udGludW91cyBhc3Nlc3Nt ZW50IGNhcGFiaWxpdGllcyBlbmFibGUgb3JnYW5pemF0aW9uYWwgc2l0dWF0aW9uYWwgYXdhcmVu ZXNzIHRocm91Z2ggZnJlcXVlbnQgc25hcHNob3RzDQogb2YgdGhlIG9wZXJhdGluZyBzdGF0ZSBv ZiB0aGVpciBlbnZpcm9ubWVudCwgd2l0aCByaXNrIHByaW9yaXRpemVkIGJhc2VkIG9uIGNvbnN1 bWVkIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHNoYXJlZCBpbnRlbGxpZ2VuY2UgKHZ1bG5lcmFi aWxpdGllcywgdGhyZWF0cywgZXRjLikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QnkgdW5kZXJ0YWtp bmcgdGhpcyB3b3JrLCB3ZSByZWNvZ25pemUgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgY2F0ZWdv cmllcyBvZiBwcm9ibGVtcyBpbiB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBkb21haW46IGRlZmlu aW5nIGV4cHJlc3Npb25zIGZvciBwYXJ0aWN1bGFyIGRvbWFpbiBjb25jZXB0cyAoaS5lLiBkYXRh IGZvcm1hdHMpLCBlc3RhYmxpc2hpbmcgYSBzdGFuZGFyZHMtYmFzZWQgZm91bmRhdGlvbg0KIHN1 cHBvcnRpbmcgdGhlIGN1cmF0aW9uIGFuZCBleGNoYW5nZSBvZiBzZWN1cml0eSBhdXRvbWF0aW9u IGNvbnRlbnQgY29sbGVjdGlvbnMgaW4gY29udGVudCByZXBvc2l0b3JpZXMsIGFuZCBlbmFibGlu ZyBpbnRlcm9wZXJhYmlsaXR5IHRocm91Z2ggdGhlIGRldmVsb3BtZW50IGFuZCB1c2Ugb2Ygc3Rh bmRhcmQgaW50ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzLiBDb250ZW50IGJh c2VkIG9uIHJpY2ggZGF0YSBzdGFuZGFyZHMNCiBhbmQgcHJvdG9jb2xzIHdpbGwgcHJvdmlkZSB0 aGUgYXV0aG9yaXRhdGl2ZSBpbnN0cnVjdGlvbnMgbmVlZGVkIGJ5IGRhdGEtZHJpdmVuIHRvb2xz IHRvIGVuYWJsZSB0aGUgYXV0b21hdGVkIGNvbGxlY3Rpb24gYW5kIGV4Y2hhbmdlIG9mIGNvbmZp Z3VyYXRpb24gYW5kIHZ1bG5lcmFiaWxpdHkgZGF0YSBwZXJ0YWluaW5nIHRvIGVudGVycHJpc2Ug YXNzZXRzLiBJbmZvcm1hdGlvbiBwcm9kdWNlZCBieSB0aGVzZSB0b29scyB3aWxsIHByb3ZpZGUN CiBhY2N1cmF0ZSBhbmQgdGltZWx5IHNpdHVhdGlvbmFsIGF3YXJlbmVzcyBpbiBzdXBwb3J0IG9m IG9yZ2FuaXphdGlvbmFsIGRlY2lzaW9uIG1ha2luZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo aXMgd29ya2luZyBncm91cCB3aWxsIHByb3ZpZGUgc29sdXRpb25zIHRvIHRoZXNlIGNhdGVnb3Jp ZXMgb2YgcHJvYmxlbXMgYW5kIHRoZSBtYWluIGFyZWFzIG9mIGZvY3VzIGZvciB0aGlzIHdvcmtp bmcgZ3JvdXAgYXJlIGRlc2NyaWJlZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEu IERlZmluZSwgZWl0aGVyIGJ5IG5vcm1hdGl2ZSByZWZlcmVuY2UsIGFkb3B0aW9uLCBvciBjcmVh dGlvbiwgYSBzZXQgb2Ygc3RhbmRhcmRzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHRoZSBwdXJwb3Nl IG9mIGFzc2Vzc2luZyBhbmQgYWdncmVnYXRpbmcgZGV2aWNlIHN0YXRlcyBhbmQgY29tcGFyaW5n IHRoZXNlIGRldmljZSBzdGF0ZXMgYWdhaW5zdCBleHBlY3RlZCB2YWx1ZXMsIGFuZCByZXBvcnRp bmcNCiBvbiB0aG9zZSByZXN1bHRzIGluIGEgcHJlZGVmaW5lZCBvciBhZCBob2MgbWFubmVyLiZu YnNwOyBUaGlzIGFyZWEgb2YgZm9jdXMgcHJvdmlkZXMgZm9yIG5lY2Vzc2FyeSBsYW5ndWFnZSBh bmQgZGF0YSBmb3JtYXQgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Mi4gRGVm aW5lLCBlaXRoZXIgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYWRvcHRpb24sIG9yIGNyZWF0aW9u LCBhIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBjYW4gYmUgdXNlZCB0byBjb250aW51b3VzbHkgYXNz ZXNzIGFuZCByZXBvcnQgb24gdGhlIHN0YXRlIG9mIHN5c3RlbXMsIGNvbXBvc2VkIG9mIG1hbnkg ZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMgYW5kIG5ldHdvcmtzLCBvcGVyYXRlZCBieSB2YXJ5 aW5nDQogcGVyc29ubmVsLCB0byBlbnN1cmUgc2VjdXJpdHkgcHJvY2VzcyBlZmZlY3RpdmVuZXNz IGluIGEgcHJlLWRlZmluZWQgb3IgYWQtaG9jIG1hbm5lci4mbmJzcDsgVGhpcyBhcmVhIG9mIGZv Y3VzIHByb3ZpZGVzIGZvciBpbnRlZ3JhdGlvbiBwcm90b2NvbHMgc3VwcG9ydGluZyBwbHVnIGFu ZCBwbGF5IGNvbnRpbnVvdXMgYXNzZXNzbWVudCBhbmQgc2VjdXJpdHkgYXV0b21hdGlvbiBuZXR3 b3JraW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgd29ya2luZyBncm91cCB3aWxsIGFjaGll dmUgdGhlIGZvbGxvd2luZyBtaWxlc3RvbmVzIGluIHR3byBwaGFzZXM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+UGhhc2UgT25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0 YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGFzc2V0IGRlc2NyaXB0aW9uIGZvcm1h dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0gQSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQgc3BlY2lmeWluZyBhc3NldCBpZGVudGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWlu ZyBwbGF0Zm9ybSBuYW1pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEg U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gbWF0Y2hpbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4w aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3Vt ZW50IHNwZWNpZnlpbmcgcGxhdGZvcm0gYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPi0gQSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyBh IGNvbnRyb2wgZnJhbWV3b3JrIHJlcHJlc2VudGF0aW9uIGZvcm1hdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlp bmcgYmVuY2htYXJrIGNvbmZpZ3VyYXRpb24gcmVwcmVzZW50YXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4tIEFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgc3RhdGluZyBn dWlkZWxpbmVzIC8gcmVxdWlyZW1lbnRzIGZvciBzcGVjaWZ5aW5nIGNoZWNraW5nIGxhbmd1YWdl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0gU3RhbmRhcmRzIFRyYWNrIGRv Y3VtZW50cyBzcGVjaWZ5aW5nIGRldmljZSBzdGF0ZSBjaGVja2luZyBsYW5ndWFnZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4i Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50 IHNwZWNpZnlpbmcgYW4gaW50ZXJyb2dhdGl2ZSBjaGVja2luZyBsYW5ndWFnZQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBz cGVjaWZ5aW5nIGFzc2V0IHJlcG9ydGluZyBpbmZvcm1hdGlvbg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+LSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyBo b3cgdG8gdXNlIHRoZSBsYW5ndWFnZXMgYW5kIG90aGVyIGNvbnRlbnQgZGVmaW5lZCBpbiB0aGlz IGdyb3VwIHdpdGggdGhlIE5FQSBwcm90b2NvbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGFzZSBU d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIFN0YW5kYXJkcyBUcmFjayBk b2N1bWVudCBzcGVjaWZ5aW5nIHNlY3VyaXR5IGF1dG9tYXRpb24vY29udGludW91cyBhc3Nlc3Nt ZW50IGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3Rh bmRhcmRzIFRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMg dXNlZCBmb3Igc2VjdXJpdHkgYXV0b21hdGlvbiBhbmQgY29udGludW91cyBhc3Nlc3NtZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBIFN0YW5kYXJkcyBUcmFjayBkb2N1 bWVudCBkZXNjcmliaW5nIHRoZSBtZXNzYWdlcyBhbmQgbmV0d29yayBwcm90b2NvbHMgZm9yIGRp c3RyaWJ1dGluZyBzZWN1cml0eSBhdXRvbWF0aW9uIGNvbnRlbnQmbmJzcDsgKGNvbnRlbnQgcmVw b3NpdG9yeSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEEgU3RhbmRhcmRz IFRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIGZvcm1hdHMgZm9y IHNlY3VyZWx5IHNoYXJpbmcgZHluYW1pYyBuZXR3b3JrIHN0YXRlIGluZm9ybWF0aW9uIGFtb25n IHNlY3VyaXR5IHN5c3RlbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNhY20gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_69F1FC52EB080B4983863BD1602520D80BD1E9AAIMCMBX02MITREOR_-- From kathleen.moriarty@emc.com Thu Sep 13 11:00:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA9521F8616 for ; Thu, 13 Sep 2012 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, LONGWORDS=1.803] 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 rVN7o0qi-pXY for ; Thu, 13 Sep 2012 11:00:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0E21F860D for ; Thu, 13 Sep 2012 11:00:41 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8DI0bBl024211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2012 14:00:40 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 13 Sep 2012 14:00:32 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8DI0Uil000575; Thu, 13 Sep 2012 14:00:30 -0400 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Sep 2012 14:00:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Thu, 13 Sep 2012 14:00:29 -0400 From: "Moriarty, Kathleen" To: "Davidson II, Mark S" , "Waltermire, David A." , "david.oliva@verizon.net" , "sacm@ietf.org" Date: Thu, 13 Sep 2012 13:56:05 -0400 Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrAgAAhkLCAAU5B0IAAAqk8 Message-ID: References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> , <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 18:00:43 -0000 Hi Mark, Many thanks to you and Dave for preparing a draft! The following link shou= ld help to answer all your questions: http://www.ietf.org/id-info/guidelines.html I use the xml template when working on drafts, but there are other options = such as the Word template. You and Dave should decide which works best for= you and prepare the draft using that format. You will run into some quest= ions like what state do I put the document in? Informational will work for= now and it can get changed later. The naming of the draft as well (file n= ame) is covered in the link and you can follow the examples of other docume= nts recently posted. Please post any specific questions. =20 Best regards, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Davidson I= I, Mark S [mdavidson@mitre.org] Sent: Thursday, September 13, 2012 1:49 PM To: Waltermire, David A.; david.oliva@verizon.net; sacm@ietf.org Subject: Re: [sacm] FW: SACM BoF Request Thank you. I=92m happy to work with David Oliva on this. What is the proper procedure for drafting the RFC? I=92m new to the IETF, s= o direction will be beneficial. Also, what would the group need from a date= s/deliverables perspective? If it=92s acceptable, I=92ll work offline with David O. and come back to th= e group at regular intervals as the schedule demands. Thank you. -Mark From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Thursday, September 13, 2012 7:53 AM To: Davidson II, Mark S; david.oliva@verizon.net; sacm@ietf.org Subject: RE: [sacm] FW: SACM BoF Request Mark, That would be great! Thank you for volunteering. Sincerely, Dave From: Davidson II, Mark S [mailto:mdavidson@mitre.org] Sent: Wednesday, September 12, 2012 3:58 PM To: david.oliva@verizon.net; Waltermire, Da= vid A.; sacm@ietf.org Subject: RE: [sacm] FW: SACM BoF Request My apologies for the late response, I didn=92t get to this email until just= now. As an original author for the ASR spec, I=92d like to participate in bringi= ng ASR to the IETF. Is that a possibility? Thank you. -Mark Davidson From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of david.oliva@verizon.net Sent: Wednesday, September 12, 2012 12:17 PM To: david.waltermire@nist.gov; sacm@ietf.= org Subject: Re: [sacm] FW: SACM BoF Request David: I would like to take on ASR (I pressume you are talking about IR 7848 for f= uture SCAP/SACM versions). Which in fact, brings up a question. In terms of maturity, how do you know which Interagency Reports will be par= t of future SACM/SCAP versions? David Oliva On 09/12/12, Waltermire, David A.> wrote: I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, G= A. The details are below for anyone interested. At this point we need to = complete preparations for the BoF. To be successful, we will need your par= ticipation in the BoF and your help getting ready. Here are meeting details if you are interested in making travel arrangement= s: http://www.ietf.org/meeting/85/index.html At this point we need additional drafts to be submitted to augment the agen= da and support the BoF. I=92d be happy to work with anyone interested in p= reparing drafts for any of the existing specifications in this area (e.g. C= PE, Asset Identification, ARF, ASR, etc.) We should probably do a direct c= onversion of existing specifications for -00 versions before making any cha= nges. The -00 deadline for the IETF 85 meeting is 10/15 with any updated d= rafts due a week later on 10/22. Any volunteers? We will also need speakers to present drafts. Please let me or Kathleen kn= ow if you are interested in making a short presentation. We also need to continue to refine the charter (included below) and use cas= e documents. Any additional comments/changes would be appreciated. Sincerely, Dave From: Waltermire, David A. Sent: Monday, September 10, 2012 6:45 PM To: 'stephen.farrell@cs.tcd.ie'; 'turners= @ieca.com'; 'Moriarty, Kathleen' Subject: SACM BoF Request Please find the our request for a WG formation BoF below. I have also incl= uded a draft charter that we have been developing with feedback from the SA= CM list. Please let me know if you have any questions or if you would like= any additional details. Sincerely, Dave Waltermire -- BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from= the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation to verify= system configurations with the ability to prioritize risk based on increas= ed situational awareness from shared intelligence is the key to escaping th= is rut. This working group will develop security automation standards in su= pport of information security processes and practices where practical. Thes= e standards will help security practitioners to be better utilized within t= heir organizations by automating routine tasks related to endpoint and serv= er security so that practitioners can focus on more advanced tasks. The ini= tial focus of this work is to address enterprise use cases. The working group will achieve this by consuming shared intelligence and co= ntinuing (with cooperation) the security automation work already performed = by various organizations around the world. The initial work has been fruit= ful, and the data formats previously published are ready for expansion on t= he international stage. Of particular interest to this working group are th= e security automation specifications supporting asset, change, configuratio= n, and vulnerability management. Of additional interest to this working gro= up are the emerging security automation interfaces and data formats relatin= g to event management and continuous assessment. The continuous assessment= capabilities enable organizational situational awareness through frequent = snapshots of the operating state of their environment, with risk prioritize= d based on consumed information provided by shared intelligence (vulnerabil= ities, threats, etc.). By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories, and enabling interoperability thro= ugh the development and use of standard interfaces and communications proto= cols. Content based on rich data standards and protocols will provide the a= uthoritative instructions needed by data-driven tools to enable the automat= ed collection and exchange of configuration and vulnerability data pertaini= ng to enterprise assets. Information produced by these tools will provide a= ccurate and timely situational awareness in support of organizational decis= ion making. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing and aggregating devi= ce states and comparing these device states against expected values, and re= porting on those results in a predefined or ad hoc manner. This area of fo= cus provides for necessary language and data format specifications. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of= systems, composed of many different types of devices and networks, operate= d by varying personnel, to ensure security process effectiveness in a pre-d= efined or ad-hoc manner. This area of focus provides for integration proto= cols supporting plug and play continuous assessment and security automation= networking. This working group will achieve the following milestones in two phases: Phase One - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability - A Standards Track document specifying a control framework representation = format. - A Standards Track document specifying benchmark configuration representat= ion - An Informational document stating guidelines / requirements for specifyin= g checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other co= ntent defined in this group with the NEA protocols Phase Two - Standards Track document specifying security automation/continuous assess= ment interfaces - A Standards Track document specifying communication protocols used for se= curity automation and continuous assessment - A Standards Track document describing the messages and network protocols = for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems ________________________________ _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Thu Sep 13 11:07:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5455421F8505 for ; Thu, 13 Sep 2012 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803] 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 JfN23sJafr5L for ; Thu, 13 Sep 2012 11:07:37 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5F21F84FA for ; Thu, 13 Sep 2012 11:07:37 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 13 Sep 2012 11:07:36 -0700 From: Michael Hammer To: "mdavidson@mitre.org" , "david.waltermire@nist.gov" , "david.oliva@verizon.net" , "sacm@ietf.org" Thread-Topic: [sacm] FW: SACM BoF Request Thread-Index: AQHNkQIUUd5L9DozTL2wga4UXLDq3peHHZrAgAAhkLCAAU5B0IAABF9A Date: Thu, 13 Sep 2012 18:07:36 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB319DB61AB@ex2k10mb2.corp.yaanatech.com> References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CE_01CD91B9.1EEDF160" MIME-Version: 1.0 Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 18:07:39 -0000 ------=_NextPart_000_00CE_01CD91B9.1EEDF160 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01CD91B9.1EEDF160" ------=_NextPart_001_00CF_01CD91B9.1EEDF160 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All, =20 I have seen a couple mentions of =E2=80=9Cnew to IETF=E2=80=9D, so was = looking for the =E2=80=9CTau of the IETF=E2=80=9D document which is on = this first link: http://www.ietf.org/newcomers.html =20 But note also these as well: =20 http://www.ietf.org/about/process-docs.html =20 http://www.ietf.org/edu/process-oriented-tutorials.html =20 http://tools.ietf.org/ =20 Hope that helps. Mike =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Davidson II, Mark S Sent: Thursday, September 13, 2012 1:49 PM To: Waltermire, David A.; david.oliva@verizon.net; sacm@ietf.org Subject: Re: [sacm] FW: SACM BoF Request =20 Thank you. I=E2=80=99m happy to work with David Oliva on this. =20 What is the proper procedure for drafting the RFC? I=E2=80=99m new to = the IETF, so direction will be beneficial. Also, what would the group = need from a dates/deliverables perspective? =20 If it=E2=80=99s acceptable, I=E2=80=99ll work offline with David O. and = come back to the group at regular intervals as the schedule demands. =20 Thank you. -Mark =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Thursday, September 13, 2012 7:53 AM To: Davidson II, Mark S; david.oliva@verizon.net; sacm@ietf.org Subject: RE: [sacm] FW: SACM BoF Request =20 Mark, =20 That would be great! Thank you for volunteering. =20 Sincerely, Dave =20 From: Davidson II, Mark S [mailto:mdavidson@mitre.org]=20 Sent: Wednesday, September 12, 2012 3:58 PM To: david.oliva@verizon.net; Waltermire, David A.; sacm@ietf.org Subject: RE: [sacm] FW: SACM BoF Request =20 My apologies for the late response, I didn=E2=80=99t get to this email = until just now. =20 As an original author for the ASR spec, I=E2=80=99d like to participate = in bringing ASR to the IETF. Is that a possibility? =20 Thank you. -Mark Davidson =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = david.oliva@verizon.net Sent: Wednesday, September 12, 2012 12:17 PM To: david.waltermire@nist.gov; sacm@ietf.org Subject: Re: [sacm] FW: SACM BoF Request =20 David: =20 I would like to take on ASR (I pressume you are talking about IR 7848 = for future SCAP/SACM versions). =20 Which in fact, brings up a question. =20 In terms of maturity, how do you know which Interagency Reports will be = part of future SACM/SCAP versions? =20 David Oliva =20 =20 On 09/12/12, Waltermire, David A. wrote: =20 I sent in a request to hold a SACM BoF at the IETF 85 meeting in = Atlanta, GA. The details are below for anyone interested. At this = point we need to complete preparations for the BoF. To be successful, = we will need your participation in the BoF and your help getting ready. =20 Here are meeting details if you are interested in making travel = arrangements: =20 http://www.ietf.org/meeting/85/index.html =20 At this point we need additional drafts to be submitted to augment the = agenda and support the BoF. I=E2=80=99d be happy to work with anyone = interested in preparing drafts for any of the existing specifications in = this area (e.g. CPE, Asset Identification, ARF, ASR, etc.) We should = probably do a direct conversion of existing specifications for -00 = versions before making any changes. The -00 deadline for the IETF 85 = meeting is 10/15 with any updated drafts due a week later on 10/22. Any = volunteers?=20 =20 We will also need speakers to present drafts. Please let me or Kathleen = know if you are interested in making a short presentation. =20 We also need to continue to refine the charter (included below) and use = case documents. Any additional comments/changes would be appreciated.=20 =20 Sincerely, Dave =20 From: Waltermire, David A.=20 Sent: Monday, September 10, 2012 6:45 PM To: 'stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moriarty, = Kathleen' Subject: SACM BoF Request =20 Please find the our request for a WG formation BoF below. I have also = included a draft charter that we have been developing with feedback from = the SACM list. Please let me know if you have any questions or if you = would like any additional details. =20 Sincerely, Dave Waltermire =20 -- =20 BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: =20 * Review the draft charter * Review draft-waltermire-sacm-use-cases-02=20 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline =20 Full Description of BOF: The SACM BoF is intended to progress the work = from the SACM mailing list to solidify discussions on a proposed = charter, use cases and milestones in support of moving to an IETF = working group. =20 CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours =20 Draft Charter: =20 Proposed Working Group Charter =20 Chairs: TBD TBD =20 Security Area Directors: Stephen Farrell Sean Turner =20 Security Area Advisor: Sean Turner =20 Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm =20 Description of Working Group =20 Securing information and the systems that store, process, and transmit = that information has become a challenging task for organizations of all = sizes, and we find that security practitioners spend most of their time = on manual processes relegating them to ineffectiveness. Security = automation to verify system configurations with the ability to = prioritize risk based on increased situational awareness from shared = intelligence is the key to escaping this rut. This working group will = develop security automation standards in support of information security = processes and practices where practical. These standards will help = security practitioners to be better utilized within their organizations = by automating routine tasks related to endpoint and server security so = that practitioners can focus on more advanced tasks. The initial focus = of this work is to address enterprise use cases.=20 =20 The working group will achieve this by consuming shared intelligence and = continuing (with cooperation) the security automation work already = performed by various organizations around the world. The initial work = has been fruitful, and the data formats previously published are ready = for expansion on the international stage. Of particular interest to this = working group are the security automation specifications supporting = asset, change, configuration, and vulnerability management. Of = additional interest to this working group are the emerging security = automation interfaces and data formats relating to event management and = continuous assessment. The continuous assessment capabilities enable = organizational situational awareness through frequent snapshots of the = operating state of their environment, with risk prioritized based on = consumed information provided by shared intelligence (vulnerabilities, = threats, etc.). =20 By undertaking this work, we recognize that there are multiple = categories of problems in the security automation domain: defining = expressions for particular domain concepts (i.e. data formats), = establishing a standards-based foundation supporting the curation and = exchange of security automation content collections in content = repositories, and enabling interoperability through the development and = use of standard interfaces and communications protocols. Content based = on rich data standards and protocols will provide the authoritative = instructions needed by data-driven tools to enable the automated = collection and exchange of configuration and vulnerability data = pertaining to enterprise assets. Information produced by these tools = will provide accurate and timely situational awareness in support of = organizational decision making.=20 =20 This working group will provide solutions to these categories of = problems and the main areas of focus for this working group are = described as follows: =20 1. Define, either by normative reference, adoption, or creation, a set = of standards that can be used for the purpose of assessing and = aggregating device states and comparing these device states against = expected values, and reporting on those results in a predefined or ad = hoc manner. This area of focus provides for necessary language and data = format specifications. =20 2. Define, either by normative reference, adoption, or creation, a set = of standards that can be used to continuously assess and report on the = state of systems, composed of many different types of devices and = networks, operated by varying personnel, to ensure security process = effectiveness in a pre-defined or ad-hoc manner. This area of focus = provides for integration protocols supporting plug and play continuous = assessment and security automation networking. =20 This working group will achieve the following milestones in two phases: =20 Phase One - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability - A Standards Track document specifying a control framework = representation format. - A Standards Track document specifying benchmark configuration = representation - An Informational document stating guidelines / requirements for = specifying checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking = language=20 - A Standards Track document specifying asset reporting information=20 - Standards Track document describing how to use the languages and other = content defined in this group with the NEA protocols =20 Phase Two - Standards Track document specifying security automation/continuous = assessment interfaces - A Standards Track document specifying communication protocols used for = security automation and continuous assessment - A Standards Track document describing the messages and network = protocols for distributing security automation content (content = repository) - A Standards Track document describing protocols and data formats for = securely sharing dynamic network state information among security = systems =20 =20 _____ =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_001_00CF_01CD91B9.1EEDF160 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

All,

 

I have seen a couple mentions of =E2=80=9Cnew to IETF=E2=80=9D, so = was looking for the =E2=80=9CTau of the IETF=E2=80=9D document which is = on this first link:

http://www.ietf.org/newcomers= .html

 

But note also these as well:

 

http://www.ietf.org/= about/process-docs.html

 

http://w= ww.ietf.org/edu/process-oriented-tutorials.html

=

 

http://tools.ietf.org/

 

Hope that helps.

Mike

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Davidson II, Mark S
Sent: Thursday, September 13, 2012 = 1:49 PM
To: Waltermire, David A.; david.oliva@verizon.net; = sacm@ietf.org
Subject: Re: [sacm] FW: SACM BoF = Request

 

Thank you. I=E2=80=99m happy to work with David Oliva on = this.

 

What is the proper procedure for drafting the RFC? I=E2=80=99m new to = the IETF, so direction will be beneficial. Also, what would the group = need from a dates/deliverables perspective?

 

If it=E2=80=99s acceptable, I=E2=80=99ll work offline with David O. = and come back to the group at regular intervals as the schedule = demands.

 

Thank you.

-Mark

 

From:= = Waltermire, David A. [mailto:david.waltermi= re@nist.gov]
Sent: Thursday, September 13, 2012 7:53 = AM
To: Davidson II, Mark S; david.oliva@verizon.net; sacm@ietf.org
Subject: RE: = [sacm] FW: SACM BoF Request

 

Mark,

 

That would be great!  Thank you for = volunteering.

 

Sincerely,

Dave

 

From:= = Davidson II, Mark S [mailto:mdavidson@mitre.org]=
Sent: Wednesday, September 12, 2012 3:58 = PM
To: david.oliva@verizon.net; = Waltermire, David A.; sacm@ietf.org
Subject: RE: = [sacm] FW: SACM BoF Request

 

My apologies for the late response, I didn=E2=80=99t get to this = email until just now.

 

As an original author for the ASR spec, I=E2=80=99d like to = participate in bringing ASR to the IETF. Is that a = possibility?

 

Thank you.

-Mark Davidson

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of david.oliva@verizon.net
Sent: Wednesday, September 12, 2012 12:17 PM
To: david.waltermire@nist.gov; = sacm@ietf.org
Subject: = Re: [sacm] FW: SACM BoF Request

 

&n= bsp;David:

&n= bsp;

I = would like to take on ASR (I pressume you are talking about IR 7848 for = future SCAP/SACM versions).

&n= bsp;

Wh= ich in fact, brings up a question.

&n= bsp;

In= terms of maturity, how do you know which Interagency Reports will be = part of future SACM/SCAP versions?

&n= bsp;

Da= vid Oliva

&n= bsp;

&n= bsp;

On= 09/12/12, Waltermire, David A.<david.waltermire@nist.gov&g= t; wrote:

&n= bsp;

I sent in a request to hold a SACM = BoF at the IETF 85 meeting in Atlanta, GA.  The details are below = for anyone interested.  At this point we need to complete = preparations for the BoF.  To be successful, we will need your = participation in the BoF and your help getting ready.

 

Here are meeting details if you are = interested in making travel arrangements:

 

http://www.ietf.org/meeting/85/index.html

 

At this point we need additional = drafts to be submitted to augment the agenda and support the BoF.  = I=E2=80=99d be happy to work with anyone interested in preparing drafts = for any of the existing specifications in this area (e.g. CPE, Asset = Identification, ARF, ASR, etc.)  We should probably do a direct = conversion of existing specifications for -00 versions before making any = changes.  The -00 deadline for the IETF 85 meeting is 10/15 with = any updated drafts due a week later on 10/22.  Any volunteers? =

 

We will also need speakers to = present drafts.  Please let me or Kathleen know if you are = interested in making a short presentation.

 

We also need to continue to refine = the charter (included below) and use case documents. Any additional = comments/changes would be appreciated.

 

Sincerely,

Dave

 

= From:= Waltermire, David A.
Sent: Monday, September 10, 2012 6:45 = PM
To: 'stephen.farrell@cs.tcd.ie'; 'turners@ieca.com'; 'Moriarty, = Kathleen'
Subject: SACM BoF Request

 

Please find the our request for a WG = formation BoF below.  I have also included a draft charter that we = have been developing with feedback from the SACM list.  Please let = me know if you have any questions or if you would like any additional = details.

 

Sincerely,

Dave = Waltermire

 

--

 

BOF full name: Security Automation and = Continuous Monitoring [SACM]

AREA: Security

BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com)

        &nb= sp;   David Waltermire (david.waltermire@nist.gov)

Agenda:

 

* Review the draft = charter

* Review = draft-waltermire-sacm-use-cases-02

* Review drafts submitted in support = of the charter

  - = draft-waltermire-content-repository-00

  - More expected before -00 = deadline

 

Full Description of BOF: The SACM BoF = is intended to progress the work from the SACM mailing list to solidify = discussions on a proposed charter, use cases and milestones in support = of moving to an IETF working group.

 

CONFLICTS to avoid: SAAG, = MILE

Expected Attendance: 40, not sure what = the previous attendance was?

Special Requests: Meetecho = support

Number of sessions: = 1

Length of session: 2 = hours

 

Draft Charter:

 

Proposed Working Group = Charter

 

Chairs:

TBD

TBD

 

Security Area = Directors:

     Stephen = Farrell <stephen.farrell@cs.tcd.ie>

=

     Sean Turner = <turners@ieca.com>

 

Security Area = Advisor:

     Sean Turner = <turners@ieca.com>

 

Mailing Lists:

     General = Discussion: sacm@ietf.org

     To = Subscribe:       http://www.ietf.org/mailman/listinfo/sacm

     = Archive:           = ; http://www.ietf.org/mail-archive/web/sacm

 

Description of Working = Group

 

Securing information and the systems = that store, process, and transmit that information has become a = challenging task for organizations of all sizes, and we find that = security practitioners spend most of their time on manual processes = relegating them to ineffectiveness. Security automation to verify system = configurations with the ability to prioritize risk based on increased = situational awareness from shared intelligence is the key to escaping = this rut. This working group will develop security automation standards = in support of information security processes and practices where = practical. These standards will help security practitioners to be better = utilized within their organizations by automating routine tasks related = to endpoint and server security so that practitioners can focus on more = advanced tasks. The initial focus of this work is to address enterprise = use cases.

 

The working group will achieve this by = consuming shared intelligence and continuing (with cooperation) the = security automation work already performed by various organizations = around the world.  The initial work has been fruitful, and the data = formats previously published are ready for expansion on the = international stage. Of particular interest to this working group are = the security automation specifications supporting asset, change, = configuration, and vulnerability management. Of additional interest to = this working group are the emerging security automation interfaces and = data formats relating to event management and continuous = assessment.  The continuous assessment capabilities enable = organizational situational awareness through frequent snapshots of the = operating state of their environment, with risk prioritized based on = consumed information provided by shared intelligence (vulnerabilities, = threats, etc.).

 

By undertaking this work, we recognize = that there are multiple categories of problems in the security = automation domain: defining expressions for particular domain concepts = (i.e. data formats), establishing a standards-based foundation = supporting the curation and exchange of security automation content = collections in content repositories, and enabling interoperability = through the development and use of standard interfaces and = communications protocols. Content based on rich data standards and = protocols will provide the authoritative instructions needed by = data-driven tools to enable the automated collection and exchange of = configuration and vulnerability data pertaining to enterprise assets. = Information produced by these tools will provide accurate and timely = situational awareness in support of organizational decision making. =

 

This working group will provide = solutions to these categories of problems and the main areas of focus = for this working group are described as follows:

 

1. Define, either by normative = reference, adoption, or creation, a set of standards that can be used = for the purpose of assessing and aggregating device states and comparing = these device states against expected values, and reporting on those = results in a predefined or ad hoc manner.  This area of focus = provides for necessary language and data format = specifications.

 

2. Define, either by normative = reference, adoption, or creation, a set of standards that can be used to = continuously assess and report on the state of systems, composed of many = different types of devices and networks, operated by varying personnel, = to ensure security process effectiveness in a pre-defined or ad-hoc = manner.  This area of focus provides for integration protocols = supporting plug and play continuous assessment and security automation = networking.

 

This working group will achieve the = following milestones in two phases:

 

Phase One

- A Standards Track document = specifying asset description format

- A Standards Track document = specifying asset identification

- A Standards Track document = specifying platform naming

- A Standards Track document = specifying platform matching

- A Standards Track document = specifying platform applicability

- A Standards Track document = specifying a control framework representation = format.

- A Standards Track document = specifying benchmark configuration = representation

- An Informational document stating = guidelines / requirements for specifying checking = languages

- Standards Track documents specifying = device state checking languages

- A Standards Track document = specifying an interrogative checking language

- A Standards Track document = specifying asset reporting information

- Standards Track document describing = how to use the languages and other content defined in this group with = the NEA protocols

 

Phase Two

- Standards Track document specifying = security automation/continuous assessment = interfaces

- A Standards Track document = specifying communication protocols used for security automation and = continuous assessment

- A Standards Track document = describing the messages and network protocols for distributing security = automation content  (content repository)

- A Standards Track document = describing protocols and data formats for securely sharing dynamic = network state information among security systems

 

 

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

------=_NextPart_001_00CF_01CD91B9.1EEDF160-- ------=_NextPart_000_00CE_01CD91B9.1EEDF160 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkx MzE4MDczM1owIwYJKoZIhvcNAQkEMRYEFO5YOgYzh3pl+zGmOMHERI+hEUeuMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAs8LHiY5qJeu+SDM9s0Baeo+/piTQ0ct/Ib/WtchwwTV2 HQnAh+h2+DRUhBDc9c5zWGKfH0uZwOk9yiDWb3V9ISnDqzWeX13juhaBlypg5GM+bqAbzyhaI33w qKo7lmW3yFZWLhFFFQuXN5i7ov/9dYTyrEwjnV++7JvFrt/JvTEAAAAAAAA= ------=_NextPart_000_00CE_01CD91B9.1EEDF160-- From kathleen.moriarty@emc.com Fri Sep 21 13:33:48 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AFF21F8619 for ; Fri, 21 Sep 2012 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, LONGWORDS=1.803] 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 5cOEeeNbk3mw for ; Fri, 21 Sep 2012 13:33:47 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3912921F8602 for ; Fri, 21 Sep 2012 13:33:46 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8LKXku2006236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2012 16:33:46 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 21 Sep 2012 16:33:33 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8LKXXuZ022353; Fri, 21 Sep 2012 16:33:33 -0400 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Sep 2012 16:33:33 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Fri, 21 Sep 2012 16:33:32 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , "sacm@ietf.org" Date: Fri, 21 Sep 2012 16:31:38 -0400 Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4= Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 20:33:48 -0000 Hello, I am including an updated version of the SACM Charter that includes more of= an emphasis on the protocols to share and exchange data within and between= enterprises/organizations. Please feel free to provide feedback to the li= st! Thanks & have a good weekend! Kathleen BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from= the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation to verify= system configurations with the ability to prioritize risk based on increas= ed situational awareness from shared intelligence is the key to escaping th= is rut. This working group will develop security automation protocols and d= ata format standards in support of information security processes and pract= ices where practical. These standards will help security practitioners to b= e better utilized within their organizations by automating routine tasks re= lated to endpoint and server security so that practitioners can focus on mo= re advanced tasks. The initial focus of this work is to address enterprise = use cases. The working group will achieve this by enabling the exchange of shared inte= lligence and continuing the security automation work already performed by v= arious organizations around the world. The initial work has been fruitful,= and the data formats previously published are ready for expansion on the i= nternational stage. Of particular interest to this working group are the se= curity automation specifications supporting asset, change, configuration, a= nd vulnerability management. Of additional interest to this working group a= re the emerging security automation interfaces and data formats relating to= event management and continuous assessment. The continuous assessment cap= abilities enable organizational situational awareness through frequent snap= shots of the operating state of their environment, with risk prioritized ba= sed on consumed information provided by shared intelligence (vulnerabilitie= s, threats, etc.). By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: enabling interoperable data e= xchanges through standardized protocols, defining expressions for particula= r domain concepts (i.e. data formats), establishing a standards-based found= ation supporting the curation and exchange of security automation content c= ollections in content repositories, and enabling interoperability through t= he development and use of standard interfaces and communications protocols.= Content based on rich data standards and protocols will provide the author= itative instructions needed by data-driven tools to enable the automated co= llection and exchange of configuration and vulnerability data pertaining to= enterprise assets. Information produced by these tools will provide accura= te and timely situational awareness in support of organizational decision m= aking. The data exchange protocols will need to meet several exchange types includ= ing those between and within organizations for sharing intelligence data to= increase situational awareness, report exchanges both internal and externa= l to an enterprise, and those between enterprise servers and end points for= assessments This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards to enable the exchange of data to increase situational awareness o= r gain access to shared content to improve the security posture of an enter= prise. This area of focus provides for the integration of interoperable pr= otocols to access shared data repositories between organizations to increas= e situational awareness and reduce risks to an enterprise. In support of a= ccessing shared intelligence for expected system state and related risks, d= efine, either by normative reference, adoption, or creation, a set of stand= ards that can be used for the purpose of assessing and aggregating device s= tates and comparing these device states against expected values, and report= ing on those results in a predefined or ad hoc manner. This area of focus = provides for necessary language and data format specifications. 3. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of= systems, composed of many different types of devices and networks, operate= d by varying personnel, to ensure security process effectiveness in a pre-d= efined or ad-hoc manner. This area of focus provides for integration proto= cols supporting plug and play continuous assessment and security automation= networking within an enterprise. This working group will achieve the following milestones in two phases: Phase One - A standards track document to define a protocol for interacting with cont= ent repositories - Standards Track document specifying security automation/continuous assess= ment interfaces - A Standards Track document specifying communication protocols used for se= curity automation and continuous assessment - A Standards Track document describing the messages and network protocols = for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification - A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability Phase Two - A Standards Track document specifying a control framework representation = format. - A Standards Track document specifying benchmark configuration representat= ion - An Informational document stating guidelines / requirements for specifyin= g checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other co= ntent defined in this group with the NEA protocols From bakerj@mitre.org Sun Sep 23 02:51:28 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FC421F84CF for ; Sun, 23 Sep 2012 02:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kqJoEnfE9yo for ; Sun, 23 Sep 2012 02:51:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F29B621F84CE for ; Sun, 23 Sep 2012 02:51:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CCC3121B10E4; Sun, 23 Sep 2012 05:51:25 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BE54321B10E3; Sun, 23 Sep 2012 05:51:25 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.001; Sun, 23 Sep 2012 05:51:25 -0400 From: "Baker, Jon" To: "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4AThqt4A== Date: Sun, 23 Sep 2012 09:51:25 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 09:51:28 -0000 >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Why the shift in emphasis to sharing and exchanging data between organizati= ons? This seems to be new to this group. Also in the section that lists the focus areas it looks like you intended f= or there to be three focus areas but accidently merged the second focus are= a into the first. Your wording in the first focus area appears to start des= cribing a new focus area and your number goes from 1 to 3 skipping number 2= . Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Moriarty, Kathleen >Sent: Friday, September 21, 2012 4:32 PM >To: Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Hello, > >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Please feel free to provide feedback to the li= st! > >Thanks & have a good weekend! >Kathleen > > > >BOF full name: Security Automation and Continuous Monitoring [SACM] >AREA: Security >BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) >Agenda: > >* Review the draft charter >* Review draft-waltermire-sacm-use-cases-02 >* Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > >Full Description of BOF: The SACM BoF is intended to progress the work fro= m >the SACM mailing list to solidify discussions on a proposed charter, use c= ases >and milestones in support of moving to an IETF working group. > >CONFLICTS to avoid: SAAG, MILE >Expected Attendance: 40, not sure what the previous attendance was? >Special Requests: Meetecho support >Number of sessions: 1 >Length of session: 2 hours > >Draft Charter: > >Proposed Working Group Charter > >Chairs: >TBD >TBD > >Security Area Directors: > Stephen Farrell > Sean Turner > >Security Area Advisor: > Sean Turner > >Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > >Description of Working Group > >Securing information and the systems that store, process, and transmit tha= t >information has become a challenging task for organizations of all sizes, = and >we find that security practitioners spend most of their time on manual >processes relegating them to ineffectiveness. Security automation to verif= y >system configurations with the ability to prioritize risk based on increas= ed >situational awareness from shared intelligence is the key to escaping this= rut. >This working group will develop security automation protocols and data >format standards in support of information security processes and practice= s >where practical. These standards will help security practitioners to be be= tter >utilized within their organizations by automating routine tasks related to >endpoint and server security so that practitioners can focus on more >advanced tasks. The initial focus of this work is to address enterprise us= e >cases. > >The working group will achieve this by enabling the exchange of shared >intelligence and continuing the security automation work already performed >by various organizations around the world. The initial work has been frui= tful, >and the data formats previously published are ready for expansion on the >international stage. Of particular interest to this working group are the >security automation specifications supporting asset, change, configuration= , >and vulnerability management. Of additional interest to this working group >are the emerging security automation interfaces and data formats relating = to >event management and continuous assessment. The continuous assessment >capabilities enable organizational situational awareness through frequent >snapshots of the operating state of their environment, with risk prioritiz= ed >based on consumed information provided by shared intelligence >(vulnerabilities, threats, etc.). > >By undertaking this work, we recognize that there are multiple categories = of >problems in the security automation domain: enabling interoperable data >exchanges through standardized protocols, defining expressions for particu= lar >domain concepts (i.e. data formats), establishing a standards-based >foundation supporting the curation and exchange of security automation >content collections in content repositories, and enabling interoperability >through the development and use of standard interfaces and communications >protocols. Content based on rich data standards and protocols will provide= the >authoritative instructions needed by data-driven tools to enable the >automated collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in support of organizati= onal >decision making. > >The data exchange protocols will need to meet several exchange types >including those between and within organizations for sharing intelligence = data >to increase situational awareness, report exchanges both internal and >external to an enterprise, and those between enterprise servers and end >points for assessments > >This working group will provide solutions to these categories of problems = and >the main areas of focus for this working group are described as follows: > >1. Define, either by normative reference, adoption, or creation, a set of >standards to enable the exchange of data to increase situational awareness= or >gain access to shared content to improve the security posture of an >enterprise. This area of focus provides for the integration of interopera= ble >protocols to access shared data repositories between organizations to >increase situational awareness and reduce risks to an enterprise. In supp= ort >of accessing shared intelligence for expected system state and related ris= ks, >define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing and aggregating >device states and comparing these device states against expected values, a= nd >reporting on those results in a predefined or ad hoc manner. This area of >focus provides for necessary language and data format specifications. > >3. Define, either by normative reference, adoption, or creation, a set of >standards that can be used to continuously assess and report on the state = of >systems, composed of many different types of devices and networks, >operated by varying personnel, to ensure security process effectiveness in= a >pre-defined or ad-hoc manner. This area of focus provides for integration >protocols supporting plug and play continuous assessment and security >automation networking within an enterprise. > >This working group will achieve the following milestones in two phases: > >Phase One >- A standards track document to define a protocol for interacting with con= tent >repositories >- Standards Track document specifying security automation/continuous >assessment interfaces >- A Standards Track document specifying communication protocols used for >security automation and continuous assessment >- A Standards Track document describing the messages and network protocols >for distributing security automation content (content repository) >- A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >- A Standards Track document specifying asset description format >- A Standards Track document specifying asset identification >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability > >Phase Two >- A Standards Track document specifying a control framework representation >format. >- A Standards Track document specifying benchmark configuration >representation >- An Informational document stating guidelines / requirements for specifyi= ng >checking languages >- Standards Track documents specifying device state checking languages >- A Standards Track document specifying an interrogative checking language >- A Standards Track document specifying asset reporting information >- Standards Track document describing how to use the languages and other >content defined in this group with the NEA protocols >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From bakerj@mitre.org Sun Sep 23 02:58:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF521F846B for ; Sun, 23 Sep 2012 02:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKtZzCKMFJuX for ; Sun, 23 Sep 2012 02:58:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 64A1A21F845D for ; Sun, 23 Sep 2012 02:58:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C2D1621B10F0; Sun, 23 Sep 2012 05:58:34 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B131A21B10EE; Sun, 23 Sep 2012 05:58:34 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.001; Sun, 23 Sep 2012 05:58:34 -0400 From: "Baker, Jon" To: "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4A== Date: Sun, 23 Sep 2012 09:58:33 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 09:58:38 -0000 Also, I noticed the following: >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicabilit= y Language. Has the group considered the SWID specification (ISO/IEC 19770-= 2). The following page and its referenced document may be of help in consid= ering how cpe and swids fit together: http://tagvault.org/Automating_CPE_name_creation Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Moriarty, Kathleen >Sent: Friday, September 21, 2012 4:32 PM >To: Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Hello, > >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Please feel free to provide feedback to the li= st! > >Thanks & have a good weekend! >Kathleen > > > >BOF full name: Security Automation and Continuous Monitoring [SACM] >AREA: Security >BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) >Agenda: > >* Review the draft charter >* Review draft-waltermire-sacm-use-cases-02 >* Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > >Full Description of BOF: The SACM BoF is intended to progress the work fro= m >the SACM mailing list to solidify discussions on a proposed charter, use c= ases >and milestones in support of moving to an IETF working group. > >CONFLICTS to avoid: SAAG, MILE >Expected Attendance: 40, not sure what the previous attendance was? >Special Requests: Meetecho support >Number of sessions: 1 >Length of session: 2 hours > >Draft Charter: > >Proposed Working Group Charter > >Chairs: >TBD >TBD > >Security Area Directors: > Stephen Farrell > Sean Turner > >Security Area Advisor: > Sean Turner > >Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > >Description of Working Group > >Securing information and the systems that store, process, and transmit tha= t >information has become a challenging task for organizations of all sizes, = and >we find that security practitioners spend most of their time on manual >processes relegating them to ineffectiveness. Security automation to verif= y >system configurations with the ability to prioritize risk based on increas= ed >situational awareness from shared intelligence is the key to escaping this= rut. >This working group will develop security automation protocols and data >format standards in support of information security processes and practice= s >where practical. These standards will help security practitioners to be be= tter >utilized within their organizations by automating routine tasks related to >endpoint and server security so that practitioners can focus on more >advanced tasks. The initial focus of this work is to address enterprise us= e >cases. > >The working group will achieve this by enabling the exchange of shared >intelligence and continuing the security automation work already performed >by various organizations around the world. The initial work has been frui= tful, >and the data formats previously published are ready for expansion on the >international stage. Of particular interest to this working group are the >security automation specifications supporting asset, change, configuration= , >and vulnerability management. Of additional interest to this working group >are the emerging security automation interfaces and data formats relating = to >event management and continuous assessment. The continuous assessment >capabilities enable organizational situational awareness through frequent >snapshots of the operating state of their environment, with risk prioritiz= ed >based on consumed information provided by shared intelligence >(vulnerabilities, threats, etc.). > >By undertaking this work, we recognize that there are multiple categories = of >problems in the security automation domain: enabling interoperable data >exchanges through standardized protocols, defining expressions for particu= lar >domain concepts (i.e. data formats), establishing a standards-based >foundation supporting the curation and exchange of security automation >content collections in content repositories, and enabling interoperability >through the development and use of standard interfaces and communications >protocols. Content based on rich data standards and protocols will provide= the >authoritative instructions needed by data-driven tools to enable the >automated collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in support of organizati= onal >decision making. > >The data exchange protocols will need to meet several exchange types >including those between and within organizations for sharing intelligence = data >to increase situational awareness, report exchanges both internal and >external to an enterprise, and those between enterprise servers and end >points for assessments > >This working group will provide solutions to these categories of problems = and >the main areas of focus for this working group are described as follows: > >1. Define, either by normative reference, adoption, or creation, a set of >standards to enable the exchange of data to increase situational awareness= or >gain access to shared content to improve the security posture of an >enterprise. This area of focus provides for the integration of interopera= ble >protocols to access shared data repositories between organizations to >increase situational awareness and reduce risks to an enterprise. In supp= ort >of accessing shared intelligence for expected system state and related ris= ks, >define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing and aggregating >device states and comparing these device states against expected values, a= nd >reporting on those results in a predefined or ad hoc manner. This area of >focus provides for necessary language and data format specifications. > >3. Define, either by normative reference, adoption, or creation, a set of >standards that can be used to continuously assess and report on the state = of >systems, composed of many different types of devices and networks, >operated by varying personnel, to ensure security process effectiveness in= a >pre-defined or ad-hoc manner. This area of focus provides for integration >protocols supporting plug and play continuous assessment and security >automation networking within an enterprise. > >This working group will achieve the following milestones in two phases: > >Phase One >- A standards track document to define a protocol for interacting with con= tent >repositories >- Standards Track document specifying security automation/continuous >assessment interfaces >- A Standards Track document specifying communication protocols used for >security automation and continuous assessment >- A Standards Track document describing the messages and network protocols >for distributing security automation content (content repository) >- A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >- A Standards Track document specifying asset description format >- A Standards Track document specifying asset identification >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability > >Phase Two >- A Standards Track document specifying a control framework representation >format. >- A Standards Track document specifying benchmark configuration >representation >- An Informational document stating guidelines / requirements for specifyi= ng >checking languages >- Standards Track documents specifying device state checking languages >- A Standards Track document specifying an interrogative checking language >- A Standards Track document specifying asset reporting information >- Standards Track document describing how to use the languages and other >content defined in this group with the NEA protocols >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Sun Sep 23 08:13:02 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AB521F84EA for ; Sun, 23 Sep 2012 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, LONGWORDS=1.803] 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 sH48OZh3sPpY for ; Sun, 23 Sep 2012 08:13:01 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58D21F84E4 for ; Sun, 23 Sep 2012 08:13:00 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8NFCm2h031161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2012 11:12:58 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 23 Sep 2012 11:12:41 -0400 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 q8NFCedB013037; Sun, 23 Sep 2012 11:12:40 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Sun, 23 Sep 2012 11:12:40 -0400 From: "Moriarty, Kathleen" To: "Baker, Jon" , "Waltermire, David A." , "sacm@ietf.org" Date: Sun, 23 Sep 2012 11:12:38 -0400 Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4AThqt4AAKyOnw Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 15:13:02 -0000 Hi Jon, Thank you for your comments! The data formats enable communication between= entities, but without common protocols, we will miss the opportunity to cr= eate interoperability between vendor products. We do want to enable intell= igence feeds and common reporting methods, even if it is to point to other = efforts like GRC Exchange. The repository work could benefit from common a= ccess methods to address one of the additions. The IETF is good at protoco= ls and the SACM community is good at data formats to enable automated secur= ity. In bringing these groups together, we should try to take advantage of = the expertise of the IETF to more fully solve the problem space. As I foun= d out with RFC6545, people will point out things needed for interoperabilit= y for which others deep in a problem space may not be aware. Thanks for the catch on two versus three, just trying to make sure people a= re reading ;-) LOL A corrected version is listed below, with the exception of how to deal with= the platform naming. In either case, whatever we select will likely be by= reference (SWID or CPE). I like the SWID approach, but we'll need more di= scussion on that. BOF full name: Security Automation and Continuous Monitoring [SACM] AREA: Security BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) David Waltermire (david.waltermire@nist.gov) Agenda: * Review the draft charter * Review draft-waltermire-sacm-use-cases-02 * Review drafts submitted in support of the charter - draft-waltermire-content-repository-00 - More expected before -00 deadline Full Description of BOF: The SACM BoF is intended to progress the work from= the SACM mailing list to solidify discussions on a proposed charter, use c= ases and milestones in support of moving to an IETF working group. CONFLICTS to avoid: SAAG, MILE Expected Attendance: 40, not sure what the previous attendance was? Special Requests: Meetecho support Number of sessions: 1 Length of session: 2 hours Draft Charter: Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation to verify= system configurations with the ability to prioritize risk based on increas= ed situational awareness from shared intelligence is the key to escaping th= is rut. This working group will develop security automation protocols and d= ata format standards in support of information security processes and pract= ices where practical. These standards will help security practitioners to b= e better utilized within their organizations by automating routine tasks re= lated to endpoint and server security so that practitioners can focus on mo= re advanced tasks. The initial focus of this work is to address enterprise = use cases. The working group will achieve this by enabling the exchange of shared inte= lligence and continuing the security automation work already performed by v= arious organizations around the world. The initial work has been fruitful,= and the data formats previously published are ready for expansion on the i= nternational stage. Of particular interest to this working group are the se= curity automation specifications supporting asset, change, configuration, a= nd vulnerability management. Of additional interest to this working group a= re the emerging security automation interfaces and data formats relating to= event management and continuous assessment. The continuous assessment cap= abilities enable organizational situational awareness through frequent snap= shots of the operating state of their environment, with risk prioritized ba= sed on consumed information provided by shared intelligence (vulnerabilitie= s, threats, etc.). By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: enabling interoperable data e= xchanges through standardized protocols, defining expressions for particula= r domain concepts (i.e. data formats), establishing a standards-based found= ation supporting the curation and exchange of security automation content c= ollections in content repositories, and enabling interoperability through t= he development and use of standard interfaces and communications protocols.= Content based on rich data standards and protocols will provide the author= itative instructions needed by data-driven tools to enable the automated co= llection and exchange of configuration and vulnerability data pertaining to= enterprise assets. Information produced by these tools will provide accura= te and timely situational awareness in support of organizational decision m= aking. The data exchange protocols will need to meet several exchange types includ= ing those between and within organizations for sharing intelligence data to= increase situational awareness, report exchanges both internal and externa= l to an enterprise, and those between enterprise servers and end points for= assessments This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards to enable the exchange of data to increase situational awareness o= r gain access to shared content to improve the security posture of an enter= prise. This area of focus provides for the integration of interoperable pr= otocols to access shared data repositories between organizations to increas= e situational awareness and reduce risks to an enterprise. In support of a= ccessing shared intelligence for expected system state and related risks, d= efine, either by normative reference, adoption, or creation, a set of stand= ards that can be used for the purpose of assessing and aggregating device s= tates and comparing these device states against expected values, and report= ing on those results in a predefined or ad hoc manner. This area of focus = provides for necessary language and data format specifications. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously assess and report on the state of= systems, composed of many different types of devices and networks, operate= d by varying personnel, to ensure security process effectiveness in a pre-d= efined or ad-hoc manner. This area of focus provides for integration proto= cols supporting plug and play continuous assessment and security automation= networking within an enterprise. This working group will achieve the following milestones in two phases: Phase One - A standards track document to define a protocol for interacting with cont= ent repositories - Standards Track document specifying security automation/continuous assess= ment interfaces - A Standards Track document specifying communication protocols used for se= curity automation and continuous assessment - A Standards Track document describing the messages and network protocols = for distributing security automation content (content repository) - A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems - A Standards Track document specifying asset description format - A Standards Track document specifying asset identification [- A Standards Track document specifying platform naming - A Standards Track document specifying platform matching - A Standards Track document specifying platform applicability] Phase Two - A Standards Track document specifying a control framework representation = format. - A Standards Track document specifying benchmark configuration representat= ion - An Informational document stating guidelines / requirements for specifyin= g checking languages - Standards Track documents specifying device state checking languages - A Standards Track document specifying an interrogative checking language - A Standards Track document specifying asset reporting information - Standards Track document describing how to use the languages and other co= ntent defined in this group with the NEA protocols Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Bak= er, Jon Sent: Sunday, September 23, 2012 5:51 AM To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] SACM BoF Request >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Why the shift in emphasis to sharing and exchanging data between organizati= ons? This seems to be new to this group. Also in the section that lists the focus areas it looks like you intended f= or there to be three focus areas but accidently merged the second focus are= a into the first. Your wording in the first focus area appears to start des= cribing a new focus area and your number goes from 1 to 3 skipping number 2= . Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Moriarty, Kathleen >Sent: Friday, September 21, 2012 4:32 PM >To: Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Hello, > >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Please feel free to provide feedback to the li= st! > >Thanks & have a good weekend! >Kathleen > > > >BOF full name: Security Automation and Continuous Monitoring [SACM] >AREA: Security >BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) >Agenda: > >* Review the draft charter >* Review draft-waltermire-sacm-use-cases-02 >* Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > >Full Description of BOF: The SACM BoF is intended to progress the work fro= m >the SACM mailing list to solidify discussions on a proposed charter, use c= ases >and milestones in support of moving to an IETF working group. > >CONFLICTS to avoid: SAAG, MILE >Expected Attendance: 40, not sure what the previous attendance was? >Special Requests: Meetecho support >Number of sessions: 1 >Length of session: 2 hours > >Draft Charter: > >Proposed Working Group Charter > >Chairs: >TBD >TBD > >Security Area Directors: > Stephen Farrell > Sean Turner > >Security Area Advisor: > Sean Turner > >Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > >Description of Working Group > >Securing information and the systems that store, process, and transmit tha= t >information has become a challenging task for organizations of all sizes, = and >we find that security practitioners spend most of their time on manual >processes relegating them to ineffectiveness. Security automation to verif= y >system configurations with the ability to prioritize risk based on increas= ed >situational awareness from shared intelligence is the key to escaping this= rut. >This working group will develop security automation protocols and data >format standards in support of information security processes and practice= s >where practical. These standards will help security practitioners to be be= tter >utilized within their organizations by automating routine tasks related to >endpoint and server security so that practitioners can focus on more >advanced tasks. The initial focus of this work is to address enterprise us= e >cases. > >The working group will achieve this by enabling the exchange of shared >intelligence and continuing the security automation work already performed >by various organizations around the world. The initial work has been frui= tful, >and the data formats previously published are ready for expansion on the >international stage. Of particular interest to this working group are the >security automation specifications supporting asset, change, configuration= , >and vulnerability management. Of additional interest to this working group >are the emerging security automation interfaces and data formats relating = to >event management and continuous assessment. The continuous assessment >capabilities enable organizational situational awareness through frequent >snapshots of the operating state of their environment, with risk prioritiz= ed >based on consumed information provided by shared intelligence >(vulnerabilities, threats, etc.). > >By undertaking this work, we recognize that there are multiple categories = of >problems in the security automation domain: enabling interoperable data >exchanges through standardized protocols, defining expressions for particu= lar >domain concepts (i.e. data formats), establishing a standards-based >foundation supporting the curation and exchange of security automation >content collections in content repositories, and enabling interoperability >through the development and use of standard interfaces and communications >protocols. Content based on rich data standards and protocols will provide= the >authoritative instructions needed by data-driven tools to enable the >automated collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in support of organizati= onal >decision making. > >The data exchange protocols will need to meet several exchange types >including those between and within organizations for sharing intelligence = data >to increase situational awareness, report exchanges both internal and >external to an enterprise, and those between enterprise servers and end >points for assessments > >This working group will provide solutions to these categories of problems = and >the main areas of focus for this working group are described as follows: > >1. Define, either by normative reference, adoption, or creation, a set of >standards to enable the exchange of data to increase situational awareness= or >gain access to shared content to improve the security posture of an >enterprise. This area of focus provides for the integration of interopera= ble >protocols to access shared data repositories between organizations to >increase situational awareness and reduce risks to an enterprise. In supp= ort >of accessing shared intelligence for expected system state and related ris= ks, >define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing and aggregating >device states and comparing these device states against expected values, a= nd >reporting on those results in a predefined or ad hoc manner. This area of >focus provides for necessary language and data format specifications. > >3. Define, either by normative reference, adoption, or creation, a set of >standards that can be used to continuously assess and report on the state = of >systems, composed of many different types of devices and networks, >operated by varying personnel, to ensure security process effectiveness in= a >pre-defined or ad-hoc manner. This area of focus provides for integration >protocols supporting plug and play continuous assessment and security >automation networking within an enterprise. > >This working group will achieve the following milestones in two phases: > >Phase One >- A standards track document to define a protocol for interacting with con= tent >repositories >- Standards Track document specifying security automation/continuous >assessment interfaces >- A Standards Track document specifying communication protocols used for >security automation and continuous assessment >- A Standards Track document describing the messages and network protocols >for distributing security automation content (content repository) >- A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >- A Standards Track document specifying asset description format >- A Standards Track document specifying asset identification >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability > >Phase Two >- A Standards Track document specifying a control framework representation >format. >- A Standards Track document specifying benchmark configuration >representation >- An Informational document stating guidelines / requirements for specifyi= ng >checking languages >- Standards Track documents specifying device state checking languages >- A Standards Track document specifying an interrogative checking language >- A Standards Track document specifying asset reporting information >- Standards Track document describing how to use the languages and other >content defined in this group with the NEA protocols >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Sun Sep 23 08:15:22 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6A21F84E4 for ; Sun, 23 Sep 2012 08:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, 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 8bmrr14a5njj for ; Sun, 23 Sep 2012 08:15:21 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 328EF21F8468 for ; Sun, 23 Sep 2012 08:15:20 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8NFF7WB001081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2012 11:15:19 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 23 Sep 2012 11:14:47 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8NFEkHh008540; Sun, 23 Sep 2012 11:14:46 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Sun, 23 Sep 2012 11:14:46 -0400 From: "Moriarty, Kathleen" To: "Baker, Jon" , "Waltermire, David A." , "sacm@ietf.org" Date: Sun, 23 Sep 2012 11:14:44 -0400 Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEg Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 15:15:22 -0000 Hi Jon, With the recent approval of CPE specifications by the ITU-T, these are now = formal recommendations and I believe the full content was included in these= Recommendations (5 total Recommendations), is that correct? If the group = were to select either CPE or SWID, it would need to be by reference now, co= rrect? Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Bak= er, Jon Sent: Sunday, September 23, 2012 5:59 AM To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] SACM BoF Request Also, I noticed the following: >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicabilit= y Language. Has the group considered the SWID specification (ISO/IEC 19770-= 2). The following page and its referenced document may be of help in consid= ering how cpe and swids fit together: http://tagvault.org/Automating_CPE_name_creation Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Moriarty, Kathleen >Sent: Friday, September 21, 2012 4:32 PM >To: Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Hello, > >I am including an updated version of the SACM Charter that includes more o= f >an emphasis on the protocols to share and exchange data within and between >enterprises/organizations. Please feel free to provide feedback to the li= st! > >Thanks & have a good weekend! >Kathleen > > > >BOF full name: Security Automation and Continuous Monitoring [SACM] >AREA: Security >BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) >Agenda: > >* Review the draft charter >* Review draft-waltermire-sacm-use-cases-02 >* Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > >Full Description of BOF: The SACM BoF is intended to progress the work fro= m >the SACM mailing list to solidify discussions on a proposed charter, use c= ases >and milestones in support of moving to an IETF working group. > >CONFLICTS to avoid: SAAG, MILE >Expected Attendance: 40, not sure what the previous attendance was? >Special Requests: Meetecho support >Number of sessions: 1 >Length of session: 2 hours > >Draft Charter: > >Proposed Working Group Charter > >Chairs: >TBD >TBD > >Security Area Directors: > Stephen Farrell > Sean Turner > >Security Area Advisor: > Sean Turner > >Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > >Description of Working Group > >Securing information and the systems that store, process, and transmit tha= t >information has become a challenging task for organizations of all sizes, = and >we find that security practitioners spend most of their time on manual >processes relegating them to ineffectiveness. Security automation to verif= y >system configurations with the ability to prioritize risk based on increas= ed >situational awareness from shared intelligence is the key to escaping this= rut. >This working group will develop security automation protocols and data >format standards in support of information security processes and practice= s >where practical. These standards will help security practitioners to be be= tter >utilized within their organizations by automating routine tasks related to >endpoint and server security so that practitioners can focus on more >advanced tasks. The initial focus of this work is to address enterprise us= e >cases. > >The working group will achieve this by enabling the exchange of shared >intelligence and continuing the security automation work already performed >by various organizations around the world. The initial work has been frui= tful, >and the data formats previously published are ready for expansion on the >international stage. Of particular interest to this working group are the >security automation specifications supporting asset, change, configuration= , >and vulnerability management. Of additional interest to this working group >are the emerging security automation interfaces and data formats relating = to >event management and continuous assessment. The continuous assessment >capabilities enable organizational situational awareness through frequent >snapshots of the operating state of their environment, with risk prioritiz= ed >based on consumed information provided by shared intelligence >(vulnerabilities, threats, etc.). > >By undertaking this work, we recognize that there are multiple categories = of >problems in the security automation domain: enabling interoperable data >exchanges through standardized protocols, defining expressions for particu= lar >domain concepts (i.e. data formats), establishing a standards-based >foundation supporting the curation and exchange of security automation >content collections in content repositories, and enabling interoperability >through the development and use of standard interfaces and communications >protocols. Content based on rich data standards and protocols will provide= the >authoritative instructions needed by data-driven tools to enable the >automated collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in support of organizati= onal >decision making. > >The data exchange protocols will need to meet several exchange types >including those between and within organizations for sharing intelligence = data >to increase situational awareness, report exchanges both internal and >external to an enterprise, and those between enterprise servers and end >points for assessments > >This working group will provide solutions to these categories of problems = and >the main areas of focus for this working group are described as follows: > >1. Define, either by normative reference, adoption, or creation, a set of >standards to enable the exchange of data to increase situational awareness= or >gain access to shared content to improve the security posture of an >enterprise. This area of focus provides for the integration of interopera= ble >protocols to access shared data repositories between organizations to >increase situational awareness and reduce risks to an enterprise. In supp= ort >of accessing shared intelligence for expected system state and related ris= ks, >define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing and aggregating >device states and comparing these device states against expected values, a= nd >reporting on those results in a predefined or ad hoc manner. This area of >focus provides for necessary language and data format specifications. > >3. Define, either by normative reference, adoption, or creation, a set of >standards that can be used to continuously assess and report on the state = of >systems, composed of many different types of devices and networks, >operated by varying personnel, to ensure security process effectiveness in= a >pre-defined or ad-hoc manner. This area of focus provides for integration >protocols supporting plug and play continuous assessment and security >automation networking within an enterprise. > >This working group will achieve the following milestones in two phases: > >Phase One >- A standards track document to define a protocol for interacting with con= tent >repositories >- Standards Track document specifying security automation/continuous >assessment interfaces >- A Standards Track document specifying communication protocols used for >security automation and continuous assessment >- A Standards Track document describing the messages and network protocols >for distributing security automation content (content repository) >- A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >- A Standards Track document specifying asset description format >- A Standards Track document specifying asset identification >- A Standards Track document specifying platform naming >- A Standards Track document specifying platform matching >- A Standards Track document specifying platform applicability > >Phase Two >- A Standards Track document specifying a control framework representation >format. >- A Standards Track document specifying benchmark configuration >representation >- An Informational document stating guidelines / requirements for specifyi= ng >checking languages >- Standards Track documents specifying device state checking languages >- A Standards Track document specifying an interrogative checking language >- A Standards Track document specifying asset reporting information >- Standards Track document describing how to use the languages and other >content defined in this group with the NEA protocols >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Sun Sep 23 10:02:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151F421F84B6 for ; Sun, 23 Sep 2012 10:02:20 -0700 (PDT) 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_54=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 iR0rkoskAzOV for ; Sun, 23 Sep 2012 10:02:18 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A36D121F84A2 for ; Sun, 23 Sep 2012 10:02:18 -0700 (PDT) Received: (qmail 13320 invoked from network); 23 Sep 2012 10:03:07 -0700 Received: from h69-130-58-233.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.227?) (69.130.58.233) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Sep 2012 10:03:07 -0700 Message-ID: <505F40AE.9010207@ThreatGuard.com> Date: Sun, 23 Sep 2012 13:02:38 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "sacm@ietf.org" References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 17:02:20 -0000 This is looking really good, but I can also understand Jon's comment about the seeming focus on data interchange. Before compliance, configuration, vulnerability, etc., data can be exchanged it first needs to be collected, and that collection not only needs to contain a certain minimum set of data elements that makes an unambiguous data interchange possible, but also needs to have some measure of trust so to how those data items were collected. This is one of the strengths of XCCDF+OVAL. The content is public and peer-reviewed for definitive data sources and the proper logic to get the most accurate results so that software the fully implements these standards (as opposed to systems that simply map results to proprietary tests) then have the same level of accuracy as the content. It might be taken as a given that XCCDF/OVAL or some such standard will be leveraged for the endpoint collection/evaluation, but I would prefer to see it explicitly stated as a necessary foundation for the rest. --gun On 9/23/2012 11:12 AM, Moriarty, Kathleen wrote: > Hi Jon, > > Thank you for your comments! The data formats enable communication between entities, but without common protocols, we will miss the opportunity to create interoperability between vendor products. We do want to enable intelligence feeds and common reporting methods, even if it is to point to other efforts like GRC Exchange. The repository work could benefit from common access methods to address one of the additions. The IETF is good at protocols and the SACM community is good at data formats to enable automated security. In bringing these groups together, we should try to take advantage of the expertise of the IETF to more fully solve the problem space. As I found out with RFC6545, people will point out things needed for interoperability for which others deep in a problem space may not be aware. > > Thanks for the catch on two versus three, just trying to make sure people are reading ;-) LOL > > A corrected version is listed below, with the exception of how to deal with the platform naming. In either case, whatever we select will likely be by reference (SWID or CPE). I like the SWID approach, but we'll need more discussion on that. > > BOF full name: Security Automation and Continuous Monitoring [SACM] > AREA: Security > BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) > Agenda: > > * Review the draft charter > * Review draft-waltermire-sacm-use-cases-02 > * Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > > Full Description of BOF: The SACM BoF is intended to progress the work from the SACM mailing list to solidify discussions on a proposed charter, use cases and milestones in support of moving to an IETF working group. > > CONFLICTS to avoid: SAAG, MILE > Expected Attendance: 40, not sure what the previous attendance was? > Special Requests: Meetecho support > Number of sessions: 1 > Length of session: 2 hours > > Draft Charter: > > Proposed Working Group Charter > > Chairs: > TBD > TBD > > Security Area Directors: > Stephen Farrell > Sean Turner > > Security Area Advisor: > Sean Turner > > Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > > Description of Working Group > > Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation protocols and data format standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this work is to address enterprise use cases. > > The working group will achieve this by enabling the exchange of shared intelligence and continuing the security automation work already performed by various organizations around the world. The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group are the emerging security automation interfaces and data formats relating to event management and continuous assessment. The continuous assessment capabilities enable organizational situational awareness through frequent snapshots of the operating state of their environment, with risk prioritized based on consumed information provided by shared intelligence (vulnerabilities, threats, etc.). > > By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: enabling interoperable data exchanges through standardized protocols, defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making. > > The data exchange protocols will need to meet several exchange types including those between and within organizations for sharing intelligence data to increase situational awareness, report exchanges both internal and external to an enterprise, and those between enterprise servers and end points for assessments > > This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows: > > 1. Define, either by normative reference, adoption, or creation, a set of standards to enable the exchange of data to increase situational awareness or gain access to shared content to improve the security posture of an enterprise. This area of focus provides for the integration of interoperable protocols to access shared data repositories between organizations to increase situational awareness and reduce risks to an enterprise. In support of accessing shared intelligence for expected system state and related risks, define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing and aggregating device states and comparing these device states against expected values, and reporting on those results in a predefined or ad hoc manner. This area of focus provides for necessary language and data format specifications. > > 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking within an enterprise. > > This working group will achieve the following milestones in two phases: > > Phase One > - A standards track document to define a protocol for interacting with content repositories > - Standards Track document specifying security automation/continuous assessment interfaces > - A Standards Track document specifying communication protocols used for security automation and continuous assessment > - A Standards Track document describing the messages and network protocols for distributing security automation content (content repository) > - A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems > - A Standards Track document specifying asset description format > - A Standards Track document specifying asset identification > [- A Standards Track document specifying platform naming > - A Standards Track document specifying platform matching > - A Standards Track document specifying platform applicability] > > Phase Two > - A Standards Track document specifying a control framework representation format. > - A Standards Track document specifying benchmark configuration representation > - An Informational document stating guidelines / requirements for specifying checking languages > - Standards Track documents specifying device state checking languages > - A Standards Track document specifying an interrogative checking language > - A Standards Track document specifying asset reporting information > - Standards Track document describing how to use the languages and other content defined in this group with the NEA protocols > > > > Best regards, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Baker, Jon > Sent: Sunday, September 23, 2012 5:51 AM > To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] SACM BoF Request > >> I am including an updated version of the SACM Charter that includes more of >> an emphasis on the protocols to share and exchange data within and between >> enterprises/organizations. > > Why the shift in emphasis to sharing and exchanging data between organizations? This seems to be new to this group. > > Also in the section that lists the focus areas it looks like you intended for there to be three focus areas but accidently merged the second focus area into the first. Your wording in the first focus area appears to start describing a new focus area and your number goes from 1 to 3 skipping number 2. > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Moriarty, Kathleen >> Sent: Friday, September 21, 2012 4:32 PM >> To: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >> >> Hello, >> >> I am including an updated version of the SACM Charter that includes more of >> an emphasis on the protocols to share and exchange data within and between >> enterprises/organizations. Please feel free to provide feedback to the list! >> >> Thanks & have a good weekend! >> Kathleen >> >> >> >> BOF full name: Security Automation and Continuous Monitoring [SACM] >> AREA: Security >> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >> Agenda: >> >> * Review the draft charter >> * Review draft-waltermire-sacm-use-cases-02 >> * Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >> Full Description of BOF: The SACM BoF is intended to progress the work from >> the SACM mailing list to solidify discussions on a proposed charter, use cases >> and milestones in support of moving to an IETF working group. >> >> CONFLICTS to avoid: SAAG, MILE >> Expected Attendance: 40, not sure what the previous attendance was? >> Special Requests: Meetecho support >> Number of sessions: 1 >> Length of session: 2 hours >> >> Draft Charter: >> >> Proposed Working Group Charter >> >> Chairs: >> TBD >> TBD >> >> Security Area Directors: >> Stephen Farrell >> Sean Turner >> >> Security Area Advisor: >> Sean Turner >> >> Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >> Description of Working Group >> >> Securing information and the systems that store, process, and transmit that >> information has become a challenging task for organizations of all sizes, and >> we find that security practitioners spend most of their time on manual >> processes relegating them to ineffectiveness. Security automation to verify >> system configurations with the ability to prioritize risk based on increased >> situational awareness from shared intelligence is the key to escaping this rut. >> This working group will develop security automation protocols and data >> format standards in support of information security processes and practices >> where practical. These standards will help security practitioners to be better >> utilized within their organizations by automating routine tasks related to >> endpoint and server security so that practitioners can focus on more >> advanced tasks. The initial focus of this work is to address enterprise use >> cases. >> >> The working group will achieve this by enabling the exchange of shared >> intelligence and continuing the security automation work already performed >> by various organizations around the world. The initial work has been fruitful, >> and the data formats previously published are ready for expansion on the >> international stage. Of particular interest to this working group are the >> security automation specifications supporting asset, change, configuration, >> and vulnerability management. Of additional interest to this working group >> are the emerging security automation interfaces and data formats relating to >> event management and continuous assessment. The continuous assessment >> capabilities enable organizational situational awareness through frequent >> snapshots of the operating state of their environment, with risk prioritized >> based on consumed information provided by shared intelligence >> (vulnerabilities, threats, etc.). >> >> By undertaking this work, we recognize that there are multiple categories of >> problems in the security automation domain: enabling interoperable data >> exchanges through standardized protocols, defining expressions for particular >> domain concepts (i.e. data formats), establishing a standards-based >> foundation supporting the curation and exchange of security automation >> content collections in content repositories, and enabling interoperability >> through the development and use of standard interfaces and communications >> protocols. Content based on rich data standards and protocols will provide the >> authoritative instructions needed by data-driven tools to enable the >> automated collection and exchange of configuration and vulnerability data >> pertaining to enterprise assets. Information produced by these tools will >> provide accurate and timely situational awareness in support of organizational >> decision making. >> >> The data exchange protocols will need to meet several exchange types >> including those between and within organizations for sharing intelligence data >> to increase situational awareness, report exchanges both internal and >> external to an enterprise, and those between enterprise servers and end >> points for assessments >> >> This working group will provide solutions to these categories of problems and >> the main areas of focus for this working group are described as follows: >> >> 1. Define, either by normative reference, adoption, or creation, a set of >> standards to enable the exchange of data to increase situational awareness or >> gain access to shared content to improve the security posture of an >> enterprise. This area of focus provides for the integration of interoperable >> protocols to access shared data repositories between organizations to >> increase situational awareness and reduce risks to an enterprise. In support >> of accessing shared intelligence for expected system state and related risks, >> define, either by normative reference, adoption, or creation, a set of >> standards that can be used for the purpose of assessing and aggregating >> device states and comparing these device states against expected values, and >> reporting on those results in a predefined or ad hoc manner. This area of >> focus provides for necessary language and data format specifications. >> >> 3. Define, either by normative reference, adoption, or creation, a set of >> standards that can be used to continuously assess and report on the state of >> systems, composed of many different types of devices and networks, >> operated by varying personnel, to ensure security process effectiveness in a >> pre-defined or ad-hoc manner. This area of focus provides for integration >> protocols supporting plug and play continuous assessment and security >> automation networking within an enterprise. >> >> This working group will achieve the following milestones in two phases: >> >> Phase One >> - A standards track document to define a protocol for interacting with content >> repositories >> - Standards Track document specifying security automation/continuous >> assessment interfaces >> - A Standards Track document specifying communication protocols used for >> security automation and continuous assessment >> - A Standards Track document describing the messages and network protocols >> for distributing security automation content (content repository) >> - A Standards Track document describing protocols and data formats for >> securely sharing dynamic network state information among security systems >> - A Standards Track document specifying asset description format >> - A Standards Track document specifying asset identification >> - A Standards Track document specifying platform naming >> - A Standards Track document specifying platform matching >> - A Standards Track document specifying platform applicability >> >> Phase Two >> - A Standards Track document specifying a control framework representation >> format. >> - A Standards Track document specifying benchmark configuration >> representation >> - An Informational document stating guidelines / requirements for specifying >> checking languages >> - Standards Track documents specifying device state checking languages >> - A Standards Track document specifying an interrogative checking language >> - A Standards Track document specifying asset reporting information >> - Standards Track document describing how to use the languages and other >> content defined in this group with the NEA protocols >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Sun Sep 23 11:49:40 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E751921F8471 for ; Sun, 23 Sep 2012 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 cf0CJJ7VotDz for ; Sun, 23 Sep 2012 11:49:40 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id DF53921F8468 for ; Sun, 23 Sep 2012 11:49:39 -0700 (PDT) Received: from mail55-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 23 Sep 2012 18:49:37 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id B6A7F3C014E for ; Sun, 23 Sep 2012 18:49:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI1432I1415Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h) Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1348426175320597_25957; Sun, 23 Sep 2012 18:49:35 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.229]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 41D958005F for ; Sun, 23 Sep 2012 18:49:35 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 23 Sep 2012 18:49:34 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 8B7AC232121B for ; Sun, 23 Sep 2012 11:44:39 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id EE6AD2321215 for ; Sun, 23 Sep 2012 11:44:38 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Sun, 23 Sep 2012 11:52:44 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Sun, 23 Sep 2012 11:49:31 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: New Version Notification for draft-montville-sacm-asset-identification-00.txt Thread-Index: AQHNmbwpURBhD/2rb0iBQj7NbRVtjQ== Date: Sun, 23 Sep 2012 18:49:28 +0000 Message-ID: In-Reply-To: <20120923183940.21756.5931.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.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="iso-8859-1" Content-ID: <48A102D06B91E04B84D9F53AF24409F5@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 2055200c-5ec3-4627-925f-df6acdbc13a1 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [sacm] FW: New Version Notification for draft-montville-sacm-asset-identification-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:49:41 -0000 All: I'm pleased to announce that I have transformed the NIST IR 7693 into an RFC format and submitted it for our consideration (see post notification e-mail below). Please note that this transformation is just that =AD a transformation. I have taken liberties where necessary (mainly for formatting purposes), but the major points, content, and style of the original document remain intact. There are sure to be issues with the document as posted. For example, it is unclear to me what can and cannot be normatively referenced with respect to this transformation. There are also several areas for IANA considerations beyond registering the asset identification namespace (extensions to asset types and relationships, for example). I look forward to working these, and other, issues on this list. Finally, a world of thanks goes to John Wunder, Adam Halbardier, and David Waltermire for their effort in getting IR 7693 finalized =AD this is really their work. Regards, Adam On 9/23/12 11:39 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-montville-sacm-asset-identification-00.txt >has been successfully submitted by Adam W. Montville and posted to the >IETF repository. > >Filename: draft-montville-sacm-asset-identification >Revision: 00 >Title: Asset Identification >Creation date: 2012-09-23 >WG ID: Individual Submission >Number of pages: 73 >URL: =20 >http://www.ietf.org/internet-drafts/draft-montville-sacm-asset-identificat >ion-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-montville-sacm-asset-identification >Htmlized: =20 >http://tools.ietf.org/html/draft-montville-sacm-asset-identification-00 > > >Abstract: > Asset identification plays an important role in an organization's > ability to quickly correlate different sets of information about > assets. This document provides the necessary constructs to uniquely > identify assets based on known identifiers and/or known information > about the assets. This document describes the purpose of asset > identification, a data model for identifying assets, methods for > identifying assets, and guidance on how to use asset identification. > It also identifies a number of known use cases for asset > identification. > > =20 > =20 > > >The IETF Secretariat > > > From bakerj@mitre.org Mon Sep 24 04:20:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81821F860E for ; Mon, 24 Sep 2012 04:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oFGmKTappco for ; Mon, 24 Sep 2012 04:20:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0F521F8607 for ; Mon, 24 Sep 2012 04:20:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5A0321B0E72; Mon, 24 Sep 2012 07:20:23 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B4CFC21B0A1A; Mon, 24 Sep 2012 07:20:23 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 07:20:23 -0400 From: "Baker, Jon" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: Ac2NMb6bWaFSnpf1Sm6ZVfNB3r5xvgAADieQA0S7LLA= Date: Mon, 24 Sep 2012 11:20:23 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130225F96C@IMCMBX03.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Montville Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 11:20:26 -0000 I looking through section 4 I noticed that the references to UC1 and UC2 ap= pear to be incorrect. The document currently says, "4. Functional Capabilities In general, the activities of managing assets, configurations, and vulnerabilities are common between UC1 and UC2. UC1 uses these activities to either grant or deny an entity access to a requested resource. UC2 uses these activities in support of compliance measurement on a periodic basis. At the most basic level, an enterprise needing to satisfy UC1 and UC2 will need certain capabilities to be met. Specifically, we are talking about risk management capabilities. This is the central problem domain, so it makes sense to be able to convey information about technical and non-technical controls, benchmarks, control requirements, control frameworks and other concepts in a common way." I believe you intended to refer to UC2 and UC3. UC1 is the common piece tha= t is used by UC2 and UC3.=20 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Waltermire, David A. >Sent: Friday, September 07, 2012 3:53 PM >To: sacm@ietf.org >Cc: Adam Montville >Subject: [sacm] FW: New Version Notification for draft-waltermire-sacm-use= - >cases-02.txt > >I just posted an updated use cases document (see below) that reduces the >scope to UC1-3 and adds a lot of new content. Many thanks to Adam >Montville for all his hard work on this revision. > >Comments are appreciated. > >Sincerely, >Dave > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Friday, September 07, 2012 3:49 PM >To: Waltermire, David A. >Cc: amontville@tripwire.com >Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.t= xt > > >A new version of I-D, draft-waltermire-sacm-use-cases-02.txt >has been successfully submitted by David Waltermire and posted to the IETF >repository. > >Filename: draft-waltermire-sacm-use-cases >Revision: 02 >Title: Analysis of Security Automation and Continuous Monitoring >(SACM) Use Cases >Creation date: 2012-09-07 >WG ID: Individual Submission >Number of pages: 23 >URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm= -use- >cases-02.txt >Status: http://datatracker.ietf.org/doc/draft-waltermire-sacm-use= -cases >Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-use-case= s-02 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-= use-cases- >02 > >Abstract: > This document identifies foundational use cases, derived functional > capabilities and requirements, architectural components, and the > supporting standards needed to define an interoperable, > automation\infrastructure required to support timely, accurate and > actionable situational awareness over an organization's IT systems. > Automation tools implementing a continuous monitoring approach will > utilize this infrastructure together with existing and emerging > event, incident and network management standards to provide > visibility into the state of assets, user activities and network > \behavior. Stakeholders will be able to use these tools to aggregate > and analyze relevant security and operational data to understand the > organizations security posture, quantify business risk, and make > informed decisions that support organizational objectives while > protecting critical information. Organizations will be able to use > these tools to augment and automate information sharing activities to > collaborate with partners to identify and mitigate threats. Other > automation tools will be able to integrate with these capabilities to > enforce policies based on human decisions to harden systems, prevent > misuse and reduce the overall attack surface. > > > > >The IETF Secretariat > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From john.banghart@nist.gov Mon Sep 24 06:18:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D9B21F863C for ; Mon, 24 Sep 2012 06:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 aDTWIjVoZO6e for ; Mon, 24 Sep 2012 06:18:08 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E69BC21F86B5 for ; Mon, 24 Sep 2012 06:18:07 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 09:17:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 24 Sep 2012 09:18:06 -0400 From: "Banghart, John" To: Adam Montville , "sacm@ietf.org" Date: Mon, 24 Sep 2012 09:18:04 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-montville-sacm-asset-identification-00.txt Thread-Index: Ac2aVsz0Zn1rVQ9rQJ20iQHCmwT/Iw== 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.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-montville-sacm-asset-identification-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:18:09 -0000 QWRhbSwNCg0KVGhhbmtzIHRvIHlvdSBhbmQgZXZlcnlvbmUgZWxzZS4gIEdyZWF0IHRvIHNlZSB0 aGlzIG1vdmluZyBmb3J3YXJkLg0KDQotSm9obg0KDQpPbiA5LzIzLzEyIDI6NDkgUE0sICJBZGFt IE1vbnR2aWxsZSIgPGFtb250dmlsbGVAdHJpcHdpcmUuY29tPiB3cm90ZToNCg0KPkFsbDoNCj4N Cj5JJ20gcGxlYXNlZCB0byBhbm5vdW5jZSB0aGF0IEkgaGF2ZSB0cmFuc2Zvcm1lZCB0aGUgTklT VCBJUiA3NjkzIGludG8gYW4NCj5SRkMgZm9ybWF0IGFuZCBzdWJtaXR0ZWQgaXQgZm9yIG91ciBj b25zaWRlcmF0aW9uIChzZWUgcG9zdCBub3RpZmljYXRpb24NCj5lLW1haWwgYmVsb3cpLiAgUGxl YXNlIG5vdGUgdGhhdCB0aGlzIHRyYW5zZm9ybWF0aW9uIGlzIGp1c3QgdGhhdCChqSBhDQo+dHJh bnNmb3JtYXRpb24uICBJIGhhdmUgdGFrZW4gbGliZXJ0aWVzIHdoZXJlIG5lY2Vzc2FyeSAobWFp bmx5IGZvcg0KPmZvcm1hdHRpbmcgcHVycG9zZXMpLCBidXQgdGhlIG1ham9yIHBvaW50cywgY29u dGVudCwgYW5kIHN0eWxlIG9mIHRoZQ0KPm9yaWdpbmFsIGRvY3VtZW50IHJlbWFpbiBpbnRhY3Qu ICBUaGVyZSBhcmUgc3VyZSB0byBiZSBpc3N1ZXMgd2l0aCB0aGUNCj5kb2N1bWVudCBhcyBwb3N0 ZWQuICBGb3IgZXhhbXBsZSwgaXQgaXMgdW5jbGVhciB0byBtZSB3aGF0IGNhbiBhbmQgY2Fubm90 DQo+YmUgbm9ybWF0aXZlbHkgcmVmZXJlbmNlZCB3aXRoIHJlc3BlY3QgdG8gdGhpcyB0cmFuc2Zv cm1hdGlvbi4gIFRoZXJlIGFyZQ0KPmFsc28gc2V2ZXJhbCBhcmVhcyBmb3IgSUFOQSBjb25zaWRl cmF0aW9ucyBiZXlvbmQgcmVnaXN0ZXJpbmcgdGhlIGFzc2V0DQo+aWRlbnRpZmljYXRpb24gbmFt ZXNwYWNlIChleHRlbnNpb25zICB0byBhc3NldCB0eXBlcyBhbmQgcmVsYXRpb25zaGlwcywNCj5m b3IgZXhhbXBsZSkuDQo+DQo+SSBsb29rIGZvcndhcmQgdG8gd29ya2luZyB0aGVzZSwgYW5kIG90 aGVyLCBpc3N1ZXMgb24gdGhpcyBsaXN0Lg0KPg0KPkZpbmFsbHksIGEgd29ybGQgb2YgdGhhbmtz IGdvZXMgdG8gSm9obiBXdW5kZXIsIEFkYW0gSGFsYmFyZGllciwgYW5kIERhdmlkDQo+V2FsdGVy bWlyZSBmb3IgdGhlaXIgZWZmb3J0IGluIGdldHRpbmcgSVIgNzY5MyBmaW5hbGl6ZWQgoakgdGhp cyBpcyByZWFsbHkNCj50aGVpciB3b3JrLg0KPg0KPlJlZ2FyZHMsDQo+DQo+QWRhbQ0KPg0KPg0K Pg0KPk9uIDkvMjMvMTIgMTE6MzkgQU0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+d3JvdGU6DQo+DQo+Pg0KPj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbW9udHZpbGxlLXNhY20tYXNzZXQtaWRlbnRpZmljYXRpb24tMDAudHh0DQo+ PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRhbSBXLiBNb250dmlsbGUgYW5k IHBvc3RlZCB0byB0aGUNCj4+SUVURiByZXBvc2l0b3J5Lg0KPj4NCj4+RmlsZW5hbWU6CSBkcmFm dC1tb250dmlsbGUtc2FjbS1hc3NldC1pZGVudGlmaWNhdGlvbg0KPj5SZXZpc2lvbjoJIDAwDQo+ PlRpdGxlOgkJIEFzc2V0IElkZW50aWZpY2F0aW9uDQo+PkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA5 LTIzDQo+PldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj5OdW1iZXIgb2YgcGFnZXM6 IDczDQo+PlVSTDogICAgICAgICAgICAgDQo+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LW1vbnR2aWxsZS1zYWNtLWFzc2V0LWlkZW50aWZpY2ENCj4+dA0KPj5pb24t MDAudHh0DQo+PlN0YXR1czogICAgICAgICAgDQo+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbW9udHZpbGxlLXNhY20tYXNzZXQtaWRlbnRpZmljYXRpb24NCj4+SHRtbGl6 ZWQ6ICAgICAgICANCj4+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9udHZpbGxl LXNhY20tYXNzZXQtaWRlbnRpZmljYXRpb24tMDANCj4+DQo+Pg0KPj5BYnN0cmFjdDoNCj4+ICAg QXNzZXQgaWRlbnRpZmljYXRpb24gcGxheXMgYW4gaW1wb3J0YW50IHJvbGUgaW4gYW4gb3JnYW5p emF0aW9uJ3MNCj4+ICAgYWJpbGl0eSB0byBxdWlja2x5IGNvcnJlbGF0ZSBkaWZmZXJlbnQgc2V0 cyBvZiBpbmZvcm1hdGlvbiBhYm91dA0KPj4gICBhc3NldHMuICBUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIHRoZSBuZWNlc3NhcnkgY29uc3RydWN0cyB0byB1bmlxdWVseQ0KPj4gICBpZGVudGlmeSBh c3NldHMgYmFzZWQgb24ga25vd24gaWRlbnRpZmllcnMgYW5kL29yIGtub3duIGluZm9ybWF0aW9u DQo+PiAgIGFib3V0IHRoZSBhc3NldHMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHVy cG9zZSBvZiBhc3NldA0KPj4gICBpZGVudGlmaWNhdGlvbiwgYSBkYXRhIG1vZGVsIGZvciBpZGVu dGlmeWluZyBhc3NldHMsIG1ldGhvZHMgZm9yDQo+PiAgIGlkZW50aWZ5aW5nIGFzc2V0cywgYW5k IGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgYXNzZXQgaWRlbnRpZmljYXRpb24uDQo+PiAgIEl0IGFs c28gaWRlbnRpZmllcyBhIG51bWJlciBvZiBrbm93biB1c2UgY2FzZXMgZm9yIGFzc2V0DQo+PiAg IGlkZW50aWZpY2F0aW9uLg0KPj4NCj4+ICAgICAgICAgICAgICAgICANCj4+ICAgICAgICANCj4+ DQo+Pg0KPj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4NCj4+DQo+Pg0KPg0KPg0KPg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2FjbSBtYWls aW5nIGxpc3QNCj5zYWNtQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWNtDQoNCg== From amontville@tripwire.com Mon Sep 24 07:12:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014221F87AB for ; Mon, 24 Sep 2012 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FedW0hbtMqtN for ; Mon, 24 Sep 2012 07:12:15 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9321F87AA for ; Mon, 24 Sep 2012 07:12:14 -0700 (PDT) Received: from mail184-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Sep 2012 14:12:14 +0000 Received: from mail184-co1 (localhost [127.0.0.1]) by mail184-co1-R.bigfish.com (Postfix) with ESMTP id 45C5DD400DA for ; Mon, 24 Sep 2012 14:12:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zzbb2dI98dI9371I1454I542M1432Ic25dL62a3Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh177df4hz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah1155h) Received: from mail184-co1 (localhost.localdomain [127.0.0.1]) by mail184-co1 (MessageSwitch) id 1348495931497444_30049; Mon, 24 Sep 2012 14:12:11 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.241]) by mail184-co1.bigfish.com (Postfix) with ESMTP id 75DD62C0060 for ; Mon, 24 Sep 2012 14:12:11 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Sep 2012 14:12:10 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id C99652321231 for ; Mon, 24 Sep 2012 07:07:12 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 2761E232120C; Mon, 24 Sep 2012 07:07:12 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 07:15:20 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 07:12:08 -0700 From: Adam Montville To: "Moriarty, Kathleen" , "Baker, Jon" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEgADAr2YA= Date: Mon, 24 Sep 2012 14:12:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 1c4aa417-de52-4982-9b38-24fb011adfea X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:12:16 -0000 On 9/23/12 8:14 AM, "Moriarty, Kathleen" wrote: >Hi Jon, > >With the recent approval of CPE specifications by the ITU-T, these are >now formal recommendations and I believe the full content was included in >these Recommendations (5 total Recommendations), is that correct? If the >group were to select either CPE or SWID, it would need to be by reference >now, correct? When you say "or" in the last sentence above, are you suggesting that we'd reference one or the other, or is it inclusive? > >Best regards, >Kathleen > >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Baker, Jon >Sent: Sunday, September 23, 2012 5:59 AM >To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Also, I noticed the following: > >>- A Standards Track document specifying platform naming >>- A Standards Track document specifying platform matching >>- A Standards Track document specifying platform applicability > >Those seem to roughly align with CPE Naming, CPE Matching, CPE >Applicability Language. Has the group considered the SWID specification >(ISO/IEC 19770-2). The following page and its referenced document may be >of help in considering how cpe and swids fit together: > >http://tagvault.org/Automating_CPE_name_creation > > >Jon > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Jonathan O. Baker >G022 - IA Industry Collaboration >The MITRE Corporation >Email: bakerj@mitre.org > > >>-----Original Message----- >>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>Moriarty, Kathleen >>Sent: Friday, September 21, 2012 4:32 PM >>To: Waltermire, David A.; sacm@ietf.org >>Subject: Re: [sacm] SACM BoF Request >> >>Hello, >> >>I am including an updated version of the SACM Charter that includes more >>of >>an emphasis on the protocols to share and exchange data within and >>between >>enterprises/organizations. Please feel free to provide feedback to the >>list! >> >>Thanks & have a good weekend! >>Kathleen >> >> >> >>BOF full name: Security Automation and Continuous Monitoring [SACM] >>AREA: Security >>BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >>Agenda: >> >>* Review the draft charter >>* Review draft-waltermire-sacm-use-cases-02 >>* Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >>Full Description of BOF: The SACM BoF is intended to progress the work >>from >>the SACM mailing list to solidify discussions on a proposed charter, use >>cases >>and milestones in support of moving to an IETF working group. >> >>CONFLICTS to avoid: SAAG, MILE >>Expected Attendance: 40, not sure what the previous attendance was? >>Special Requests: Meetecho support >>Number of sessions: 1 >>Length of session: 2 hours >> >>Draft Charter: >> >>Proposed Working Group Charter >> >>Chairs: >>TBD >>TBD >> >>Security Area Directors: >> Stephen Farrell >> Sean Turner >> >>Security Area Advisor: >> Sean Turner >> >>Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >>Description of Working Group >> >>Securing information and the systems that store, process, and transmit >>that >>information has become a challenging task for organizations of all >>sizes, and >>we find that security practitioners spend most of their time on manual >>processes relegating them to ineffectiveness. Security automation to >>verify >>system configurations with the ability to prioritize risk based on >>increased >>situational awareness from shared intelligence is the key to escaping >>this rut. >>This working group will develop security automation protocols and data >>format standards in support of information security processes and >>practices >>where practical. These standards will help security practitioners to be >>better >>utilized within their organizations by automating routine tasks related >>to >>endpoint and server security so that practitioners can focus on more >>advanced tasks. The initial focus of this work is to address enterprise >>use >>cases. >> >>The working group will achieve this by enabling the exchange of shared >>intelligence and continuing the security automation work already >>performed >>by various organizations around the world. The initial work has been >>fruitful, >>and the data formats previously published are ready for expansion on the >>international stage. Of particular interest to this working group are the >>security automation specifications supporting asset, change, >>configuration, >>and vulnerability management. Of additional interest to this working >>group >>are the emerging security automation interfaces and data formats >>relating to >>event management and continuous assessment. The continuous assessment >>capabilities enable organizational situational awareness through frequent >>snapshots of the operating state of their environment, with risk >>prioritized >>based on consumed information provided by shared intelligence >>(vulnerabilities, threats, etc.). >> >>By undertaking this work, we recognize that there are multiple >>categories of >>problems in the security automation domain: enabling interoperable data >>exchanges through standardized protocols, defining expressions for >>particular >>domain concepts (i.e. data formats), establishing a standards-based >>foundation supporting the curation and exchange of security automation >>content collections in content repositories, and enabling >>interoperability >>through the development and use of standard interfaces and communications >>protocols. Content based on rich data standards and protocols will >>provide the >>authoritative instructions needed by data-driven tools to enable the >>automated collection and exchange of configuration and vulnerability data >>pertaining to enterprise assets. Information produced by these tools will >>provide accurate and timely situational awareness in support of >>organizational >>decision making. >> >>The data exchange protocols will need to meet several exchange types >>including those between and within organizations for sharing >>intelligence data >>to increase situational awareness, report exchanges both internal and >>external to an enterprise, and those between enterprise servers and end >>points for assessments >> >>This working group will provide solutions to these categories of >>problems and >>the main areas of focus for this working group are described as follows: >> >>1. Define, either by normative reference, adoption, or creation, a set of >>standards to enable the exchange of data to increase situational >>awareness or >>gain access to shared content to improve the security posture of an >>enterprise. This area of focus provides for the integration of >>interoperable >>protocols to access shared data repositories between organizations to >>increase situational awareness and reduce risks to an enterprise. In >>support >>of accessing shared intelligence for expected system state and related >>risks, >>define, either by normative reference, adoption, or creation, a set of >>standards that can be used for the purpose of assessing and aggregating >>device states and comparing these device states against expected values, >>and >>reporting on those results in a predefined or ad hoc manner. This area >>of >>focus provides for necessary language and data format specifications. >> >>3. Define, either by normative reference, adoption, or creation, a set of >>standards that can be used to continuously assess and report on the >>state of >>systems, composed of many different types of devices and networks, >>operated by varying personnel, to ensure security process effectiveness >>in a >>pre-defined or ad-hoc manner. This area of focus provides for >>integration >>protocols supporting plug and play continuous assessment and security >>automation networking within an enterprise. >> >>This working group will achieve the following milestones in two phases: >> >>Phase One >>- A standards track document to define a protocol for interacting with >>content >>repositories >>- Standards Track document specifying security automation/continuous >>assessment interfaces >>- A Standards Track document specifying communication protocols used for >>security automation and continuous assessment >>- A Standards Track document describing the messages and network >>protocols >>for distributing security automation content (content repository) >>- A Standards Track document describing protocols and data formats for >>securely sharing dynamic network state information among security systems >>- A Standards Track document specifying asset description format >>- A Standards Track document specifying asset identification >>- A Standards Track document specifying platform naming >>- A Standards Track document specifying platform matching >>- A Standards Track document specifying platform applicability >> >>Phase Two >>- A Standards Track document specifying a control framework >>representation >>format. >>- A Standards Track document specifying benchmark configuration >>representation >>- An Informational document stating guidelines / requirements for >>specifying >>checking languages >>- Standards Track documents specifying device state checking languages >>- A Standards Track document specifying an interrogative checking >>language >>- A Standards Track document specifying asset reporting information >>- Standards Track document describing how to use the languages and other >>content defined in this group with the NEA protocols >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > > From mdavidson@mitre.org Mon Sep 24 07:23:35 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0A821F8787 for ; Mon, 24 Sep 2012 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pa4lmPcjRaF5 for ; Mon, 24 Sep 2012 07:23:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4042321F8683 for ; Mon, 24 Sep 2012 07:23:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C65221B1AF9; Mon, 24 Sep 2012 10:23:29 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 67BEB21B1AE8; Mon, 24 Sep 2012 10:23:29 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.34]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 10:23:29 -0400 From: "Davidson II, Mark S" To: "sacm@ietf.org" Thread-Topic: ASR RFC Questions Thread-Index: Ac2aYCmhtdKxNJ9oQB+lyReYXUTuWQ== Date: Mon, 24 Sep 2012 14:23:29 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BD21F34@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.53] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80BD21F34IMCMBX02MITREOR_" MIME-Version: 1.0 Cc: "david.oliva@verizon.net" Subject: [sacm] ASR RFC Questions X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:23:35 -0000 --_000_69F1FC52EB080B4983863BD1602520D80BD21F34IMCMBX02MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, First, a couple of notes: ASR NIST IR: http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nis= tir_7848.pdf I am currently using NRoffEdit to create the ASR. As David and I work through the draft RFC for ASR, I have some questions fo= r the group: 0. Is the draft's deadline 10/15? 1. In the case that a contributor does not represent an organization, what = is the appropriate text that would go in place of the organization? 2. ASR has a few tables (notably tables 6-1 through 6-12). What is the best= way to represent these tables in RFC format? 3. Is it worth sharing the NRoffEdit file in this forum before posting as a= draft, or should it just be posted as a draft when ready? The conversion to RFC is mostly complete, though I'm sure there will be ple= nty of topics to address within the draft. The major work left to be done i= s creating the data model tables in the RFC. Thank you. Mark Davidson MDavidson@MITRE.org Information Security Engineer G022 - Information Assurance The MITRE Corporation --_000_69F1FC52EB080B4983863BD1602520D80BD21F34IMCMBX02MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

First, a couple of notes:

ASR NIST IR: http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nistir_7848.pdf<= /a>

I am currently using NRoffEdit to create the ASR.

 

As David and I work through the draft RFC for ASR, I= have some questions for the group:

 

0. Is the draft’s deadline 10/15?

1. In the case that a contributor does not represent= an organization, what is the appropriate text that would go in place of th= e organization?

2. ASR has a few tables (notably tables 6-1 through = 6-12). What is the best way to represent these tables in RFC format?

3. Is it worth sharing the NRoffEdit file in this fo= rum before posting as a draft, or should it just be posted as a draft when = ready?

 

The conversion to RFC is mostly complete, though I&#= 8217;m sure there will be plenty of topics to address within the draft. The= major work left to be done is creating the data model tables in the RFC.

 

Thank you.

 

Mark Davidson

MDavidson@MITRE.org

Information Security Engineer

G022 - Information Assurance

The MITRE Corporation

 

--_000_69F1FC52EB080B4983863BD1602520D80BD21F34IMCMBX02MITREOR_-- From amontville@tripwire.com Mon Sep 24 07:24:14 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAAF21F8799 for ; Mon, 24 Sep 2012 07:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rgy6Aj0Z4UM8 for ; Mon, 24 Sep 2012 07:24:13 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 331F221F8793 for ; Mon, 24 Sep 2012 07:24:13 -0700 (PDT) Received: from mail66-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Sep 2012 14:24:12 +0000 Received: from mail66-co1 (localhost [127.0.0.1]) by mail66-co1-R.bigfish.com (Postfix) with ESMTP id 9A40A6800AF for ; Mon, 24 Sep 2012 14:24:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371I936eI542M1432I1a09J62a3Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah1155h) Received: from mail66-co1 (localhost.localdomain [127.0.0.1]) by mail66-co1 (MessageSwitch) id 1348496649990129_21690; Mon, 24 Sep 2012 14:24:09 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.239]) by mail66-co1.bigfish.com (Postfix) with ESMTP id E4B0AA00054 for ; Mon, 24 Sep 2012 14:24:09 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Sep 2012 14:24:08 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id A03572321231 for ; Mon, 24 Sep 2012 07:19:10 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 09395232120C; Mon, 24 Sep 2012 07:19:10 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 07:27:18 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 07:24:06 -0700 From: Adam Montville To: "Baker, Jon" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt Thread-Index: Ac2NMb6b+r9MbropPUWAwtxhNNSIcQAADieQA1PS9YD//736gA== Date: Mon, 24 Sep 2012 14:24:05 +0000 Message-ID: In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130225F96C@IMCMBX03.MITRE.ORG> 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: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <79DCDD156AFE5D4EAF04C7DC8435A892@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 12270d91-48e8-4e6d-8992-aca6608aac26 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:24:14 -0000 You're probably right, Jon. Either Dave or I will review and fix. It seems, however, that the intent was clear enough for you (the reader) to figure out. I'm interested in hearing any feedback about the use cases, how they're broken down, what's missing, whether the scope is correct, and so on. Regards, Adam On 9/24/12 4:20 AM, "Baker, Jon" wrote: >I looking through section 4 I noticed that the references to UC1 and UC2 >appear to be incorrect. The document currently says, > >"4. Functional Capabilities > > In general, the activities of managing assets, configurations, and > vulnerabilities are common between UC1 and UC2. UC1 uses these > activities to either grant or deny an entity access to a requested > resource. UC2 uses these activities in support of compliance > measurement on a periodic basis. > > At the most basic level, an enterprise needing to satisfy UC1 and UC2 > will need certain capabilities to be met. Specifically, we are > talking about risk management capabilities. This is the central > problem domain, so it makes sense to be able to convey information > about technical and non-technical controls, benchmarks, control > requirements, control frameworks and other concepts in a common way." > >I believe you intended to refer to UC2 and UC3. UC1 is the common piece >that is used by UC2 and UC3. > > > >Jon > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Jonathan O. Baker >G022 - IA Industry Collaboration >The MITRE Corporation >Email: bakerj@mitre.org > > >>-----Original Message----- >>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>Waltermire, David A. >>Sent: Friday, September 07, 2012 3:53 PM >>To: sacm@ietf.org >>Cc: Adam Montville >>Subject: [sacm] FW: New Version Notification for >>draft-waltermire-sacm-use- >>cases-02.txt >> >>I just posted an updated use cases document (see below) that reduces the >>scope to UC1-3 and adds a lot of new content. Many thanks to Adam >>Montville for all his hard work on this revision. >> >>Comments are appreciated. >> >>Sincerely, >>Dave >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Friday, September 07, 2012 3:49 PM >>To: Waltermire, David A. >>Cc: amontville@tripwire.com >>Subject: New Version Notification for >>draft-waltermire-sacm-use-cases-02.txt >> >> >>A new version of I-D, draft-waltermire-sacm-use-cases-02.txt >>has been successfully submitted by David Waltermire and posted to the >>IETF >>repository. >> >>Filename: draft-waltermire-sacm-use-cases >>Revision: 02 >>Title: Analysis of Security Automation and Continuous Monitoring >>(SACM) Use Cases >>Creation date: 2012-09-07 >>WG ID: Individual Submission >>Number of pages: 23 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use- >>cases-02.txt >>Status: =20 >>http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases >>Htmlized: =20 >>http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases- >>02 >> >>Abstract: >> This document identifies foundational use cases, derived functional >> capabilities and requirements, architectural components, and the >> supporting standards needed to define an interoperable, >> automation\infrastructure required to support timely, accurate and >> actionable situational awareness over an organization's IT systems. >> Automation tools implementing a continuous monitoring approach will >> utilize this infrastructure together with existing and emerging >> event, incident and network management standards to provide >> visibility into the state of assets, user activities and network >> \behavior. Stakeholders will be able to use these tools to aggregate >> and analyze relevant security and operational data to understand the >> organizations security posture, quantify business risk, and make >> informed decisions that support organizational objectives while >> protecting critical information. Organizations will be able to use >> these tools to augment and automate information sharing activities to >> collaborate with partners to identify and mitigate threats. Other >> automation tools will be able to integrate with these capabilities to >> enforce policies based on human decisions to harden systems, prevent >> misuse and reduce the overall attack surface. >> >> >> >> >>The IETF Secretariat >> >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm > > From amontville@tripwire.com Mon Sep 24 07:31:13 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7113021F8799 for ; Mon, 24 Sep 2012 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 CWxCXXWm6OOE for ; Mon, 24 Sep 2012 07:31:12 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8112221F8787 for ; Mon, 24 Sep 2012 07:31:12 -0700 (PDT) Received: from mail12-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Sep 2012 14:31:11 +0000 Received: from mail12-ch1 (localhost [127.0.0.1]) by mail12-ch1-R.bigfish.com (Postfix) with ESMTP id 835EC34010B for ; Mon, 24 Sep 2012 14:31:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z551biz9371Ic85ehd6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah30d1K8275bh8275dh5eeeKz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ahbe3k1155h) Received: from mail12-ch1 (localhost.localdomain [127.0.0.1]) by mail12-ch1 (MessageSwitch) id 1348497068870596_31779; Mon, 24 Sep 2012 14:31:08 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail12-ch1.bigfish.com (Postfix) with ESMTP id C7CEA1A0057 for ; Mon, 24 Sep 2012 14:31:08 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Sep 2012 14:31:06 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 7012D2321249 for ; Mon, 24 Sep 2012 07:26:08 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id C83A5232120C; Mon, 24 Sep 2012 07:26:07 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 07:34:16 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 07:31:04 -0700 From: Adam Montville To: "Davidson II, Mark S" , "sacm@ietf.org" Thread-Topic: [sacm] ASR RFC Questions Thread-Index: Ac2aYCmhtdKxNJ9oQB+lyReYXUTuWQAAQ/SA Date: Mon, 24 Sep 2012 14:31:04 +0000 Message-ID: In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD21F34@IMCMBX02.MITRE.ORG> 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: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC85BBF54CB0amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 219fd32c-38bf-460c-a9ec-19603ed91277 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "david.oliva@verizon.net" Subject: Re: [sacm] ASR RFC Questions X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:31:13 -0000 --_000_CC85BBF54CB0amontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "", Mark S > Date: Monday, September 24, 2012 7:23 AM To: "sacm@ietf.org" > Cc: "david.oliva@verizon.net" > Subject: [sacm] ASR RFC Questions All, First, a couple of notes: ASR NIST IR: http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nis= tir_7848.pdf I am currently using NRoffEdit to create the ASR. As David and I work through the draft RFC for ASR, I have some questions fo= r the group: 0. Is the draft=92s deadline 10/15? One of the BoF chairs would know for sure, but I believe that is correct. 1. In the case that a contributor does not represent an organization, what = is the appropriate text that would go in place of the organization? I don't really know the answer, but there are others on this list who proba= bly do. 2. ASR has a few tables (notably tables 6-1 through 6-12). What is the best= way to represent these tables in RFC format? This depends on the complexity of the tables. I don't know about creating = tables using the Nroff editor, just XML. When all else fails, using someth= ing that helps create ascii diagrams is useful (UltraEdit or http://www.asc= iiflow.com). 3. Is it worth sharing the NRoffEdit file in this forum before posting as a= draft, or should it just be posted as a draft when ready? I would just post it. That's what I did for the AI transformation. The conversion to RFC is mostly complete, though I=92m sure there will be p= lenty of topics to address within the draft. The major work left to be done= is creating the data model tables in the RFC. Outstanding! Thanks for your collective efforts! Thank you. Mark Davidson MDavidson@MITRE.org Information Security Engineer G022 - Information Assurance The MITRE Corporation --_000_CC85BBF54CB0amontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D91F3967B33C04DA735C7B33AA991C7@tripwire.com> Content-Transfer-Encoding: quoted-printable



One of the BoF chairs would know for sure, but I believe that is corre= ct.


1. In the case that a contributor does not represent= an organization, what is the appropriate text that would go in place of th= e organization?

I don't really know the answer, but there are others on this list who = probably do.

2. ASR has a few tables (notably tables 6-1 through = 6-12). What is the best way to represent these tables in RFC format?


This depends on the complexity of the tables.  I don't know about= creating tables using the Nroff editor, just XML.  When all else fail= s, using something that helps create ascii diagrams is useful (UltraEdit or= http://www.asciiflow.com).

3. Is it worth sharing the NRoffEdit file in this fo= rum before posting as a draft, or should it just be posted as a draft when = ready?

 

I would just post it.  That's what I did for the AI transformatio= n.


The conversion to RFC is mostly complete, though I= =92m sure there will be plenty of topics to address within the draft. The m= ajor work left to be done is creating the data model tables in the RFC.

Outstanding!  Thanks for your collective efforts!


 

Thank you.

 

Mark Davidson

MDavidson@MIT= RE.org

Information Security Engineer

G022 - Information Assurance

The MITRE Corporation

 



--_000_CC85BBF54CB0amontvilletripwirecom_-- From amontville@tripwire.com Mon Sep 24 07:39:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1821F8683 for ; Mon, 24 Sep 2012 07:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 uy08ivHuh8rf for ; Mon, 24 Sep 2012 07:39:09 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4CF21F84A7 for ; Mon, 24 Sep 2012 07:39:09 -0700 (PDT) Received: from mail136-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Sep 2012 14:39:08 +0000 Received: from mail136-va3 (localhost [127.0.0.1]) by mail136-va3-R.bigfish.com (Postfix) with ESMTP id 523C34A0339 for ; Mon, 24 Sep 2012 14:39:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzc85fh1102Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ahbe3k1155h) Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3 (MessageSwitch) id 1348497547292855_30248; Mon, 24 Sep 2012 14:39:07 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.240]) by mail136-va3.bigfish.com (Postfix) with ESMTP id 36A933A0057 for ; Mon, 24 Sep 2012 14:39:07 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Sep 2012 14:39:05 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 2CD812321231 for ; Mon, 24 Sep 2012 07:34:07 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 91DD4232120C for ; Mon, 24 Sep 2012 07:34:06 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 07:42:14 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 07:39:03 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Other Transformations and Next Work Thread-Index: AQHNmmJXWNkCmQbCrEaep+/UK3lDKQ== Date: Mon, 24 Sep 2012 14:39:02 +0000 Message-ID: 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: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC85BE954CC9amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: a3064e29-0a97-4b38-bb35-34f35c6cb447 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [sacm] Other Transformations and Next Work X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:39:10 -0000 --_000_CC85BE954CC9amontvilletripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: The asset identification transformation has been posted, and it seems that = the ASR transformation will be done as well. I think we can normatively r= eference CPE, if necessary, and probably SWID as well. But, these are (as presently proposed in the draft charter) phase two effor= ts. We should probably consider getting something done with respect to the= first few deliverables of phase one. That said, some valid concerns have been raised to the list. Should we wor= k on the communication protocols first or second? What comes first, the ch= icken or the egg? If we can normatively reference those pieces used for ef= fective assessment and/or automation, then we should be able to safely take= care of the protocols first. Is anyone yet working on the document specifying communication protocols us= ed for security automation and continuous assessment? Adam --_000_CC85BE954CC9amontvilletripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2A2B9FB313CCCF4491DF323B23358A41@tripwire.com> Content-Transfer-Encoding: quoted-printable
All:

The asset identification transformation has been posted, and it seems = that the ASR transformation will be done as well.   I think we can nor= matively reference CPE, if necessary, and probably SWID as well.  

But, these are (as presently proposed in the draft charter) phase two = efforts.  We should probably consider getting something done with resp= ect to the first few deliverables of phase one.  

That said, some valid concerns have been raised to the list.  Sho= uld we work on the communication protocols first or second?  What come= s first, the chicken or the egg?  If we can normatively reference thos= e pieces used for effective assessment and/or automation, then we should be able to safely take care of the protocols first.

Is anyone yet working on the document specifying communication protoco= ls used for security automation and continuous assessment?

Adam
--_000_CC85BE954CC9amontvilletripwirecom_-- From john.banghart@nist.gov Mon Sep 24 11:01:52 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06621F8803; Mon, 24 Sep 2012 11:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Lr-AeYYt+RoY; Mon, 24 Sep 2012 11:01:51 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E470621F87FE; Mon, 24 Sep 2012 11:01:50 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 14:01:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 24 Sep 2012 14:01:49 -0400 From: "Banghart, John" To: "sacm@ietf.org" , "mile@ietf.org" Date: Mon, 24 Sep 2012 14:01:45 -0400 Thread-Topic: Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2afm7Z7K4Rsa/6QIqh6G/YPMl5VA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC8618484F76johnbanghartnistgov_" MIME-Version: 1.0 Subject: [sacm] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:01:52 -0000 --_000_CC8618484F76johnbanghartnistgov_ Content-Type: text/plain; charset="us-ascii" Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards. The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts. Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend. Participants are encouraged to share their use cases and requirements for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the room number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_CC8618484F76johnbanghartnistgov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48ZGl2PjxkaXY+SGVsbG8gYWxsLDwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhlcmUgd2lsbCBiZSBhIGJpcmRzLW9mLWEtZmVhdGhlciAoQm9GKSBzZXNz aW9uIGF0IHRoZSB1cGNvbWluZyBJVCBTZWN1cml0eSBBdXRvbWF0aW9uIENvbmZlcmVuY2UgKElU U0FDKSBpbiBCYWx0aW1vcmUgb24gV2VkbmVzZGF5LCBPY3RvYmVyIDR0aCwgZnJvbSA1OjMwcG0g dG8gNjozMHBtLCBmb2N1c2luZyBvbiBpbnRlcm5hdGlvbmFsIGVmZm9ydHMgdG8gZGV2ZWxvcCBz ZWN1cml0eSBhdXRvbWF0aW9uIHN0YW5kYXJkcy4gJm5ic3A7VGhlIEJvRiB3aWxsIGZvY3VzIG9u IHJldmlld2luZyBjdXJyZW50IGVmZm9ydHMgdG8gc3RhbmRhcmRpemUgc2VjdXJpdHkgYXV0b21h dGlvbiBjYXBhYmlsaXRpZXMgYW5kIGhvdyB0byBlbmdhZ2UgaW4gdGhlc2UgZWZmb3J0cy4gJm5i c3A7QW55b25lIGFjdGl2ZWx5IG9yIGludGVyZXN0ZWQgaW4gcGFydGljaXBhdGluZyBpbiBvciB1 c2luZyBzdGFuZGFyZHMgZGV2ZWxvcGVkIGJ5IGludGVybmF0aW9uYWwgc3RhbmRhcmRzIGRldmVs b3BtZW50IG9yZ2FuaXphdGlvbnMgKFNET3MpIHNob3VsZCBhdHRlbmQuICZuYnNwO1BhcnRpY2lw YW50cyBhcmUgZW5jb3VyYWdlZCB0byBzaGFyZSB0aGVpciB1c2UgY2FzZXMgYW5kIHJlcXVpcmVt ZW50cyBmb3Igc2VjdXJpdHkgYXV0b21hdGlvbiBzdGFuZGFyZHMuPC9kaXY+PGRpdj4mbmJzcDs8 L2Rpdj48ZGl2PkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBJVFNBQywgcGxlYXNlIHZpc2l0 OiBodHRwczovL2l0c2FjLmcycGxhbmV0LmNvbS9pdHNhYzIwMTIuICZuYnNwOzwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+UGxlYXNlIG5vdGUgdGhhdCByZW1vdGUgYWNjZXNzIGNhcGFiaWxpdGll cyB3aWxsIG5vdCBiZSBwb3NzaWJsZS48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pklm IHRoZXJlIGlzIHN1ZmZpY2llbnQgaW50ZXJlc3QsIEkgd2lsbCBwcm92aWRlIGFkZGl0aW9uYWwg ZGV0YWlscyBvbiB0aGUgcm9vbSBudW1iZXIgYW5kIG90aGVyIGxvZ2lzdGljcy48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi1Kb2hu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2PjxkaXY+LS08L2Rpdj48ZGl2PkpvaG4gQmFu Z2hhcnQ8L2Rpdj48ZGl2PlByb2dyYW0gQW5hbHlzdDwvZGl2PjxkaXY+UHJvZ3JhbSBDb29yZGlu YXRpb24gT2ZmaWNlPC9kaXY+PGRpdj5PZmZpY2Ugb2YgdGhlIFVuZGVyIFNlY3JldGFyeSBvZiBD b21tZXJjZSBmb3IgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5PC9kaXY+PGRpdj5OYXRpb25hbCBJ bnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj4oMzAxKSA5NzUtODA4NTwvZGl2PjxkaXY+Sm9obi5iYW5naGFydEBuaXN0LmdvdjwvZGl2 PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+DQo= --_000_CC8618484F76johnbanghartnistgov_-- From tony@yaanatech.com Mon Sep 24 11:33:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFBB21F8683; Mon, 24 Sep 2012 11:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqGApxXRmZoz; Mon, 24 Sep 2012 11:33:27 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2922621F8686; Mon, 24 Sep 2012 11:33:26 -0700 (PDT) Received: from [192.168.0.4] (pool-96-247-209-46.clppva.fios.verizon.net [96.247.209.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id E22D058081; Mon, 24 Sep 2012 18:33:25 +0000 (UTC) Message-ID: <5060A774.1040605@yaanatech.com> Date: Mon, 24 Sep 2012 14:33:24 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: "Banghart, John" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060604050302080306090008" Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:33:27 -0000 This is a multi-part message in MIME format. --------------060604050302080306090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi John, How are going to provide notice of the room to those of us there? --tony On 9/24/2012 2:01 PM, Banghart, John wrote: > Hello all, > > There will be a birds-of-a-feather (BoF) session at the upcoming IT > Security Automation Conference (ITSAC) in Baltimore on Wednesday, > October 4th, from 5:30pm to 6:30pm, focusing on international efforts > to develop security automation standards. The BoF will focus on > reviewing current efforts to standardize security automation > capabilities and how to engage in these efforts. Anyone actively or > interested in participating in or using standards developed by > international standards development organizations (SDOs) should > attend. Participants are encouraged to share their use cases and > requirements for security automation standards. > For more information on the ITSAC, please visit: > https://itsac.g2planet.com/itsac2012. > > Please note that remote access capabilities will not be possible. > > If there is sufficient interest, I will provide additional details on > the room number and other logistics. > > Thank you. > > -John > > -- > John Banghart > Program Analyst > Program Coordination Office > Office of the Under Secretary of Commerce for Standards and Technology > National Institute of Standards and Technology > > (301) 975-8085 > John.banghart@nist.gov > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --------------060604050302080306090008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi John,

How are going to provide notice of the room
to those of us there?

--tony

On 9/24/2012 2:01 PM, Banghart, John wrote:
Hello all,

There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards.  The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts.  Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend.  Participants are encouraged to share their use cases and requirements for security automation standards.
 
For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012.  

Please note that remote access capabilities will not be possible.

If there is sufficient interest, I will provide additional details on the room number and other logistics.

Thank you.

-John

--
John Banghart
Program Analyst
Program Coordination Office
Office of the Under Secretary of Commerce for Standards and Technology
National Institute of Standards and Technology

(301) 975-8085


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

--------------060604050302080306090008-- From john.banghart@nist.gov Mon Sep 24 11:47:57 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD56821F884D; Mon, 24 Sep 2012 11:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 yCZSf-uFQYZE; Mon, 24 Sep 2012 11:47:57 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id CE49821F888F; Mon, 24 Sep 2012 11:47:56 -0700 (PDT) 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.1.379.0; Mon, 24 Sep 2012 14:47:42 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 24 Sep 2012 14:47:55 -0400 From: "Banghart, John" To: "tony@yaanatech.com" Date: Mon, 24 Sep 2012 14:47:52 -0400 Thread-Topic: [mile] Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2ahN+1/dYx5YsvQxO6kHqP9MVPYQ== Message-ID: In-Reply-To: <5060A774.1040605@yaanatech.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 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC8622F34F8Fjohnbanghartnistgov_" MIME-Version: 1.0 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:47:58 -0000 --_000_CC8622F34F8Fjohnbanghartnistgov_ Content-Type: text/plain; charset="us-ascii" Tony, Great question. Once we are confirmed, there will be a notice board in the registration area indicating what sessions are taking place in what room. -John From: Tony Rutkowski > Organization: Yaana Technologies Reply-To: "tony@yaanatech.com" > Date: Monday, September 24, 2012 2:33 PM To: "Banghart, John" > Cc: "sacm@ietf.org" >, "mile@ietf.org" > Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Hi John, How are going to provide notice of the room to those of us there? --tony On 9/24/2012 2:01 PM, Banghart, John wrote: Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards. The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts. Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend. Participants are encouraged to share their use cases and requirements for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the room number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov _______________________________________________ mile mailing list mile@ietf.orghttps://www.ietf.org/mailman/listinfo/mile --_000_CC8622F34F8Fjohnbanghartnistgov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48ZGl2PlRvbnksPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj5HcmVhdCBxdWVzdGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uY2Ugd2UgYXJlIGNv bmZpcm1lZCwgdGhlcmUgd2lsbCBiZSBhIG5vdGljZSBib2FyZCBpbiB0aGUgcmVnaXN0cmF0aW9u IGFyZWEgaW5kaWNhdGluZyB3aGF0IHNlc3Npb25zIGFyZSB0YWtpbmcgcGxhY2UgaW4gd2hhdCBy b29tLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LUpvaG48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj4gVG9ueSBSdXRrb3dza2kgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20i PnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Pcmdhbml6YXRpb246IDwvc3Bhbj4gWWFhbmEgVGVjaG5vbG9naWVzPGJyPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXBseS1UbzogPC9zcGFuPiAiPGEgaHJlZj0ibWFpbHRv OnRvbnlAeWFhbmF0ZWNoLmNvbSI+dG9ueUB5YWFuYXRlY2guY29tPC9hPiIgJmx0OzxhIGhyZWY9 Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20iPnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4mZ3Q7PGJy PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+IE1vbmRheSwgU2Vw dGVtYmVyIDI0LCAyMDEyIDI6MzMgUE08YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlRvOiA8L3NwYW4+ICJCYW5naGFydCwgSm9obiIgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2huLmJh bmdoYXJ0QG5pc3QuZ292Ij5qb2huLmJhbmdoYXJ0QG5pc3QuZ292PC9hPiZndDs8YnI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+ICI8YSBocmVmPSJtYWlsdG86c2Fj bUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4mZ3Q7LCAiPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0 Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5v cmciPm1pbGVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPiBSZTogW21pbGVdIFVwY29taW5nIEJvRiBhdCB0aGUgSVQgU2Vj dXJpdHkgQXV0b21hdGlvbiBDb25mZXJlbmNlPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+PGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5IaSBKb2huLDxicj48YnI+DQpIb3cgYXJlIGdvaW5nIHRvIHBy b3ZpZGUgbm90aWNlIG9mIHRoZSByb29tPGJyPg0KdG8gdGhvc2Ugb2YgdXMgdGhlcmU/PGJyPjxi cj4NCi0tdG9ueTxicj48YnI+DQpPbiA5LzI0LzIwMTIgMjowMSBQTSwgQmFuZ2hhcnQsIEpvaG4g d3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNpdGU9Im1pZDpDQzg2MTg0OC40Rjc2JTI1am9o bi5iYW5naGFydEBuaXN0LmdvdiIgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2PkhlbGxvIGFsbCw8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZXJlIHdpbGwgYmUgYSBiaXJkcy1vZi1hLWZlYXRoZXIg KEJvRikgc2Vzc2lvbiBhdCB0aGUgdXBjb21pbmcgSVQgU2VjdXJpdHkgQXV0b21hdGlvbiBDb25m ZXJlbmNlIChJVFNBQykgaW4gQmFsdGltb3JlIG9uIFdlZG5lc2RheSwgT2N0b2JlciA0dGgsIGZy b20gNTozMHBtIHRvIDY6MzBwbSwgZm9jdXNpbmcgb24gaW50ZXJuYXRpb25hbCBlZmZvcnRzIHRv IGRldmVsb3Agc2VjdXJpdHkgYXV0b21hdGlvbiBzdGFuZGFyZHMuICZuYnNwO1RoZSBCb0YNCiB3 aWxsIGZvY3VzIG9uIHJldmlld2luZyBjdXJyZW50IGVmZm9ydHMgdG8gc3RhbmRhcmRpemUgc2Vj dXJpdHkgYXV0b21hdGlvbiBjYXBhYmlsaXRpZXMgYW5kIGhvdyB0byBlbmdhZ2UgaW4gdGhlc2Ug ZWZmb3J0cy4gJm5ic3A7QW55b25lIGFjdGl2ZWx5IG9yIGludGVyZXN0ZWQgaW4gcGFydGljaXBh dGluZyBpbiBvciB1c2luZyBzdGFuZGFyZHMgZGV2ZWxvcGVkIGJ5IGludGVybmF0aW9uYWwgc3Rh bmRhcmRzIGRldmVsb3BtZW50IG9yZ2FuaXphdGlvbnMNCiAoU0RPcykgc2hvdWxkIGF0dGVuZC4g Jm5ic3A7UGFydGljaXBhbnRzIGFyZSBlbmNvdXJhZ2VkIHRvIHNoYXJlIHRoZWlyIHVzZSBjYXNl cyBhbmQgcmVxdWlyZW1lbnRzIGZvciBzZWN1cml0eSBhdXRvbWF0aW9uIHN0YW5kYXJkcy48L2Rp dj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIElUU0FD LCBwbGVhc2UgdmlzaXQ6IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0 dHBzOi8vaXRzYWMuZzJwbGFuZXQuY29tL2l0c2FjMjAxMiI+DQpodHRwczovL2l0c2FjLmcycGxh bmV0LmNvbS9pdHNhYzIwMTI8L2E+LiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlBs ZWFzZSBub3RlIHRoYXQgcmVtb3RlIGFjY2VzcyBjYXBhYmlsaXRpZXMgd2lsbCBub3QgYmUgcG9z c2libGUuPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JZiB0aGVyZSBpcyBzdWZmaWNp ZW50IGludGVyZXN0LCBJIHdpbGwgcHJvdmlkZSBhZGRpdGlvbmFsIGRldGFpbHMgb24gdGhlIHJv b20gbnVtYmVyIGFuZCBvdGhlciBsb2dpc3RpY3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5U aGFuayB5b3UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tSm9objwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGRpdj48ZGl2Pi0tPC9kaXY+PGRpdj5Kb2huIEJhbmdoYXJ0PC9kaXY+PGRpdj5Q cm9ncmFtIEFuYWx5c3Q8L2Rpdj48ZGl2PlByb2dyYW0gQ29vcmRpbmF0aW9uIE9mZmljZTwvZGl2 PjxkaXY+T2ZmaWNlIG9mIHRoZSBVbmRlciBTZWNyZXRhcnkgb2YgQ29tbWVyY2UgZm9yIFN0YW5k YXJkcyBhbmQgVGVjaG5vbG9neTwvZGl2PjxkaXY+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5k YXJkcyBhbmQgVGVjaG5vbG9neTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+KDMwMSkgOTc1LTgw ODU8L2Rpdj48ZGl2PjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpKb2huLmJhbmdoYXJ0QG5pc3QuZ292Ij5Kb2huLmJhbmdoYXJ0QG5pc3QuZ292PC9hPjwv ZGl2PjwvZGl2PjwvZGl2Pjxicj48ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVy Ij48L2ZpZWxkc2V0PiA8YnI+PHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptaWxlIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10 eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0 Zi5vcmc8L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PC9wcmU+PC9ibG9ja3F1b3RlPjxicj48L2Rpdj48L2Rp dj48L3NwYW4+PC9ib2R5PjwvaHRtbD4NCg== --_000_CC8622F34F8Fjohnbanghartnistgov_-- From john.banghart@nist.gov Mon Sep 24 12:26:34 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76C521F88AE; Mon, 24 Sep 2012 12:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 UWVG7BLe4PcU; Mon, 24 Sep 2012 12:26:30 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id AE5F021F88AD; Mon, 24 Sep 2012 12:26:30 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 15:26:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 24 Sep 2012 15:24:48 -0400 From: "Banghart, John" To: "Banghart, John" , "sacm@ietf.org" , "mile@ietf.org" Date: Mon, 24 Sep 2012 15:26:27 -0400 Thread-Topic: [mile] Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2aikL6gV4NdUTRQnyFuOkJdGgRYg== 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.4.120824 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC862BD74F9Fjohnbanghartnistgov_" MIME-Version: 1.0 Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 19:26:34 -0000 --_000_CC862BD74F9Fjohnbanghartnistgov_ Content-Type: text/plain; charset="us-ascii" Minor correction. I meant Wednesday the 3rd, which is the first day of the conference. -John From: , "Banghart, John" > Date: Monday, September 24, 2012 2:01 PM To: "sacm@ietf.org" >, "mile@ietf.org" > Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards. The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts. Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend. Participants are encouraged to share their use cases and requirements for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the room number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_CC862BD74F9Fjohnbanghartnistgov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48ZGl2Pk1pbm9yIGNvcnJlY3Rpb24uICZuYnNwO0kgbWVh bnQgV2VkbmVzZGF5IHRoZSAzcmQsIHdoaWNoIGlzIHRoZSBmaXJzdCBkYXkgb2YgdGhlIGNvbmZl cmVuY2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tSm9objwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJP UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJP UkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQ QURESU5HLVRPUDogM3B0Ij48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPiAmbHQ7QmFuZ2hhcnQmZ3Q7LCAiQmFuZ2hhcnQsIEpvaG4iICZsdDs8YSBocmVmPSJtYWls dG86am9obi5iYW5naGFydEBuaXN0LmdvdiI+am9obi5iYW5naGFydEBuaXN0LmdvdjwvYT4mZ3Q7 PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+IE1vbmRheSwg U2VwdGVtYmVyIDI0LCAyMDEyIDI6MDEgUE08YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOiA8L3NwYW4+ICI8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRm Lm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9y ZzwvYT4mZ3Q7LCAiPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8 L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPiBb bWlsZV0gVXBjb21pbmcgQm9GIGF0IHRoZSBJVCBTZWN1cml0eSBBdXRvbWF0aW9uIENvbmZlcmVu Y2U8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGRpdj48ZGl2Pkhl bGxvIGFsbCw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZXJlIHdpbGwgYmUgYSBiaXJkcy1v Zi1hLWZlYXRoZXIgKEJvRikgc2Vzc2lvbiBhdCB0aGUgdXBjb21pbmcgSVQgU2VjdXJpdHkgQXV0 b21hdGlvbiBDb25mZXJlbmNlIChJVFNBQykgaW4gQmFsdGltb3JlIG9uIFdlZG5lc2RheSwgT2N0 b2JlciA0dGgsIGZyb20gNTozMHBtIHRvIDY6MzBwbSwgZm9jdXNpbmcgb24gaW50ZXJuYXRpb25h bCBlZmZvcnRzIHRvIGRldmVsb3Agc2VjdXJpdHkgYXV0b21hdGlvbiBzdGFuZGFyZHMuICZuYnNw O1RoZSBCb0YNCiB3aWxsIGZvY3VzIG9uIHJldmlld2luZyBjdXJyZW50IGVmZm9ydHMgdG8gc3Rh bmRhcmRpemUgc2VjdXJpdHkgYXV0b21hdGlvbiBjYXBhYmlsaXRpZXMgYW5kIGhvdyB0byBlbmdh Z2UgaW4gdGhlc2UgZWZmb3J0cy4gJm5ic3A7QW55b25lIGFjdGl2ZWx5IG9yIGludGVyZXN0ZWQg aW4gcGFydGljaXBhdGluZyBpbiBvciB1c2luZyBzdGFuZGFyZHMgZGV2ZWxvcGVkIGJ5IGludGVy bmF0aW9uYWwgc3RhbmRhcmRzIGRldmVsb3BtZW50IG9yZ2FuaXphdGlvbnMNCiAoU0RPcykgc2hv dWxkIGF0dGVuZC4gJm5ic3A7UGFydGljaXBhbnRzIGFyZSBlbmNvdXJhZ2VkIHRvIHNoYXJlIHRo ZWlyIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBzZWN1cml0eSBhdXRvbWF0aW9uIHN0 YW5kYXJkcy48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+Rm9yIG1vcmUgaW5mb3JtYXRpb24g b24gdGhlIElUU0FDLCBwbGVhc2UgdmlzaXQ6IDxhIGhyZWY9Imh0dHBzOi8vaXRzYWMuZzJwbGFu ZXQuY29tL2l0c2FjMjAxMiI+aHR0cHM6Ly9pdHNhYy5nMnBsYW5ldC5jb20vaXRzYWMyMDEyPC9h Pi4gJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5QbGVhc2Ugbm90ZSB0aGF0IHJlbW90 ZSBhY2Nlc3MgY2FwYWJpbGl0aWVzIHdpbGwgbm90IGJlIHBvc3NpYmxlLjwvZGl2PjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+SWYgdGhlcmUgaXMgc3VmZmljaWVudCBpbnRlcmVzdCwgSSB3aWxs IHByb3ZpZGUgYWRkaXRpb25hbCBkZXRhaWxzIG9uIHRoZSByb29tIG51bWJlciBhbmQgb3RoZXIg bG9naXN0aWNzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmsgeW91LjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+LUpvaG48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+PGRpdj4t LTwvZGl2PjxkaXY+Sm9obiBCYW5naGFydDwvZGl2PjxkaXY+UHJvZ3JhbSBBbmFseXN0PC9kaXY+ PGRpdj5Qcm9ncmFtIENvb3JkaW5hdGlvbiBPZmZpY2U8L2Rpdj48ZGl2Pk9mZmljZSBvZiB0aGUg VW5kZXIgU2VjcmV0YXJ5IG9mIENvbW1lcmNlIGZvciBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8 L2Rpdj48ZGl2Pk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PigzMDEpIDk3NS04MDg1PC9kaXY+PGRpdj48YSBocmVm PSJtYWlsdG86Sm9obi5iYW5naGFydEBuaXN0LmdvdiI+Sm9obi5iYW5naGFydEBuaXN0Lmdvdjwv YT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L3NwYW4+PC9ib2R5PjwvaHRtbD4NCg== --_000_CC862BD74F9Fjohnbanghartnistgov_-- From john.banghart@nist.gov Tue Sep 25 05:22:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64A21F88A0; Tue, 25 Sep 2012 05:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sA-sQh+5N+2Q; Tue, 25 Sep 2012 05:22:10 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8886521F8871; Tue, 25 Sep 2012 05:22:10 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 25 Sep 2012 08:21:58 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 25 Sep 2012 08:20:25 -0400 From: "Banghart, John" To: Richard Adams , "sacm@ietf.org" , "mile@ietf.org" Date: Tue, 25 Sep 2012 08:22:04 -0400 Thread-Topic: [mile] Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2bGCQv0d9uRVOrRJmtOBdeRZ3DmQ== Message-ID: In-Reply-To: <00a401cd9a95$96e6dfd0$c4b49f70$@ewa-canada.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 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC871A0D5009johnbanghartnistgov_" MIME-Version: 1.0 Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 12:22:12 -0000 --_000_CC871A0D5009johnbanghartnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richard, No problem at all. I think the discussion can be as broad as the group lik= es, assuming it is cybersecurity related. -John From: Richard Adams > Organization: EWAC Date: Monday, September 24, 2012 4:45 PM To: "Banghart, John" = >, "sacm@ietf.org" >, "mile@ietf.org" > Subject: RE: [mile] Upcoming BoF at the IT Security Automation Conference Hi John, I have a quick question regarding this; do you know how specific the talk w= ill be? Will there be any mention of the =93new=94 ITSG-33 that we Canadia= ns are about to put out? I apologize if this question is out of sorts, I h= aven=92t been keeping up with the lists as much as I=92d like. Thanks. Richee From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Banghart, John Sent: September-24-12 3:26 PM To: Banghart, John; sacm@ietf.org; mile@ietf.org Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Minor correction. I meant Wednesday the 3rd, which is the first day of the= conference. -John From: , "Banghart, John" > Date: Monday, September 24, 2012 2:01 PM To: "sacm@ietf.org" >, "mile@ietf.org" > Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Securit= y Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, fro= m 5:30pm to 6:30pm, focusing on international efforts to develop security a= utomation standards. The BoF will focus on reviewing current efforts to st= andardize security automation capabilities and how to engage in these effor= ts. Anyone actively or interested in participating in or using standards d= eveloped by international standards development organizations (SDOs) should= attend. Participants are encouraged to share their use cases and requirem= ents for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com= /itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the r= oom number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_CC871A0D5009johnbanghartnistgov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Richard,

No problem at all.  I think the discussion can be as broad as the g= roup likes, assuming it is cybersecurity related.

= -John

From: Richard Adams <radams@ewa-ca= nada.com>
Organization: = EWAC
Date: Monday, September 24= , 2012 4:45 PM
To: "Bangha= rt, John" <john.banghart@= nist.gov>, "sacm@ietf.org&= quot; <sacm@ietf.org>, "mile@ietf.org" <mile@ietf.org>
S= ubject: RE: [mile] Upcoming BoF at the IT Security Automation Confe= rence

Hi John,

 

I have a quick question regarding this; do you know how spe= cific the talk will be?  Will there be any mention of the =93new=94 IT= SG-33 that we Canadians are about to put out?  I apologize if this question is out of sorts, I ha= ven=92t been keeping up with the lists as much as I=92d like.

 <= /span>

Thanks.

&nb= sp;

Richee=

<= span lang=3D"EN-US" style=3D"font-size: 10pt; font-family: Tahoma, sans-ser= if; ">From: mile= -bounces@ietf.org [mailto:mile= -bounces@ietf.org] On Behalf Of Banghart, John
Sent: September-24-12 3:26 PM<= br>To: Banghart, John; sacm@ietf.or= g; mile@ietf.org
Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference

 

<= p class=3D"MsoNormal">Minor correction.  I meant Wednesday th= e 3rd, which is the first day of the conference.

 

-John

 

<= p class=3D"MsoNormal">From: <Banghart>, "Banghart, John" <john.banghart@nist.gov>
Dat= e: Monday, September 24, 2012 2:01 PM
To: "sacm@ietf.org" <sacm@ietf.org>, "mile@ie= tf.org" <mile@ietf.org>=
Subject: [mile] Upcoming BoF at the IT Security Automation Confe= rence

=  

Hello all,

 

 =

For more information = on the ITSAC, please visit: https://itsac.g2planet.com= /itsac2012.  

 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri, sans-s= erif; ">Please note that remote access capabilities will not be possible.

&= nbsp;

If there i= s sufficient interest, I will provide additional details on the room number= and other logistics.

 

Thank you.

 

 

--

Jo= hn Banghart

Program Analyst

Program Coordination Office

Office of the Under Secretary of Commerce for Stand= ards and Technology

= National Institute of Standards and Technology

 

(301) 975-8085

 --_000_CC871A0D5009johnbanghartnistgov_-- From ramartin@mitre.org Tue Sep 25 06:15:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C659C21F847C for ; Tue, 25 Sep 2012 06:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7mCkm0e64Do for ; Tue, 25 Sep 2012 06:15:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BD16621F845D for ; Tue, 25 Sep 2012 06:15:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2CCC021B0962; Tue, 25 Sep 2012 09:15:28 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1348421B0851; Tue, 25 Sep 2012 09:15:28 -0400 (EDT) Received: from mm169528-pc.mitre.org (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 25 Sep 2012 09:15:27 -0400 Message-ID: <5061AE6F.6050104@mitre.org> Date: Tue, 25 Sep 2012 09:15:27 -0400 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "Waltermire, David A." , "Baker, Jon" , "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:15:30 -0000 Hi Kathleen, Regarding your statement "I believe the full content was included in these Recommendations (5 total Recommendations), is that correct?" No. The normative portions are references to the 4 NIST IRs - in the same manner as was done for IODEF, RID, RID-T, and XCCDF. If you Google x.cpe.1, x.cpe.2, x.cpe.3, and x.cpe.4 you will find links to the four documents and their summary sections that state the approach taken. Specifically for X.1528.1 (ex X.cpe.1): "...This is achieved by listing the relevant clauses of the NIST Interagency Report 7696 Common Platform Enumeration: Name Matching Specification version 2.3 and showing whether they are normative or informative." Specifically for X.1528.2 (ex X.cpe.2): "...This is achieved by listing the relevant clauses of the NIST Interagency Report 7696 Common Platform Enumeration: Name Matching Specification version 2.3 and showing whether they are normative or informative." Specifically for X.1528.3 (ex X.cpe.3): "...This is achieved by listing the relevant clauses of the NIST Interagency Report 7697 Common Platform Enumeration: Name Matching Specification version 2.3 and showing whether they are normative or informative." Specifically for X.1528.4 (ex X.cpe.4): "...This is achieved by listing the relevant clauses of the NIST Interagency Report 7698: Common Platform Enumeration Applicability Language Specification version 2.3 and showing whether they are normative or informative." Regards, Bob On 9/23/12 11:14 AM, Moriarty, Kathleen wrote: > Hi Jon, > > With the recent approval of CPE specifications by the ITU-T, these are now formal recommendations and I believe the full content was included in these Recommendations (5 total Recommendations), is that correct? If the group were to select either CPE or SWID, it would need to be by reference now, correct? > > Best regards, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Baker, Jon > Sent: Sunday, September 23, 2012 5:59 AM > To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] SACM BoF Request > > Also, I noticed the following: > >> - A Standards Track document specifying platform naming >> - A Standards Track document specifying platform matching >> - A Standards Track document specifying platform applicability > > Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicability Language. Has the group considered the SWID specification (ISO/IEC 19770-2). The following page and its referenced document may be of help in considering how cpe and swids fit together: > > http://tagvault.org/Automating_CPE_name_creation > > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Moriarty, Kathleen >> Sent: Friday, September 21, 2012 4:32 PM >> To: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >> >> Hello, >> >> I am including an updated version of the SACM Charter that includes more of >> an emphasis on the protocols to share and exchange data within and between >> enterprises/organizations. Please feel free to provide feedback to the list! >> >> Thanks & have a good weekend! >> Kathleen >> >> >> >> BOF full name: Security Automation and Continuous Monitoring [SACM] >> AREA: Security >> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >> Agenda: >> >> * Review the draft charter >> * Review draft-waltermire-sacm-use-cases-02 >> * Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >> Full Description of BOF: The SACM BoF is intended to progress the work from >> the SACM mailing list to solidify discussions on a proposed charter, use cases >> and milestones in support of moving to an IETF working group. >> >> CONFLICTS to avoid: SAAG, MILE >> Expected Attendance: 40, not sure what the previous attendance was? >> Special Requests: Meetecho support >> Number of sessions: 1 >> Length of session: 2 hours >> >> Draft Charter: >> >> Proposed Working Group Charter >> >> Chairs: >> TBD >> TBD >> >> Security Area Directors: >> Stephen Farrell >> Sean Turner >> >> Security Area Advisor: >> Sean Turner >> >> Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >> Description of Working Group >> >> Securing information and the systems that store, process, and transmit that >> information has become a challenging task for organizations of all sizes, and >> we find that security practitioners spend most of their time on manual >> processes relegating them to ineffectiveness. Security automation to verify >> system configurations with the ability to prioritize risk based on increased >> situational awareness from shared intelligence is the key to escaping this rut. >> This working group will develop security automation protocols and data >> format standards in support of information security processes and practices >> where practical. These standards will help security practitioners to be better >> utilized within their organizations by automating routine tasks related to >> endpoint and server security so that practitioners can focus on more >> advanced tasks. The initial focus of this work is to address enterprise use >> cases. >> >> The working group will achieve this by enabling the exchange of shared >> intelligence and continuing the security automation work already performed >> by various organizations around the world. The initial work has been fruitful, >> and the data formats previously published are ready for expansion on the >> international stage. Of particular interest to this working group are the >> security automation specifications supporting asset, change, configuration, >> and vulnerability management. Of additional interest to this working group >> are the emerging security automation interfaces and data formats relating to >> event management and continuous assessment. The continuous assessment >> capabilities enable organizational situational awareness through frequent >> snapshots of the operating state of their environment, with risk prioritized >> based on consumed information provided by shared intelligence >> (vulnerabilities, threats, etc.). >> >> By undertaking this work, we recognize that there are multiple categories of >> problems in the security automation domain: enabling interoperable data >> exchanges through standardized protocols, defining expressions for particular >> domain concepts (i.e. data formats), establishing a standards-based >> foundation supporting the curation and exchange of security automation >> content collections in content repositories, and enabling interoperability >> through the development and use of standard interfaces and communications >> protocols. Content based on rich data standards and protocols will provide the >> authoritative instructions needed by data-driven tools to enable the >> automated collection and exchange of configuration and vulnerability data >> pertaining to enterprise assets. Information produced by these tools will >> provide accurate and timely situational awareness in support of organizational >> decision making. >> >> The data exchange protocols will need to meet several exchange types >> including those between and within organizations for sharing intelligence data >> to increase situational awareness, report exchanges both internal and >> external to an enterprise, and those between enterprise servers and end >> points for assessments >> >> This working group will provide solutions to these categories of problems and >> the main areas of focus for this working group are described as follows: >> >> 1. Define, either by normative reference, adoption, or creation, a set of >> standards to enable the exchange of data to increase situational awareness or >> gain access to shared content to improve the security posture of an >> enterprise. This area of focus provides for the integration of interoperable >> protocols to access shared data repositories between organizations to >> increase situational awareness and reduce risks to an enterprise. In support >> of accessing shared intelligence for expected system state and related risks, >> define, either by normative reference, adoption, or creation, a set of >> standards that can be used for the purpose of assessing and aggregating >> device states and comparing these device states against expected values, and >> reporting on those results in a predefined or ad hoc manner. This area of >> focus provides for necessary language and data format specifications. >> >> 3. Define, either by normative reference, adoption, or creation, a set of >> standards that can be used to continuously assess and report on the state of >> systems, composed of many different types of devices and networks, >> operated by varying personnel, to ensure security process effectiveness in a >> pre-defined or ad-hoc manner. This area of focus provides for integration >> protocols supporting plug and play continuous assessment and security >> automation networking within an enterprise. >> >> This working group will achieve the following milestones in two phases: >> >> Phase One >> - A standards track document to define a protocol for interacting with content >> repositories >> - Standards Track document specifying security automation/continuous >> assessment interfaces >> - A Standards Track document specifying communication protocols used for >> security automation and continuous assessment >> - A Standards Track document describing the messages and network protocols >> for distributing security automation content (content repository) >> - A Standards Track document describing protocols and data formats for >> securely sharing dynamic network state information among security systems >> - A Standards Track document specifying asset description format >> - A Standards Track document specifying asset identification >> - A Standards Track document specifying platform naming >> - A Standards Track document specifying platform matching >> - A Standards Track document specifying platform applicability >> >> Phase Two >> - A Standards Track document specifying a control framework representation >> format. >> - A Standards Track document specifying benchmark configuration >> representation >> - An Informational document stating guidelines / requirements for specifying >> checking languages >> - Standards Track documents specifying device state checking languages >> - A Standards Track document specifying an interrogative checking language >> - A Standards Track document specifying asset reporting information >> - Standards Track document describing how to use the languages and other >> content defined in this group with the NEA protocols >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > . > From john.banghart@nist.gov Tue Sep 25 07:59:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C572E21F884F; Tue, 25 Sep 2012 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rMagGaQmzjhy; Tue, 25 Sep 2012 07:59:42 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4133E21F8841; Tue, 25 Sep 2012 07:59:36 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 25 Sep 2012 10:59:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 25 Sep 2012 10:57:29 -0400 From: "Banghart, John" To: Richard Adams Date: Tue, 25 Sep 2012 10:59:13 -0400 Thread-Topic: [mile] Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2bLhXFkrWUoQaXQ96WSX5hPL10+w== Message-ID: References: <00a401cd9a95$96e6dfd0$c4b49f70$@ewa-canada.com> <005401cd9b2d$f781e090$e685a1b0$@ewa-canada.com> In-Reply-To: <005401cd9b2d$f781e090$e685a1b0$@ewa-canada.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_A9D339F8A4AF4144A7767B1E3AF025EDnistgov_" MIME-Version: 1.0 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:59:43 -0000 --_000_A9D339F8A4AF4144A7767B1E3AF025EDnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richee, Well, I guess it's me unless someone else wants to volunteer. :) -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov On Sep 25, 2012, at 10:56 AM, Richard Adams wrote: John, Is it possible to get the name of the individual that will be moderating th= is meeting? Thanks. Richee From: Banghart, John [mailto:john.banghart@nist.gov] Sent: September-25-12 8:22 AM To: Richard Adams; sacm@ietf.org; mile@ietf.org Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Richard, No problem at all. I think the discussion can be as broad as the group lik= es, assuming it is cybersecurity related. -John From: Richard Adams > Organization: EWAC Date: Monday, September 24, 2012 4:45 PM To: "Banghart, John" = >, "sacm@ietf.org" >, "mile@ietf.org" > Subject: RE: [mile] Upcoming BoF at the IT Security Automation Conference Hi John, I have a quick question regarding this; do you know how specific the talk w= ill be? Will there be any mention of the =93new=94 ITSG-33 that we Canadia= ns are about to put out? I apologize if this question is out of sorts, I h= aven=92t been keeping up with the lists as much as I=92d like. Thanks. Richee From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Banghart, John Sent: September-24-12 3:26 PM To: Banghart, John; sacm@ietf.org; mile@ietf.org Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Minor correction. I meant Wednesday the 3rd, which is the first day of the= conference. -John From: , "Banghart, John" > Date: Monday, September 24, 2012 2:01 PM To: "sacm@ietf.org" >, "mile@ietf.org" > Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Securit= y Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, fro= m 5:30pm to 6:30pm, focusing on international efforts to develop security a= utomation standards. The BoF will focus on reviewing current efforts to st= andardize security automation capabilities and how to engage in these effor= ts. Anyone actively or interested in participating in or using standards d= eveloped by international standards development organizations (SDOs) should= attend. Participants are encouraged to share their use cases and requirem= ents for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com= /itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the r= oom number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_A9D339F8A4AF4144A7767B1E3AF025EDnistgov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richee,

Well, I guess it's me unless someone else wants to volunteer.  :)

--
John Banghart
Program Analyst
Program Coordination Of= fice
Natio= nal Institute of Standards and Technology

(301) 975-8085

On Sep 25, 2012, at 10:56 AM, Richard Adams wrote:

John,
 
Is it possible to get the name of the individual that will= be moderating this meeting?
 
Thanks.
 
Richee
=  
Fr= om: Ban= ghart, John [mailto:john.banghart@nist.gov] 
Sent:&n= bsp;September-25-12 8:22 AM
To: Richard Adams; sacm@ietf.org; mile@ietf.org
Subject: Re: [mile] Upcoming BoF at the IT S= ecurity Automation Conference
&nbs= p;
Richard,
 
No problem at all= .  I think the discussion can be as broad as the group likes, assuming= it is cybersecurity related.
=  
-John<= /div>
 
 Richard Adams <radams@ewa-canada.com>
Or= ganization: EWAC
<= b>Date: Monday, Septe= mber 24, 2012 4:45 PM
To: = "Banghart, John" <john.banghart@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>, = "mile@ietf.org" <mile@ietf.org>
Sub= ject: RE: [mile] Upco= ming BoF at the IT Security Automation Conference
 
Hi John,<= /span>
 
I have a quick quest= ion regarding this; do you know how specific the talk will be?  Will t= here be any mention of the =93new=94 ITSG-33 that we Canadians are about to= put out?  I apologize if this question is out of sorts, I haven=92t b= een keeping up with the lists as much as I=92d like.
 
Thanks.
 
Richee=
 =
From: mile= -bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, John
Sent: September-24-12 3:26 PM
To: Banghart, John; sacm@ietf.org; mile@ietf.org
Subj= ect: Re: [mile] Upcom= ing BoF at the IT Security Automation Conference
 
Minor correction.  I = meant Wednesday the 3rd, which is the first day of the conference.
=  
<= div>
-John=
 
From: <Banghart>, "Banghart, John" = <john.banghart@nist.gov>
Date: Monday, September 24, 2012 2:0= 1 PM
To: "sacm@ietf.org" <sacm@ietf.org>, "mil= e@ietf.org" <mile@ietf.org>
Subject: [mile] Upcoming BoF at the IT= Security Automation Conference<= /o:p>
 
Hello a= ll,
 
There will be a birds-of-a-feather (BoF) session a= t the upcoming IT Security Automation Conference (ITSAC) in Baltimore on We= dnesday, October 4th, from 5:30pm to 6:30pm, focusing on international effo= rts to develop security automation standards.  The BoF will focus on r= eviewing current efforts to standardize security automation capabilities an= d how to engage in these efforts.  Anyone actively or interested in pa= rticipating in or using standards developed by international standards deve= lopment organizations (SDOs) should attend.  Participants are encourag= ed to share their use cases and requirements for security automation standa= rds.
 <= /div>
For more information on the ITSAC, please visit:<= span class=3D"Apple-converted-space"> https://itsac.g2planet.com/itsac2012.  
 
Pl= ease note that remote access capabilities will not be possible.
If there is sufficient interest, I will provide additional = details on the room number and other logistics.
 
Thank = you.
 <= /div>
-John<= /o:p>
 
--
= John Banghart
=
Program Coordination Office
Office of the Under Secretary of Commerce for Standards and Technology<= /span>
National Institute of Standards and Technology
 <= span style=3D"color: black; ">
= (301) 975-8085
John.banghart@nist.gov<= span style=3D"color: black; ">

= = --_000_A9D339F8A4AF4144A7767B1E3AF025EDnistgov_-- From john.banghart@nist.gov Tue Sep 25 08:02:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F521F88E6; Tue, 25 Sep 2012 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 q2EYK3cSp5KZ; Tue, 25 Sep 2012 08:02:09 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC4A21F887B; Tue, 25 Sep 2012 08:02:07 -0700 (PDT) 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.1.379.0; Tue, 25 Sep 2012 11:01:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 25 Sep 2012 11:00:00 -0400 From: "Banghart, John" To: Richard Adams Date: Tue, 25 Sep 2012 11:01:44 -0400 Thread-Topic: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2bLm+QgU0ejbTETJevvvKrckUfxw== Message-ID: <3C4B0547-AFB4-408D-B308-61828C153E67@nist.gov> References: <00a401cd9a95$96e6dfd0$c4b49f70$@ewa-canada.com> <005401cd9b2d$f781e090$e685a1b0$@ewa-canada.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_3C4B0547AFB4408DB30861828C153E67nistgov_" MIME-Version: 1.0 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:02:10 -0000 --_000_3C4B0547AFB4408DB30861828C153E67nistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, Not picking on Richard, but to save everyone's Inbox, let's stop cross-post= ing unless you want to discuss topic relevant things for the BoF. Any admi= nistrative questions can be directed to me. Thanks! -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov On Sep 25, 2012, at 10:59 AM, Banghart, John wrote: Richee, Well, I guess it's me unless someone else wants to volunteer. :) -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov On Sep 25, 2012, at 10:56 AM, Richard Adams wrote: John, Is it possible to get the name of the individual that will be moderating th= is meeting? Thanks. Richee From: Banghart, John [mailto:john.banghart@nist.gov] Sent: September-25-12 8:22 AM To: Richard Adams; sacm@ietf.org; mile@ietf.org Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Richard, No problem at all. I think the discussion can be as broad as the group lik= es, assuming it is cybersecurity related. -John From: Richard Adams > Organization: EWAC Date: Monday, September 24, 2012 4:45 PM To: "Banghart, John" = >, "sacm@ietf.org" >, "mile@ietf.org" > Subject: RE: [mile] Upcoming BoF at the IT Security Automation Conference Hi John, I have a quick question regarding this; do you know how specific the talk w= ill be? Will there be any mention of the =93new=94 ITSG-33 that we Canadia= ns are about to put out? I apologize if this question is out of sorts, I h= aven=92t been keeping up with the lists as much as I=92d like. Thanks. Richee From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Banghart, John Sent: September-24-12 3:26 PM To: Banghart, John; sacm@ietf.org; mile@ietf.org Subject: Re: [mile] Upcoming BoF at the IT Security Automation Conference Minor correction. I meant Wednesday the 3rd, which is the first day of the= conference. -John From: , "Banghart, John" > Date: Monday, September 24, 2012 2:01 PM To: "sacm@ietf.org" >, "mile@ietf.org" > Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Securit= y Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, fro= m 5:30pm to 6:30pm, focusing on international efforts to develop security a= utomation standards. The BoF will focus on reviewing current efforts to st= andardize security automation capabilities and how to engage in these effor= ts. Anyone actively or interested in participating in or using standards d= eveloped by international standards development organizations (SDOs) should= attend. Participants are encouraged to share their use cases and requirem= ents for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com= /itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the r= oom number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_3C4B0547AFB4408DB30861828C153E67nistgov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All,

No= t picking on Richard, but to save everyone's Inbox, let's stop cross-postin= g unless you want to discuss topic relevant things for the BoF.  Any a= dministrative questions can be directed to me.

Tha= nks!

 
--
John Banghart
Program Analyst
Program Coordination Of= fice
Natio= nal Institute of Standards and Technology

(301) 975-8085

On Sep 25, 2012, at 10:59 AM, Banghart, John wrote:

Richee,

Well, I guess it's me unless som= eone else wants to volunteer.  :)

--
John Banghart
Program Analyst
Program Coordination Office
Office of the Unde= r Secretary of Commerce for Standards and Technology
National Institute of Sta= ndards and Technology

(301) 975-8085

No problem at all= .  I think the discussion can be as broad as the group likes, assuming= it is cybersecurity related.
=  
-John<= /div>
 
 Richard Adams <radams@ewa-canada.com>
Or= ganization: EWAC
<= b>Date: Monday, Septe= mber 24, 2012 4:45 PM
To: = "Banghart, John" <john.banghart@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>, = "mile@ietf.org" <mile@ietf.org>
Sub= ject: RE: [mile] Upco= ming BoF at the IT Security Automation Conference
 
Hi John,<= /span>
 
I have a quick quest= ion regarding this; do you know how specific the talk will be?  Will t= here be any mention of the =93new=94 ITSG-33 that we Canadians are about to= put out?  I apologize if this question is out of sorts, I haven=92t b= een keeping up with the lists as much as I=92d like.
 
Thanks.
 
Richee=
 =
From: mile= -bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, John
Sent: September-24-12 3:26 PM
To: Banghart, John; sacm@ietf.org; mile@ietf.org
Subj= ect: Re: [mile] Upcom= ing BoF at the IT Security Automation Conference
 
Minor correction.  I = meant Wednesday the 3rd, which is the first day of the conference.
=  
<= div>
-John=
 
From: <Banghart>, "Banghart, John" = <john.banghart@nist.gov>
Date: Monday, September 24, 2012 2:0= 1 PM
To: "sacm@ietf.org" <sacm@ietf.org>, "mil= e@ietf.org" <mile@ietf.org>
Subject: [mile] Upcoming BoF at the IT= Security Automation Conference<= /o:p>
 
Hello a= ll,
 
There will be a birds-of-a-feather (BoF) session a= t the upcoming IT Security Automation Conference (ITSAC) in Baltimore on We= dnesday, October 4th, from 5:30pm to 6:30pm, focusing on international effo= rts to develop security automation standards.  The BoF will focus on r= eviewing current efforts to standardize security automation capabilities an= d how to engage in these efforts.  Anyone actively or interested in pa= rticipating in or using standards developed by international standards deve= lopment organizations (SDOs) should attend.  Participants are encourag= ed to share their use cases and requirements for security automation standa= rds.
 <= /div>
For more information on the ITSAC, please visit:<= span class=3D"Apple-converted-space"> https://itsac.g2planet.com/itsac2012.  
 
Pl= ease note that remote access capabilities will not be possible.
If there is sufficient interest, I will provide additional = details on the room number and other logistics.
 
Thank = you.
 <= /div>
-John<= /o:p>
 
--
= John Banghart
=
Program Coordination Office
Office of the Under Secretary of Commerce for Standards and Technology<= /span>
National Institute of Standards and Technology
 <= span style=3D"color: black; ">
= (301) 975-8085
John.banghart@nist.gov<= span style=3D"color: black; ">

=
<ATT00001..c>

<= /html>= --_000_3C4B0547AFB4408DB30861828C153E67nistgov_-- From turners@ieca.com Tue Sep 25 08:07:03 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBB11F0C54 for ; Tue, 25 Sep 2012 08:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 BBTqc106T9pK for ; Tue, 25 Sep 2012 08:07:03 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.142.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB121F042A for ; Tue, 25 Sep 2012 08:07:03 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 50C412864A908; Tue, 25 Sep 2012 10:07:03 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 45BB72864A8C8 for ; Tue, 25 Sep 2012 10:07:03 -0500 (CDT) Received: from [108.18.174.220] (port=49408 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGWj0-00031b-9q; Tue, 25 Sep 2012 10:07:02 -0500 Message-ID: <5061C895.8080808@ieca.com> Date: Tue, 25 Sep 2012 11:07:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Davidson II, Mark S" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:49408 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "david.oliva@verizon.net" , "sacm@ietf.org" , Adam Montville Subject: Re: [sacm] ASR RFC Questions X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:07:04 -0000 On 9/24/12 10:31 AM, Adam Montville wrote: > From: "", Mark S > > Date: Monday, September 24, 2012 7:23 AM > To: "sacm@ietf.org " > > Cc: "david.oliva@verizon.net " > > > Subject: [sacm] ASR RFC Questions > > All, > > First, a couple of notes: > > ASR NIST IR: > http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nistir_7848.pdf > > I am currently using NRoffEdit to create the ASR. > > As David and I work through the draft RFC for ASR, I have some > questions for the group: Friendly AD jumping in :) General reminder to you and all: Please make sure to read and follow the NOTE WELL on the submission page: https://datatracker.ietf.org/submit/note-well/ > 0. Is the draft’s deadline 10/15? > > > > One of the BoF chairs would know for sure, but I believe that is correct. Cutoff for -00 version is 10/15. > > 1. In the case that a contributor does not represent an > organization, what is the appropriate text that would go in place of > the organization? > > > I don't really know the answer, but there are others on this list who > probably do. On the front page do something like the following if they're listed last: Author 1 Author Org Author Name October 15, 2012 If they're not listed last then use a blank line like: Author Name Author 2 Author Org October 15, 2012 In the Author' addresses section at a minimum name and email address are needed. This reminds me though that not all authors need to be listed on the front page. If there's really just one editor you can list your name, put (ed.) next to it, and then have a contributors section where you also list the other authors. Like s8 in: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's no hard and fast rule but try to keep the # of authors on the front low. Nobody wants the boiler plate to take two pages ;) > 2. ASR has a few tables (notably tables 6-1 through 6-12). What is > the best way to represent these tables in RFC format? > > > > This depends on the complexity of the tables. I don't know about > creating tables using the Nroff editor, just XML. When all else fails, > using something that helps create ascii diagrams is useful (UltraEdit or > http://www.asciiflow.com). ascii art is your friend ;) Do the best you can, but I normally just do it by hand +----------------+----------------+----------------+ | Column Heading | Column Heading | Column Heading | +----------------+----------------+----------------+ | Entry | Entry | Entry | +----------------+----------------+----------------+ | Entry | Entry | Entry | +----------------+----------------+----------------+ ... > 3. Is it worth sharing the NRoffEdit file in this forum before > posting as a draft, or should it just be posted as a draft when ready? > > > I would just post it. That's what I did for the AI transformation. I'd just post it too. Once it's posted then when you do edits everyone can use the tools to see what's changed from version to version. But, do run the nits checker on it so your (if you have any) will stop fall out when the submission tool kicks it back for odd errors you didn't know about: https://tools.ietf.org/tools/idnits/ > The conversion to RFC is mostly complete, though I’m sure there will > be plenty of topics to address within the draft. The major work left > to be done is creating the data model tables in the RFC. > > > Outstanding! Thanks for your collective efforts! +1 The best way to get work done is to do it and then submit it. spt > Thank you. > > Mark Davidson > > MDavidson@MITRE.org > > Information Security Engineer > > G022 - Information Assurance > > The MITRE Corporation > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Tue Sep 25 08:42:22 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51E21F8852 for ; Tue, 25 Sep 2012 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 6KY4kMo6vmPc for ; Tue, 25 Sep 2012 08:42:21 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [74.52.222.226]) by ietfa.amsl.com (Postfix) with ESMTP id 022A121F87FC for ; Tue, 25 Sep 2012 08:42:20 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id D7FA921377A80; Tue, 25 Sep 2012 10:42:20 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id C611D21377A5C for ; Tue, 25 Sep 2012 10:42:20 -0500 (CDT) Received: from [108.18.174.220] (port=49512 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGXH9-0006oz-Q7; Tue, 25 Sep 2012 10:42:20 -0500 Message-ID: <5061D0DB.7090501@ieca.com> Date: Tue, 25 Sep 2012 11:42:19 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Michael Hammer References: <19195004.2782837.1347466639484.JavaMail.root@vznit170136> <69F1FC52EB080B4983863BD1602520D80BD1D17A@IMCMBX02.MITRE.ORG> <69F1FC52EB080B4983863BD1602520D80BD1E9AA@IMCMBX02.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB319DB61AB@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB319DB61AB@ex2k10mb2.corp.yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:49512 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "david.oliva@verizon.net" , "mdavidson@mitre.org" , "sacm@ietf.org" , "david.waltermire@nist.gov" Subject: Re: [sacm] FW: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:42:22 -0000 A direct link to the tao: https://www.ietf.org/tao.html And feel free to ask questions. spt On 9/13/12 2:07 PM, Michael Hammer wrote: > All, > > I have seen a couple mentions of “new to IETF”, so was looking for the > “Tau of the IETF” document which is on this first link: > > http://www.ietf.org/newcomers.html > > But note also these as well: > > http://www.ietf.org/about/process-docs.html > > http://www.ietf.org/edu/process-oriented-tutorials.html > > http://tools.ietf.org/ > > Hope that helps. > > Mike > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Davidson II, Mark S > *Sent:* Thursday, September 13, 2012 1:49 PM > *To:* Waltermire, David A.; david.oliva@verizon.net; sacm@ietf.org > *Subject:* Re: [sacm] FW: SACM BoF Request > > Thank you. I’m happy to work with David Oliva on this. > > What is the proper procedure for drafting the RFC? I’m new to the IETF, > so direction will be beneficial. Also, what would the group need from a > dates/deliverables perspective? > > If it’s acceptable, I’ll work offline with David O. and come back to the > group at regular intervals as the schedule demands. > > Thank you. > > -Mark > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > > *Sent:* Thursday, September 13, 2012 7:53 AM > *To:* Davidson II, Mark S; david.oliva@verizon.net > ; sacm@ietf.org > *Subject:* RE: [sacm] FW: SACM BoF Request > > Mark, > > That would be great! Thank you for volunteering. > > Sincerely, > > Dave > > *From:*Davidson II, Mark S [mailto:mdavidson@mitre.org] > > *Sent:* Wednesday, September 12, 2012 3:58 PM > *To:* david.oliva@verizon.net ; > Waltermire, David A.; sacm@ietf.org > *Subject:* RE: [sacm] FW: SACM BoF Request > > My apologies for the late response, I didn’t get to this email until > just now. > > As an original author for the ASR spec, I’d like to participate in > bringing ASR to the IETF. Is that a possibility? > > Thank you. > > -Mark Davidson > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of *david.oliva@verizon.net > > *Sent:* Wednesday, September 12, 2012 12:17 PM > *To:* david.waltermire@nist.gov ; > sacm@ietf.org > *Subject:* Re: [sacm] FW: SACM BoF Request > > David: > > I would like to take on ASR (I pressume you are talking about IR 7848 > for future SCAP/SACM versions). > > Which in fact, brings up a question. > > In terms of maturity, how do you know which Interagency Reports will be > part of future SACM/SCAP versions? > > David Oliva > > On 09/12/12, Waltermire, David A. > wrote: > > I sent in a request to hold a SACM BoF at the IETF 85 meeting in > Atlanta, GA. The details are below for anyone interested. At this > point we need to complete preparations for the BoF. To be successful, > we will need your participation in the BoF and your help getting ready. > > Here are meeting details if you are interested in making travel > arrangements: > > http://www.ietf.org/meeting/85/index.html > > At this point we need additional drafts to be submitted to augment the > agenda and support the BoF. I’d be happy to work with anyone interested > in preparing drafts for any of the existing specifications in this area > (e.g. CPE, Asset Identification, ARF, ASR, etc.) We should probably do > a direct conversion of existing specifications for -00 versions before > making any changes. The -00 deadline for the IETF 85 meeting is 10/15 > with any updated drafts due a week later on 10/22. Any volunteers? > > We will also need speakers to present drafts. Please let me or Kathleen > know if you are interested in making a short presentation. > > We also need to continue to refine the charter (included below) and use > case documents. Any additional comments/changes would be appreciated. > > Sincerely, > > Dave > > *From:*Waltermire, David A. > *Sent:* Monday, September 10, 2012 6:45 PM > *To:* 'stephen.farrell@cs.tcd.ie '; > 'turners@ieca.com '; 'Moriarty, Kathleen' > *Subject:* SACM BoF Request > > Please find the our request for a WG formation BoF below. I have also > included a draft charter that we have been developing with feedback from > the SACM list. Please let me know if you have any questions or if you > would like any additional details. > > Sincerely, > > Dave Waltermire > > -- > > BOF full name: Security Automation and Continuous Monitoring [SACM] > > AREA: Security > > BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com > ) > > David Waltermire (david.waltermire@nist.gov > ) > > Agenda: > > * Review the draft charter > > * Review draft-waltermire-sacm-use-cases-02 > > * Review drafts submitted in support of the charter > > - draft-waltermire-content-repository-00 > > - More expected before -00 deadline > > Full Description of BOF: The SACM BoF is intended to progress the work > from the SACM mailing list to solidify discussions on a proposed > charter, use cases and milestones in support of moving to an IETF > working group. > > CONFLICTS to avoid: SAAG, MILE > > Expected Attendance: 40, not sure what the previous attendance was? > > Special Requests: Meetecho support > > Number of sessions: 1 > > Length of session: 2 hours > > Draft Charter: > > Proposed Working Group Charter > > Chairs: > > TBD > > TBD > > Security Area Directors: > > Stephen Farrell > > > Sean Turner > > > Security Area Advisor: > > Sean Turner > > > Mailing Lists: > > General Discussion: sacm@ietf.org > > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > > Archive: http://www.ietf.org/mail-archive/web/sacm > > Description of Working Group > > Securing information and the systems that store, process, and transmit > that information has become a challenging task for organizations of all > sizes, and we find that security practitioners spend most of their time > on manual processes relegating them to ineffectiveness. Security > automation to verify system configurations with the ability to > prioritize risk based on increased situational awareness from shared > intelligence is the key to escaping this rut. This working group will > develop security automation standards in support of information security > processes and practices where practical. These standards will help > security practitioners to be better utilized within their organizations > by automating routine tasks related to endpoint and server security so > that practitioners can focus on more advanced tasks. The initial focus > of this work is to address enterprise use cases. > > The working group will achieve this by consuming shared intelligence and > continuing (with cooperation) the security automation work already > performed by various organizations around the world. The initial work > has been fruitful, and the data formats previously published are ready > for expansion on the international stage. Of particular interest to this > working group are the security automation specifications supporting > asset, change, configuration, and vulnerability management. Of > additional interest to this working group are the emerging security > automation interfaces and data formats relating to event management and > continuous assessment. The continuous assessment capabilities enable > organizational situational awareness through frequent snapshots of the > operating state of their environment, with risk prioritized based on > consumed information provided by shared intelligence (vulnerabilities, > threats, etc.). > > By undertaking this work, we recognize that there are multiple > categories of problems in the security automation domain: defining > expressions for particular domain concepts (i.e. data formats), > establishing a standards-based foundation supporting the curation and > exchange of security automation content collections in content > repositories, and enabling interoperability through the development and > use of standard interfaces and communications protocols. Content based > on rich data standards and protocols will provide the authoritative > instructions needed by data-driven tools to enable the automated > collection and exchange of configuration and vulnerability data > pertaining to enterprise assets. Information produced by these tools > will provide accurate and timely situational awareness in support of > organizational decision making. > > This working group will provide solutions to these categories of > problems and the main areas of focus for this working group are > described as follows: > > 1. Define, either by normative reference, adoption, or creation, a set > of standards that can be used for the purpose of assessing and > aggregating device states and comparing these device states against > expected values, and reporting on those results in a predefined or ad > hoc manner. This area of focus provides for necessary language and data > format specifications. > > 2. Define, either by normative reference, adoption, or creation, a set > of standards that can be used to continuously assess and report on the > state of systems, composed of many different types of devices and > networks, operated by varying personnel, to ensure security process > effectiveness in a pre-defined or ad-hoc manner. This area of focus > provides for integration protocols supporting plug and play continuous > assessment and security automation networking. > > This working group will achieve the following milestones in two phases: > > Phase One > > - A Standards Track document specifying asset description format > > - A Standards Track document specifying asset identification > > - A Standards Track document specifying platform naming > > - A Standards Track document specifying platform matching > > - A Standards Track document specifying platform applicability > > - A Standards Track document specifying a control framework > representation format. > > - A Standards Track document specifying benchmark configuration > representation > > - An Informational document stating guidelines / requirements for > specifying checking languages > > - Standards Track documents specifying device state checking languages > > - A Standards Track document specifying an interrogative checking language > > - A Standards Track document specifying asset reporting information > > - Standards Track document describing how to use the languages and other > content defined in this group with the NEA protocols > > Phase Two > > - Standards Track document specifying security automation/continuous > assessment interfaces > > - A Standards Track document specifying communication protocols used for > security automation and continuous assessment > > - A Standards Track document describing the messages and network > protocols for distributing security automation content (content repository) > > - A Standards Track document describing protocols and data formats for > securely sharing dynamic network state information among security systems > > ------------------------------------------------------------------------ > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Tue Sep 25 13:25:40 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF37B1F0CE2 for ; Tue, 25 Sep 2012 13:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.015 X-Spam-Level: X-Spam-Status: No, score=-102.015 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 kbNww-D8z2Hh for ; Tue, 25 Sep 2012 13:25:39 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.44.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77A941F0CB7 for ; Tue, 25 Sep 2012 13:25:39 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id DE742332E926C; Tue, 25 Sep 2012 15:25:38 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id CFB32332E924C for ; Tue, 25 Sep 2012 15:25:38 -0500 (CDT) Received: from [108.18.174.220] (port=52705 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGbhK-0006bY-Cf; Tue, 25 Sep 2012 15:25:38 -0500 Message-ID: <50621341.5050908@ieca.com> Date: Tue, 25 Sep 2012 16:25:37 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Baker, Jon" References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:52705 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:25:41 -0000 Jon, The protocol bullets were added at the request of both Security ADs. The IETF uses the 5 questions in s1 of https://datatracker.ietf.org/doc/rfc5434/ when determining whether to charter a WG. If there's no protocol work to be done in the somewhat near future, then we'll have a debate early on in the BOF about what the answer to question 1 part b is because that's basically what the IETF does best/most. I also say this because it takes on average 3 years from the start of a WG to it publishing it's first RFC. SMIME took 2 years 5 months from the day it was started until RFC3850 was published (and that was after RSA gave change control) and TLS 1.0 took 2 years 1 month. If we're going to spend three years arguing about schema and naming before getting to protocol design ... I'm not saying a WG can't form without protocol work, but there will certainly be less resistance if protocol work is part of the initial set of deliverables. spt On 9/23/12 11:12 AM, Moriarty, Kathleen wrote: > Hi Jon, > > Thank you for your comments! The data formats enable communication between entities, but without common protocols, we will miss the opportunity to create interoperability between vendor products. We do want to enable intelligence feeds and common reporting methods, even if it is to point to other efforts like GRC Exchange. The repository work could benefit from common access methods to address one of the additions. The IETF is good at protocols and the SACM community is good at data formats to enable automated security. In bringing these groups together, we should try to take advantage of the expertise of the IETF to more fully solve the problem space. As I found out with RFC6545, people will point out things needed for interoperability for which others deep in a problem space may not be aware. > > Thanks for the catch on two versus three, just trying to make sure people are reading ;-) LOL > > A corrected version is listed below, with the exception of how to deal with the platform naming. In either case, whatever we select will likely be by reference (SWID or CPE). I like the SWID approach, but we'll need more discussion on that. > > BOF full name: Security Automation and Continuous Monitoring [SACM] > AREA: Security > BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) > David Waltermire (david.waltermire@nist.gov) > Agenda: > > * Review the draft charter > * Review draft-waltermire-sacm-use-cases-02 > * Review drafts submitted in support of the charter > - draft-waltermire-content-repository-00 > - More expected before -00 deadline > > Full Description of BOF: The SACM BoF is intended to progress the work from the SACM mailing list to solidify discussions on a proposed charter, use cases and milestones in support of moving to an IETF working group. > > CONFLICTS to avoid: SAAG, MILE > Expected Attendance: 40, not sure what the previous attendance was? > Special Requests: Meetecho support > Number of sessions: 1 > Length of session: 2 hours > > Draft Charter: > > Proposed Working Group Charter > > Chairs: > TBD > TBD > > Security Area Directors: > Stephen Farrell > Sean Turner > > Security Area Advisor: > Sean Turner > > Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > > Description of Working Group > > Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation protocols and data format standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this work is to address enterprise use cases. > > The working group will achieve this by enabling the exchange of shared intelligence and continuing the security automation work already performed by various organizations around the world. The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group are the emerging security automation interfaces and data formats relating to event management and continuous assessment. The continuous assessment capabilities enable organizational situational awareness through frequent snapshots of the operating state of their environment, with risk prioritized based on consumed information provided by shared intelligence (vulnerabilities, threats, etc.). > > By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: enabling interoperable data exchanges through standardized protocols, defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making. > > The data exchange protocols will need to meet several exchange types including those between and within organizations for sharing intelligence data to increase situational awareness, report exchanges both internal and external to an enterprise, and those between enterprise servers and end points for assessments > > This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows: > > 1. Define, either by normative reference, adoption, or creation, a set of standards to enable the exchange of data to increase situational awareness or gain access to shared content to improve the security posture of an enterprise. This area of focus provides for the integration of interoperable protocols to access shared data repositories between organizations to increase situational awareness and reduce risks to an enterprise. In support of accessing shared intelligence for expected system state and related risks, define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing and aggregating device states and comparing these device states against expected values, and reporting on those results in a predefined or ad hoc manner. This area of focus provides for necessary language and data format specifications. > > 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking within an enterprise. > > This working group will achieve the following milestones in two phases: > > Phase One > - A standards track document to define a protocol for interacting with content repositories > - Standards Track document specifying security automation/continuous assessment interfaces > - A Standards Track document specifying communication protocols used for security automation and continuous assessment > - A Standards Track document describing the messages and network protocols for distributing security automation content (content repository) > - A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems > - A Standards Track document specifying asset description format > - A Standards Track document specifying asset identification > [- A Standards Track document specifying platform naming > - A Standards Track document specifying platform matching > - A Standards Track document specifying platform applicability] > > Phase Two > - A Standards Track document specifying a control framework representation format. > - A Standards Track document specifying benchmark configuration representation > - An Informational document stating guidelines / requirements for specifying checking languages > - Standards Track documents specifying device state checking languages > - A Standards Track document specifying an interrogative checking language > - A Standards Track document specifying asset reporting information > - Standards Track document describing how to use the languages and other content defined in this group with the NEA protocols > > > > Best regards, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Baker, Jon > Sent: Sunday, September 23, 2012 5:51 AM > To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] SACM BoF Request > >> I am including an updated version of the SACM Charter that includes more of >> an emphasis on the protocols to share and exchange data within and between >> enterprises/organizations. > > Why the shift in emphasis to sharing and exchanging data between organizations? This seems to be new to this group. > > Also in the section that lists the focus areas it looks like you intended for there to be three focus areas but accidently merged the second focus area into the first. Your wording in the first focus area appears to start describing a new focus area and your number goes from 1 to 3 skipping number 2. > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Moriarty, Kathleen >> Sent: Friday, September 21, 2012 4:32 PM >> To: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >> >> Hello, >> >> I am including an updated version of the SACM Charter that includes more of >> an emphasis on the protocols to share and exchange data within and between >> enterprises/organizations. Please feel free to provide feedback to the list! >> >> Thanks & have a good weekend! >> Kathleen >> >> >> >> BOF full name: Security Automation and Continuous Monitoring [SACM] >> AREA: Security >> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >> Agenda: >> >> * Review the draft charter >> * Review draft-waltermire-sacm-use-cases-02 >> * Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >> Full Description of BOF: The SACM BoF is intended to progress the work from >> the SACM mailing list to solidify discussions on a proposed charter, use cases >> and milestones in support of moving to an IETF working group. >> >> CONFLICTS to avoid: SAAG, MILE >> Expected Attendance: 40, not sure what the previous attendance was? >> Special Requests: Meetecho support >> Number of sessions: 1 >> Length of session: 2 hours >> >> Draft Charter: >> >> Proposed Working Group Charter >> >> Chairs: >> TBD >> TBD >> >> Security Area Directors: >> Stephen Farrell >> Sean Turner >> >> Security Area Advisor: >> Sean Turner >> >> Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >> Description of Working Group >> >> Securing information and the systems that store, process, and transmit that >> information has become a challenging task for organizations of all sizes, and >> we find that security practitioners spend most of their time on manual >> processes relegating them to ineffectiveness. Security automation to verify >> system configurations with the ability to prioritize risk based on increased >> situational awareness from shared intelligence is the key to escaping this rut. >> This working group will develop security automation protocols and data >> format standards in support of information security processes and practices >> where practical. These standards will help security practitioners to be better >> utilized within their organizations by automating routine tasks related to >> endpoint and server security so that practitioners can focus on more >> advanced tasks. The initial focus of this work is to address enterprise use >> cases. >> >> The working group will achieve this by enabling the exchange of shared >> intelligence and continuing the security automation work already performed >> by various organizations around the world. The initial work has been fruitful, >> and the data formats previously published are ready for expansion on the >> international stage. Of particular interest to this working group are the >> security automation specifications supporting asset, change, configuration, >> and vulnerability management. Of additional interest to this working group >> are the emerging security automation interfaces and data formats relating to >> event management and continuous assessment. The continuous assessment >> capabilities enable organizational situational awareness through frequent >> snapshots of the operating state of their environment, with risk prioritized >> based on consumed information provided by shared intelligence >> (vulnerabilities, threats, etc.). >> >> By undertaking this work, we recognize that there are multiple categories of >> problems in the security automation domain: enabling interoperable data >> exchanges through standardized protocols, defining expressions for particular >> domain concepts (i.e. data formats), establishing a standards-based >> foundation supporting the curation and exchange of security automation >> content collections in content repositories, and enabling interoperability >> through the development and use of standard interfaces and communications >> protocols. Content based on rich data standards and protocols will provide the >> authoritative instructions needed by data-driven tools to enable the >> automated collection and exchange of configuration and vulnerability data >> pertaining to enterprise assets. Information produced by these tools will >> provide accurate and timely situational awareness in support of organizational >> decision making. >> >> The data exchange protocols will need to meet several exchange types >> including those between and within organizations for sharing intelligence data >> to increase situational awareness, report exchanges both internal and >> external to an enterprise, and those between enterprise servers and end >> points for assessments >> >> This working group will provide solutions to these categories of problems and >> the main areas of focus for this working group are described as follows: >> >> 1. Define, either by normative reference, adoption, or creation, a set of >> standards to enable the exchange of data to increase situational awareness or >> gain access to shared content to improve the security posture of an >> enterprise. This area of focus provides for the integration of interoperable >> protocols to access shared data repositories between organizations to >> increase situational awareness and reduce risks to an enterprise. In support >> of accessing shared intelligence for expected system state and related risks, >> define, either by normative reference, adoption, or creation, a set of >> standards that can be used for the purpose of assessing and aggregating >> device states and comparing these device states against expected values, and >> reporting on those results in a predefined or ad hoc manner. This area of >> focus provides for necessary language and data format specifications. >> >> 3. Define, either by normative reference, adoption, or creation, a set of >> standards that can be used to continuously assess and report on the state of >> systems, composed of many different types of devices and networks, >> operated by varying personnel, to ensure security process effectiveness in a >> pre-defined or ad-hoc manner. This area of focus provides for integration >> protocols supporting plug and play continuous assessment and security >> automation networking within an enterprise. >> >> This working group will achieve the following milestones in two phases: >> >> Phase One >> - A standards track document to define a protocol for interacting with content >> repositories >> - Standards Track document specifying security automation/continuous >> assessment interfaces >> - A Standards Track document specifying communication protocols used for >> security automation and continuous assessment >> - A Standards Track document describing the messages and network protocols >> for distributing security automation content (content repository) >> - A Standards Track document describing protocols and data formats for >> securely sharing dynamic network state information among security systems >> - A Standards Track document specifying asset description format >> - A Standards Track document specifying asset identification >> - A Standards Track document specifying platform naming >> - A Standards Track document specifying platform matching >> - A Standards Track document specifying platform applicability >> >> Phase Two >> - A Standards Track document specifying a control framework representation >> format. >> - A Standards Track document specifying benchmark configuration >> representation >> - An Informational document stating guidelines / requirements for specifying >> checking languages >> - Standards Track documents specifying device state checking languages >> - A Standards Track document specifying an interrogative checking language >> - A Standards Track document specifying asset reporting information >> - Standards Track document describing how to use the languages and other >> content defined in this group with the NEA protocols >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From bakerj@mitre.org Tue Sep 25 18:55:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4552C21F860D for ; Tue, 25 Sep 2012 18:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qizuJG8sxHDZ for ; Tue, 25 Sep 2012 18:55:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFC21F8605 for ; Tue, 25 Sep 2012 18:55:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 877C021B0CE1; Tue, 25 Sep 2012 21:55:26 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7ACA321B0CF2; Tue, 25 Sep 2012 21:55:26 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.001; Tue, 25 Sep 2012 21:55:26 -0400 From: "Baker, Jon" To: Sean Turner Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4AThqt4AAKyOnwAHhyvIAAAvglwA== Date: Wed, 26 Sep 2012 01:55:25 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130227FC8C@IMCMBX03.MITRE.ORG> References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> <50621341.5050908@ieca.com> In-Reply-To: <50621341.5050908@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 01:55:30 -0000 Sean,=20 Thanks for pointing out the rfc. It was helpful for me to what goes into a = well-run BoF.. Also, thank you for explaining why the protocol bullets were added. In the = original announcement the addition seemed to come somewhat out of nowhere. = I may have missed it on the list, but I had not seen it discussed.=20 Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: Sean Turner [mailto:turners@ieca.com] >Sent: Tuesday, September 25, 2012 4:26 PM >To: Baker, Jon >Cc: sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Jon, > >The protocol bullets were added at the request of both Security ADs. >The IETF uses the 5 questions in s1 of >https://datatracker.ietf.org/doc/rfc5434/ when determining whether to >charter a WG. If there's no protocol work to be done in the somewhat >near future, then we'll have a debate early on in the BOF about what the >answer to question 1 part b is because that's basically what the IETF >does best/most. I also say this because it takes on average 3 years >from the start of a WG to it publishing it's first RFC. SMIME took 2 >years 5 months from the day it was started until RFC3850 was published >(and that was after RSA gave change control) and TLS 1.0 took 2 years 1 >month. If we're going to spend three years arguing about schema and >naming before getting to protocol design ... > >I'm not saying a WG can't form without protocol work, but there will >certainly be less resistance if protocol work is part of the initial set >of deliverables. > >spt > >On 9/23/12 11:12 AM, Moriarty, Kathleen wrote: >> Hi Jon, >> >> Thank you for your comments! The data formats enable communication >between entities, but without common protocols, we will miss the >opportunity to create interoperability between vendor products. We do wan= t >to enable intelligence feeds and common reporting methods, even if it is t= o >point to other efforts like GRC Exchange. The repository work could benef= it >from common access methods to address one of the additions. The IETF is >good at protocols and the SACM community is good at data formats to enable >automated security. In bringing these groups together, we should try to ta= ke >advantage of the expertise of the IETF to more fully solve the problem spa= ce. >As I found out with RFC6545, people will point out things needed for >interoperability for which others deep in a problem space may not be aware= . >> >> Thanks for the catch on two versus three, just trying to make sure peopl= e >are reading ;-) LOL >> >> A corrected version is listed below, with the exception of how to deal w= ith >the platform naming. In either case, whatever we select will likely be by >reference (SWID or CPE). I like the SWID approach, but we'll need more >discussion on that. >> >> BOF full name: Security Automation and Continuous Monitoring [SACM] >> AREA: Security >> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >> Agenda: >> >> * Review the draft charter >> * Review draft-waltermire-sacm-use-cases-02 >> * Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >> Full Description of BOF: The SACM BoF is intended to progress the work >from the SACM mailing list to solidify discussions on a proposed charter, = use >cases and milestones in support of moving to an IETF working group. >> >> CONFLICTS to avoid: SAAG, MILE >> Expected Attendance: 40, not sure what the previous attendance was? >> Special Requests: Meetecho support >> Number of sessions: 1 >> Length of session: 2 hours >> >> Draft Charter: >> >> Proposed Working Group Charter >> >> Chairs: >> TBD >> TBD >> >> Security Area Directors: >> Stephen Farrell >> Sean Turner >> >> Security Area Advisor: >> Sean Turner >> >> Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >> Description of Working Group >> >> Securing information and the systems that store, process, and transmit t= hat >information has become a challenging task for organizations of all sizes, = and >we find that security practitioners spend most of their time on manual >processes relegating them to ineffectiveness. Security automation to verif= y >system configurations with the ability to prioritize risk based on increas= ed >situational awareness from shared intelligence is the key to escaping this= rut. >This working group will develop security automation protocols and data >format standards in support of information security processes and practice= s >where practical. These standards will help security practitioners to be be= tter >utilized within their organizations by automating routine tasks related to >endpoint and server security so that practitioners can focus on more >advanced tasks. The initial focus of this work is to address enterprise us= e >cases. >> >> The working group will achieve this by enabling the exchange of shared >intelligence and continuing the security automation work already performed >by various organizations around the world. The initial work has been frui= tful, >and the data formats previously published are ready for expansion on the >international stage. Of particular interest to this working group are the >security automation specifications supporting asset, change, configuration= , >and vulnerability management. Of additional interest to this working group >are the emerging security automation interfaces and data formats relating = to >event management and continuous assessment. The continuous assessment >capabilities enable organizational situational awareness through frequent >snapshots of the operating state of their environment, with risk prioritiz= ed >based on consumed information provided by shared intelligence >(vulnerabilities, threats, etc.). >> >> By undertaking this work, we recognize that there are multiple categorie= s of >problems in the security automation domain: enabling interoperable data >exchanges through standardized protocols, defining expressions for particu= lar >domain concepts (i.e. data formats), establishing a standards-based >foundation supporting the curation and exchange of security automation >content collections in content repositories, and enabling interoperability >through the development and use of standard interfaces and communications >protocols. Content based on rich data standards and protocols will provide= the >authoritative instructions needed by data-driven tools to enable the >automated collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in support of organizati= onal >decision making. >> >> The data exchange protocols will need to meet several exchange types >including those between and within organizations for sharing intelligence = data >to increase situational awareness, report exchanges both internal and >external to an enterprise, and those between enterprise servers and end >points for assessments >> >> This working group will provide solutions to these categories of problem= s >and the main areas of focus for this working group are described as follow= s: >> >> 1. Define, either by normative reference, adoption, or creation, a set o= f >standards to enable the exchange of data to increase situational awareness= or >gain access to shared content to improve the security posture of an >enterprise. This area of focus provides for the integration of interopera= ble >protocols to access shared data repositories between organizations to >increase situational awareness and reduce risks to an enterprise. In supp= ort >of accessing shared intelligence for expected system state and related ris= ks, >define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing and aggregating >device states and comparing these device states against expected values, a= nd >reporting on those results in a predefined or ad hoc manner. This area of >focus provides for necessary language and data format specifications. >> >> 2. Define, either by normative reference, adoption, or creation, a set o= f >standards that can be used to continuously assess and report on the state = of >systems, composed of many different types of devices and networks, >operated by varying personnel, to ensure security process effectiveness in= a >pre-defined or ad-hoc manner. This area of focus provides for integration >protocols supporting plug and play continuous assessment and security >automation networking within an enterprise. >> >> This working group will achieve the following milestones in two phases: >> >> Phase One >> - A standards track document to define a protocol for interacting with >content repositories >> - Standards Track document specifying security automation/continuous >assessment interfaces >> - A Standards Track document specifying communication protocols used for >security automation and continuous assessment >> - A Standards Track document describing the messages and network >protocols for distributing security automation content (content repositor= y) >> - A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >> - A Standards Track document specifying asset description format >> - A Standards Track document specifying asset identification >> [- A Standards Track document specifying platform naming >> - A Standards Track document specifying platform matching >> - A Standards Track document specifying platform applicability] >> >> Phase Two >> - A Standards Track document specifying a control framework >representation format. >> - A Standards Track document specifying benchmark configuration >representation >> - An Informational document stating guidelines / requirements for >specifying checking languages >> - Standards Track documents specifying device state checking languages >> - A Standards Track document specifying an interrogative checking langua= ge >> - A Standards Track document specifying asset reporting information >> - Standards Track document describing how to use the languages and other >content defined in this group with the NEA protocols >> >> >> >> Best regards, >> Kathleen >> >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >Of Baker, Jon >> Sent: Sunday, September 23, 2012 5:51 AM >> To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >> >>> I am including an updated version of the SACM Charter that includes mor= e >of >>> an emphasis on the protocols to share and exchange data within and >between >>> enterprises/organizations. >> >> Why the shift in emphasis to sharing and exchanging data between >organizations? This seems to be new to this group. >> >> Also in the section that lists the focus areas it looks like you intende= d for >there to be three focus areas but accidently merged the second focus area >into the first. Your wording in the first focus area appears to start desc= ribing a >new focus area and your number goes from 1 to 3 skipping number 2. >> >> Jon >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Jonathan O. Baker >> G022 - IA Industry Collaboration >> The MITRE Corporation >> Email: bakerj@mitre.org >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >Of >>> Moriarty, Kathleen >>> Sent: Friday, September 21, 2012 4:32 PM >>> To: Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] SACM BoF Request >>> >>> Hello, >>> >>> I am including an updated version of the SACM Charter that includes mor= e >of >>> an emphasis on the protocols to share and exchange data within and >between >>> enterprises/organizations. Please feel free to provide feedback to the= list! >>> >>> Thanks & have a good weekend! >>> Kathleen >>> >>> >>> >>> BOF full name: Security Automation and Continuous Monitoring [SACM] >>> AREA: Security >>> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>> David Waltermire (david.waltermire@nist.gov) >>> Agenda: >>> >>> * Review the draft charter >>> * Review draft-waltermire-sacm-use-cases-02 >>> * Review drafts submitted in support of the charter >>> - draft-waltermire-content-repository-00 >>> - More expected before -00 deadline >>> >>> Full Description of BOF: The SACM BoF is intended to progress the work >from >>> the SACM mailing list to solidify discussions on a proposed charter, us= e >cases >>> and milestones in support of moving to an IETF working group. >>> >>> CONFLICTS to avoid: SAAG, MILE >>> Expected Attendance: 40, not sure what the previous attendance was? >>> Special Requests: Meetecho support >>> Number of sessions: 1 >>> Length of session: 2 hours >>> >>> Draft Charter: >>> >>> Proposed Working Group Charter >>> >>> Chairs: >>> TBD >>> TBD >>> >>> Security Area Directors: >>> Stephen Farrell >>> Sean Turner >>> >>> Security Area Advisor: >>> Sean Turner >>> >>> Mailing Lists: >>> General Discussion: sacm@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>> Archive: http://www.ietf.org/mail-archive/web/sacm >>> >>> Description of Working Group >>> >>> Securing information and the systems that store, process, and transmit >that >>> information has become a challenging task for organizations of all size= s, and >>> we find that security practitioners spend most of their time on manual >>> processes relegating them to ineffectiveness. Security automation to >verify >>> system configurations with the ability to prioritize risk based on incr= eased >>> situational awareness from shared intelligence is the key to escaping t= his >rut. >>> This working group will develop security automation protocols and data >>> format standards in support of information security processes and >practices >>> where practical. These standards will help security practitioners to be >better >>> utilized within their organizations by automating routine tasks related= to >>> endpoint and server security so that practitioners can focus on more >>> advanced tasks. The initial focus of this work is to address enterprise= use >>> cases. >>> >>> The working group will achieve this by enabling the exchange of shared >>> intelligence and continuing the security automation work already >performed >>> by various organizations around the world. The initial work has been >fruitful, >>> and the data formats previously published are ready for expansion on th= e >>> international stage. Of particular interest to this working group are t= he >>> security automation specifications supporting asset, change, configurat= ion, >>> and vulnerability management. Of additional interest to this working gr= oup >>> are the emerging security automation interfaces and data formats relati= ng >to >>> event management and continuous assessment. The continuous >assessment >>> capabilities enable organizational situational awareness through freque= nt >>> snapshots of the operating state of their environment, with risk priori= tized >>> based on consumed information provided by shared intelligence >>> (vulnerabilities, threats, etc.). >>> >>> By undertaking this work, we recognize that there are multiple categori= es >of >>> problems in the security automation domain: enabling interoperable data >>> exchanges through standardized protocols, defining expressions for >particular >>> domain concepts (i.e. data formats), establishing a standards-based >>> foundation supporting the curation and exchange of security automation >>> content collections in content repositories, and enabling interoperabil= ity >>> through the development and use of standard interfaces and >communications >>> protocols. Content based on rich data standards and protocols will prov= ide >the >>> authoritative instructions needed by data-driven tools to enable the >>> automated collection and exchange of configuration and vulnerability da= ta >>> pertaining to enterprise assets. Information produced by these tools wi= ll >>> provide accurate and timely situational awareness in support of >organizational >>> decision making. >>> >>> The data exchange protocols will need to meet several exchange types >>> including those between and within organizations for sharing intelligen= ce >data >>> to increase situational awareness, report exchanges both internal and >>> external to an enterprise, and those between enterprise servers and end >>> points for assessments >>> >>> This working group will provide solutions to these categories of proble= ms >and >>> the main areas of focus for this working group are described as follows= : >>> >>> 1. Define, either by normative reference, adoption, or creation, a set = of >>> standards to enable the exchange of data to increase situational >awareness or >>> gain access to shared content to improve the security posture of an >>> enterprise. This area of focus provides for the integration of interop= erable >>> protocols to access shared data repositories between organizations to >>> increase situational awareness and reduce risks to an enterprise. In >support >>> of accessing shared intelligence for expected system state and related >risks, >>> define, either by normative reference, adoption, or creation, a set of >>> standards that can be used for the purpose of assessing and aggregating >>> device states and comparing these device states against expected values= , >and >>> reporting on those results in a predefined or ad hoc manner. This area= of >>> focus provides for necessary language and data format specifications. >>> >>> 3. Define, either by normative reference, adoption, or creation, a set = of >>> standards that can be used to continuously assess and report on the sta= te >of >>> systems, composed of many different types of devices and networks, >>> operated by varying personnel, to ensure security process effectiveness= in >a >>> pre-defined or ad-hoc manner. This area of focus provides for integrat= ion >>> protocols supporting plug and play continuous assessment and security >>> automation networking within an enterprise. >>> >>> This working group will achieve the following milestones in two phases: >>> >>> Phase One >>> - A standards track document to define a protocol for interacting with >content >>> repositories >>> - Standards Track document specifying security automation/continuous >>> assessment interfaces >>> - A Standards Track document specifying communication protocols used fo= r >>> security automation and continuous assessment >>> - A Standards Track document describing the messages and network >protocols >>> for distributing security automation content (content repository) >>> - A Standards Track document describing protocols and data formats for >>> securely sharing dynamic network state information among security >systems >>> - A Standards Track document specifying asset description format >>> - A Standards Track document specifying asset identification >>> - A Standards Track document specifying platform naming >>> - A Standards Track document specifying platform matching >>> - A Standards Track document specifying platform applicability >>> >>> Phase Two >>> - A Standards Track document specifying a control framework >representation >>> format. >>> - A Standards Track document specifying benchmark configuration >>> representation >>> - An Informational document stating guidelines / requirements for >specifying >>> checking languages >>> - Standards Track documents specifying device state checking languages >>> - A Standards Track document specifying an interrogative checking >language >>> - A Standards Track document specifying asset reporting information >>> - Standards Track document describing how to use the languages and othe= r >>> content defined in this group with the NEA protocols >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> From turners@ieca.com Tue Sep 25 19:01:08 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065091F0425 for ; Tue, 25 Sep 2012 19:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.02 X-Spam-Level: X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 75D4WOFRUXwS for ; Tue, 25 Sep 2012 19:01:06 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.144.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7886B21F8610 for ; Tue, 25 Sep 2012 19:01:06 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 2033A19BD216C; Tue, 25 Sep 2012 21:01:06 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 11F0119BD214B for ; Tue, 25 Sep 2012 21:01:06 -0500 (CDT) Received: from [108.18.174.220] (port=56385 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGgvx-0006kl-94; Tue, 25 Sep 2012 21:01:05 -0500 Message-ID: <506261E0.9040407@ieca.com> Date: Tue, 25 Sep 2012 22:01:04 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Baker, Jon" References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG> <50621341.5050908@ieca.com> <6C1C15D8B5510B4B8FF132B10D3865130227FC8C@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130227FC8C@IMCMBX03.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:56385 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 02:01:08 -0000 No worries it did kind of come out of nowhere ;) Tomorrow is the IESG/IAB BOF coordination call where we discuss all the proposed BOFs for IETF 85 (https://wiki.tools.ietf.org/bof/trac/). After the call, I'll post a summary of what transpired wrt this BOF proposal. spt On 9/25/12 9:55 PM, Baker, Jon wrote: > Sean, > > Thanks for pointing out the rfc. It was helpful for me to what goes into a well-run BoF.. > > Also, thank you for explaining why the protocol bullets were added. In the original announcement the addition seemed to come somewhat out of nowhere. I may have missed it on the list, but I had not seen it discussed. > > Thanks, > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > > >> -----Original Message----- >> From: Sean Turner [mailto:turners@ieca.com] >> Sent: Tuesday, September 25, 2012 4:26 PM >> To: Baker, Jon >> Cc: sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >> >> Jon, >> >> The protocol bullets were added at the request of both Security ADs. >> The IETF uses the 5 questions in s1 of >> https://datatracker.ietf.org/doc/rfc5434/ when determining whether to >> charter a WG. If there's no protocol work to be done in the somewhat >> near future, then we'll have a debate early on in the BOF about what the >> answer to question 1 part b is because that's basically what the IETF >> does best/most. I also say this because it takes on average 3 years >>from the start of a WG to it publishing it's first RFC. SMIME took 2 >> years 5 months from the day it was started until RFC3850 was published >> (and that was after RSA gave change control) and TLS 1.0 took 2 years 1 >> month. If we're going to spend three years arguing about schema and >> naming before getting to protocol design ... >> >> I'm not saying a WG can't form without protocol work, but there will >> certainly be less resistance if protocol work is part of the initial set >> of deliverables. >> >> spt >> >> On 9/23/12 11:12 AM, Moriarty, Kathleen wrote: >>> Hi Jon, >>> >>> Thank you for your comments! The data formats enable communication >> between entities, but without common protocols, we will miss the >> opportunity to create interoperability between vendor products. We do want >> to enable intelligence feeds and common reporting methods, even if it is to >> point to other efforts like GRC Exchange. The repository work could benefit >>from common access methods to address one of the additions. The IETF is >> good at protocols and the SACM community is good at data formats to enable >> automated security. In bringing these groups together, we should try to take >> advantage of the expertise of the IETF to more fully solve the problem space. >> As I found out with RFC6545, people will point out things needed for >> interoperability for which others deep in a problem space may not be aware. >>> >>> Thanks for the catch on two versus three, just trying to make sure people >> are reading ;-) LOL >>> >>> A corrected version is listed below, with the exception of how to deal with >> the platform naming. In either case, whatever we select will likely be by >> reference (SWID or CPE). I like the SWID approach, but we'll need more >> discussion on that. >>> >>> BOF full name: Security Automation and Continuous Monitoring [SACM] >>> AREA: Security >>> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>> David Waltermire (david.waltermire@nist.gov) >>> Agenda: >>> >>> * Review the draft charter >>> * Review draft-waltermire-sacm-use-cases-02 >>> * Review drafts submitted in support of the charter >>> - draft-waltermire-content-repository-00 >>> - More expected before -00 deadline >>> >>> Full Description of BOF: The SACM BoF is intended to progress the work >>from the SACM mailing list to solidify discussions on a proposed charter, use >> cases and milestones in support of moving to an IETF working group. >>> >>> CONFLICTS to avoid: SAAG, MILE >>> Expected Attendance: 40, not sure what the previous attendance was? >>> Special Requests: Meetecho support >>> Number of sessions: 1 >>> Length of session: 2 hours >>> >>> Draft Charter: >>> >>> Proposed Working Group Charter >>> >>> Chairs: >>> TBD >>> TBD >>> >>> Security Area Directors: >>> Stephen Farrell >>> Sean Turner >>> >>> Security Area Advisor: >>> Sean Turner >>> >>> Mailing Lists: >>> General Discussion: sacm@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>> Archive: http://www.ietf.org/mail-archive/web/sacm >>> >>> Description of Working Group >>> >>> Securing information and the systems that store, process, and transmit that >> information has become a challenging task for organizations of all sizes, and >> we find that security practitioners spend most of their time on manual >> processes relegating them to ineffectiveness. Security automation to verify >> system configurations with the ability to prioritize risk based on increased >> situational awareness from shared intelligence is the key to escaping this rut. >> This working group will develop security automation protocols and data >> format standards in support of information security processes and practices >> where practical. These standards will help security practitioners to be better >> utilized within their organizations by automating routine tasks related to >> endpoint and server security so that practitioners can focus on more >> advanced tasks. The initial focus of this work is to address enterprise use >> cases. >>> >>> The working group will achieve this by enabling the exchange of shared >> intelligence and continuing the security automation work already performed >> by various organizations around the world. The initial work has been fruitful, >> and the data formats previously published are ready for expansion on the >> international stage. Of particular interest to this working group are the >> security automation specifications supporting asset, change, configuration, >> and vulnerability management. Of additional interest to this working group >> are the emerging security automation interfaces and data formats relating to >> event management and continuous assessment. The continuous assessment >> capabilities enable organizational situational awareness through frequent >> snapshots of the operating state of their environment, with risk prioritized >> based on consumed information provided by shared intelligence >> (vulnerabilities, threats, etc.). >>> >>> By undertaking this work, we recognize that there are multiple categories of >> problems in the security automation domain: enabling interoperable data >> exchanges through standardized protocols, defining expressions for particular >> domain concepts (i.e. data formats), establishing a standards-based >> foundation supporting the curation and exchange of security automation >> content collections in content repositories, and enabling interoperability >> through the development and use of standard interfaces and communications >> protocols. Content based on rich data standards and protocols will provide the >> authoritative instructions needed by data-driven tools to enable the >> automated collection and exchange of configuration and vulnerability data >> pertaining to enterprise assets. Information produced by these tools will >> provide accurate and timely situational awareness in support of organizational >> decision making. >>> >>> The data exchange protocols will need to meet several exchange types >> including those between and within organizations for sharing intelligence data >> to increase situational awareness, report exchanges both internal and >> external to an enterprise, and those between enterprise servers and end >> points for assessments >>> >>> This working group will provide solutions to these categories of problems >> and the main areas of focus for this working group are described as follows: >>> >>> 1. Define, either by normative reference, adoption, or creation, a set of >> standards to enable the exchange of data to increase situational awareness or >> gain access to shared content to improve the security posture of an >> enterprise. This area of focus provides for the integration of interoperable >> protocols to access shared data repositories between organizations to >> increase situational awareness and reduce risks to an enterprise. In support >> of accessing shared intelligence for expected system state and related risks, >> define, either by normative reference, adoption, or creation, a set of >> standards that can be used for the purpose of assessing and aggregating >> device states and comparing these device states against expected values, and >> reporting on those results in a predefined or ad hoc manner. This area of >> focus provides for necessary language and data format specifications. >>> >>> 2. Define, either by normative reference, adoption, or creation, a set of >> standards that can be used to continuously assess and report on the state of >> systems, composed of many different types of devices and networks, >> operated by varying personnel, to ensure security process effectiveness in a >> pre-defined or ad-hoc manner. This area of focus provides for integration >> protocols supporting plug and play continuous assessment and security >> automation networking within an enterprise. >>> >>> This working group will achieve the following milestones in two phases: >>> >>> Phase One >>> - A standards track document to define a protocol for interacting with >> content repositories >>> - Standards Track document specifying security automation/continuous >> assessment interfaces >>> - A Standards Track document specifying communication protocols used for >> security automation and continuous assessment >>> - A Standards Track document describing the messages and network >> protocols for distributing security automation content (content repository) >>> - A Standards Track document describing protocols and data formats for >> securely sharing dynamic network state information among security systems >>> - A Standards Track document specifying asset description format >>> - A Standards Track document specifying asset identification >>> [- A Standards Track document specifying platform naming >>> - A Standards Track document specifying platform matching >>> - A Standards Track document specifying platform applicability] >>> >>> Phase Two >>> - A Standards Track document specifying a control framework >> representation format. >>> - A Standards Track document specifying benchmark configuration >> representation >>> - An Informational document stating guidelines / requirements for >> specifying checking languages >>> - Standards Track documents specifying device state checking languages >>> - A Standards Track document specifying an interrogative checking language >>> - A Standards Track document specifying asset reporting information >>> - Standards Track document describing how to use the languages and other >> content defined in this group with the NEA protocols >>> >>> >>> >>> Best regards, >>> Kathleen >>> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Baker, Jon >>> Sent: Sunday, September 23, 2012 5:51 AM >>> To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] SACM BoF Request >>> >>>> I am including an updated version of the SACM Charter that includes more >> of >>>> an emphasis on the protocols to share and exchange data within and >> between >>>> enterprises/organizations. >>> >>> Why the shift in emphasis to sharing and exchanging data between >> organizations? This seems to be new to this group. >>> >>> Also in the section that lists the focus areas it looks like you intended for >> there to be three focus areas but accidently merged the second focus area >> into the first. Your wording in the first focus area appears to start describing a >> new focus area and your number goes from 1 to 3 skipping number 2. >>> >>> Jon >>> >>> ============================================ >>> Jonathan O. Baker >>> G022 - IA Industry Collaboration >>> The MITRE Corporation >>> Email: bakerj@mitre.org >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of >>>> Moriarty, Kathleen >>>> Sent: Friday, September 21, 2012 4:32 PM >>>> To: Waltermire, David A.; sacm@ietf.org >>>> Subject: Re: [sacm] SACM BoF Request >>>> >>>> Hello, >>>> >>>> I am including an updated version of the SACM Charter that includes more >> of >>>> an emphasis on the protocols to share and exchange data within and >> between >>>> enterprises/organizations. Please feel free to provide feedback to the list! >>>> >>>> Thanks & have a good weekend! >>>> Kathleen >>>> >>>> >>>> >>>> BOF full name: Security Automation and Continuous Monitoring [SACM] >>>> AREA: Security >>>> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>>> David Waltermire (david.waltermire@nist.gov) >>>> Agenda: >>>> >>>> * Review the draft charter >>>> * Review draft-waltermire-sacm-use-cases-02 >>>> * Review drafts submitted in support of the charter >>>> - draft-waltermire-content-repository-00 >>>> - More expected before -00 deadline >>>> >>>> Full Description of BOF: The SACM BoF is intended to progress the work >> from >>>> the SACM mailing list to solidify discussions on a proposed charter, use >> cases >>>> and milestones in support of moving to an IETF working group. >>>> >>>> CONFLICTS to avoid: SAAG, MILE >>>> Expected Attendance: 40, not sure what the previous attendance was? >>>> Special Requests: Meetecho support >>>> Number of sessions: 1 >>>> Length of session: 2 hours >>>> >>>> Draft Charter: >>>> >>>> Proposed Working Group Charter >>>> >>>> Chairs: >>>> TBD >>>> TBD >>>> >>>> Security Area Directors: >>>> Stephen Farrell >>>> Sean Turner >>>> >>>> Security Area Advisor: >>>> Sean Turner >>>> >>>> Mailing Lists: >>>> General Discussion: sacm@ietf.org >>>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>>> Archive: http://www.ietf.org/mail-archive/web/sacm >>>> >>>> Description of Working Group >>>> >>>> Securing information and the systems that store, process, and transmit >> that >>>> information has become a challenging task for organizations of all sizes, and >>>> we find that security practitioners spend most of their time on manual >>>> processes relegating them to ineffectiveness. Security automation to >> verify >>>> system configurations with the ability to prioritize risk based on increased >>>> situational awareness from shared intelligence is the key to escaping this >> rut. >>>> This working group will develop security automation protocols and data >>>> format standards in support of information security processes and >> practices >>>> where practical. These standards will help security practitioners to be >> better >>>> utilized within their organizations by automating routine tasks related to >>>> endpoint and server security so that practitioners can focus on more >>>> advanced tasks. The initial focus of this work is to address enterprise use >>>> cases. >>>> >>>> The working group will achieve this by enabling the exchange of shared >>>> intelligence and continuing the security automation work already >> performed >>>> by various organizations around the world. The initial work has been >> fruitful, >>>> and the data formats previously published are ready for expansion on the >>>> international stage. Of particular interest to this working group are the >>>> security automation specifications supporting asset, change, configuration, >>>> and vulnerability management. Of additional interest to this working group >>>> are the emerging security automation interfaces and data formats relating >> to >>>> event management and continuous assessment. The continuous >> assessment >>>> capabilities enable organizational situational awareness through frequent >>>> snapshots of the operating state of their environment, with risk prioritized >>>> based on consumed information provided by shared intelligence >>>> (vulnerabilities, threats, etc.). >>>> >>>> By undertaking this work, we recognize that there are multiple categories >> of >>>> problems in the security automation domain: enabling interoperable data >>>> exchanges through standardized protocols, defining expressions for >> particular >>>> domain concepts (i.e. data formats), establishing a standards-based >>>> foundation supporting the curation and exchange of security automation >>>> content collections in content repositories, and enabling interoperability >>>> through the development and use of standard interfaces and >> communications >>>> protocols. Content based on rich data standards and protocols will provide >> the >>>> authoritative instructions needed by data-driven tools to enable the >>>> automated collection and exchange of configuration and vulnerability data >>>> pertaining to enterprise assets. Information produced by these tools will >>>> provide accurate and timely situational awareness in support of >> organizational >>>> decision making. >>>> >>>> The data exchange protocols will need to meet several exchange types >>>> including those between and within organizations for sharing intelligence >> data >>>> to increase situational awareness, report exchanges both internal and >>>> external to an enterprise, and those between enterprise servers and end >>>> points for assessments >>>> >>>> This working group will provide solutions to these categories of problems >> and >>>> the main areas of focus for this working group are described as follows: >>>> >>>> 1. Define, either by normative reference, adoption, or creation, a set of >>>> standards to enable the exchange of data to increase situational >> awareness or >>>> gain access to shared content to improve the security posture of an >>>> enterprise. This area of focus provides for the integration of interoperable >>>> protocols to access shared data repositories between organizations to >>>> increase situational awareness and reduce risks to an enterprise. In >> support >>>> of accessing shared intelligence for expected system state and related >> risks, >>>> define, either by normative reference, adoption, or creation, a set of >>>> standards that can be used for the purpose of assessing and aggregating >>>> device states and comparing these device states against expected values, >> and >>>> reporting on those results in a predefined or ad hoc manner. This area of >>>> focus provides for necessary language and data format specifications. >>>> >>>> 3. Define, either by normative reference, adoption, or creation, a set of >>>> standards that can be used to continuously assess and report on the state >> of >>>> systems, composed of many different types of devices and networks, >>>> operated by varying personnel, to ensure security process effectiveness in >> a >>>> pre-defined or ad-hoc manner. This area of focus provides for integration >>>> protocols supporting plug and play continuous assessment and security >>>> automation networking within an enterprise. >>>> >>>> This working group will achieve the following milestones in two phases: >>>> >>>> Phase One >>>> - A standards track document to define a protocol for interacting with >> content >>>> repositories >>>> - Standards Track document specifying security automation/continuous >>>> assessment interfaces >>>> - A Standards Track document specifying communication protocols used for >>>> security automation and continuous assessment >>>> - A Standards Track document describing the messages and network >> protocols >>>> for distributing security automation content (content repository) >>>> - A Standards Track document describing protocols and data formats for >>>> securely sharing dynamic network state information among security >> systems >>>> - A Standards Track document specifying asset description format >>>> - A Standards Track document specifying asset identification >>>> - A Standards Track document specifying platform naming >>>> - A Standards Track document specifying platform matching >>>> - A Standards Track document specifying platform applicability >>>> >>>> Phase Two >>>> - A Standards Track document specifying a control framework >> representation >>>> format. >>>> - A Standards Track document specifying benchmark configuration >>>> representation >>>> - An Informational document stating guidelines / requirements for >> specifying >>>> checking languages >>>> - Standards Track documents specifying device state checking languages >>>> - A Standards Track document specifying an interrogative checking >> language >>>> - A Standards Track document specifying asset reporting information >>>> - Standards Track document describing how to use the languages and other >>>> content defined in this group with the NEA protocols >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> > From bakerj@mitre.org Tue Sep 25 19:06:57 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B108F1F0C95 for ; Tue, 25 Sep 2012 19:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwcbA-HYfUxr for ; Tue, 25 Sep 2012 19:06:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 785FC1F0C51 for ; Tue, 25 Sep 2012 19:06:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E44E21B0D07; Tue, 25 Sep 2012 22:06:53 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6FEF821B0D04; Tue, 25 Sep 2012 22:06:53 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.001; Tue, 25 Sep 2012 22:06:53 -0400 From: "Baker, Jon" To: "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEgAHsIJlA= Date: Wed, 26 Sep 2012 02:06:52 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 02:06:57 -0000 In your message below, you say "select either CPE or SWID". I really have n= ot looked at it as a one or the other decision.=20 I believe that there remains a need for both efforts. SWIDs are well suited= for identifying specific instances of installed software all the way down = to the patch level. However, SWIDS are not currently designed to support wh= at we have referred to as abstract names like "Windows 7". Security guidanc= e is generally written to target these sorts of abstractions. Vulnerability= information is often reported and shared using these sorts of abstractions= . For example, "Flash 1.2.3 has a zero day vulnerability that is actively b= eing exploited." Enterprise reporting also tends to leverage this abstracti= on capability. To make this work you end up needing a way to determine if o= ne name matches another (CPE Matching Spec) and a way to state that somethi= ng (benchmark/vulnerability/etc) applies to a given platform (CPE Applicabi= lity).=20 I think there is a near and medium term need for both efforts. There has al= so been a lot of recent work to harmonize the efforts.=20 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >Sent: Sunday, September 23, 2012 11:15 AM >To: Baker, Jon; Waltermire, David A.; sacm@ietf.org >Subject: RE: SACM BoF Request > >Hi Jon, > >With the recent approval of CPE specifications by the ITU-T, these are now >formal recommendations and I believe the full content was included in thes= e >Recommendations (5 total Recommendations), is that correct? If the group >were to select either CPE or SWID, it would need to be by reference now, >correct? > >Best regards, >Kathleen > >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Baker, Jon >Sent: Sunday, September 23, 2012 5:59 AM >To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >Also, I noticed the following: > >>- A Standards Track document specifying platform naming >>- A Standards Track document specifying platform matching >>- A Standards Track document specifying platform applicability > >Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicabili= ty >Language. Has the group considered the SWID specification (ISO/IEC 19770-2= ). >The following page and its referenced document may be of help in >considering how cpe and swids fit together: > >http://tagvault.org/Automating_CPE_name_creation > > >Jon > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Jonathan O. Baker >G022 - IA Industry Collaboration >The MITRE Corporation >Email: bakerj@mitre.org > > >>-----Original Message----- >>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>Moriarty, Kathleen >>Sent: Friday, September 21, 2012 4:32 PM >>To: Waltermire, David A.; sacm@ietf.org >>Subject: Re: [sacm] SACM BoF Request >> >>Hello, >> >>I am including an updated version of the SACM Charter that includes more = of >>an emphasis on the protocols to share and exchange data within and >between >>enterprises/organizations. Please feel free to provide feedback to the l= ist! >> >>Thanks & have a good weekend! >>Kathleen >> >> >> >>BOF full name: Security Automation and Continuous Monitoring [SACM] >>AREA: Security >>BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >> David Waltermire (david.waltermire@nist.gov) >>Agenda: >> >>* Review the draft charter >>* Review draft-waltermire-sacm-use-cases-02 >>* Review drafts submitted in support of the charter >> - draft-waltermire-content-repository-00 >> - More expected before -00 deadline >> >>Full Description of BOF: The SACM BoF is intended to progress the work fr= om >>the SACM mailing list to solidify discussions on a proposed charter, use = cases >>and milestones in support of moving to an IETF working group. >> >>CONFLICTS to avoid: SAAG, MILE >>Expected Attendance: 40, not sure what the previous attendance was? >>Special Requests: Meetecho support >>Number of sessions: 1 >>Length of session: 2 hours >> >>Draft Charter: >> >>Proposed Working Group Charter >> >>Chairs: >>TBD >>TBD >> >>Security Area Directors: >> Stephen Farrell >> Sean Turner >> >>Security Area Advisor: >> Sean Turner >> >>Mailing Lists: >> General Discussion: sacm@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >> Archive: http://www.ietf.org/mail-archive/web/sacm >> >>Description of Working Group >> >>Securing information and the systems that store, process, and transmit th= at >>information has become a challenging task for organizations of all sizes,= and >>we find that security practitioners spend most of their time on manual >>processes relegating them to ineffectiveness. Security automation to veri= fy >>system configurations with the ability to prioritize risk based on increa= sed >>situational awareness from shared intelligence is the key to escaping thi= s rut. >>This working group will develop security automation protocols and data >>format standards in support of information security processes and practic= es >>where practical. These standards will help security practitioners to be b= etter >>utilized within their organizations by automating routine tasks related t= o >>endpoint and server security so that practitioners can focus on more >>advanced tasks. The initial focus of this work is to address enterprise u= se >>cases. >> >>The working group will achieve this by enabling the exchange of shared >>intelligence and continuing the security automation work already performe= d >>by various organizations around the world. The initial work has been fru= itful, >>and the data formats previously published are ready for expansion on the >>international stage. Of particular interest to this working group are the >>security automation specifications supporting asset, change, configuratio= n, >>and vulnerability management. Of additional interest to this working grou= p >>are the emerging security automation interfaces and data formats relating= to >>event management and continuous assessment. The continuous >assessment >>capabilities enable organizational situational awareness through frequent >>snapshots of the operating state of their environment, with risk prioriti= zed >>based on consumed information provided by shared intelligence >>(vulnerabilities, threats, etc.). >> >>By undertaking this work, we recognize that there are multiple categories= of >>problems in the security automation domain: enabling interoperable data >>exchanges through standardized protocols, defining expressions for >particular >>domain concepts (i.e. data formats), establishing a standards-based >>foundation supporting the curation and exchange of security automation >>content collections in content repositories, and enabling interoperabilit= y >>through the development and use of standard interfaces and >communications >>protocols. Content based on rich data standards and protocols will provid= e >the >>authoritative instructions needed by data-driven tools to enable the >>automated collection and exchange of configuration and vulnerability data >>pertaining to enterprise assets. Information produced by these tools will >>provide accurate and timely situational awareness in support of >organizational >>decision making. >> >>The data exchange protocols will need to meet several exchange types >>including those between and within organizations for sharing intelligence >data >>to increase situational awareness, report exchanges both internal and >>external to an enterprise, and those between enterprise servers and end >>points for assessments >> >>This working group will provide solutions to these categories of problems >and >>the main areas of focus for this working group are described as follows: >> >>1. Define, either by normative reference, adoption, or creation, a set of >>standards to enable the exchange of data to increase situational awarenes= s >or >>gain access to shared content to improve the security posture of an >>enterprise. This area of focus provides for the integration of interoper= able >>protocols to access shared data repositories between organizations to >>increase situational awareness and reduce risks to an enterprise. In sup= port >>of accessing shared intelligence for expected system state and related ri= sks, >>define, either by normative reference, adoption, or creation, a set of >>standards that can be used for the purpose of assessing and aggregating >>device states and comparing these device states against expected values, >and >>reporting on those results in a predefined or ad hoc manner. This area o= f >>focus provides for necessary language and data format specifications. >> >>3. Define, either by normative reference, adoption, or creation, a set of >>standards that can be used to continuously assess and report on the state= of >>systems, composed of many different types of devices and networks, >>operated by varying personnel, to ensure security process effectiveness i= n a >>pre-defined or ad-hoc manner. This area of focus provides for integratio= n >>protocols supporting plug and play continuous assessment and security >>automation networking within an enterprise. >> >>This working group will achieve the following milestones in two phases: >> >>Phase One >>- A standards track document to define a protocol for interacting with >content >>repositories >>- Standards Track document specifying security automation/continuous >>assessment interfaces >>- A Standards Track document specifying communication protocols used for >>security automation and continuous assessment >>- A Standards Track document describing the messages and network >protocols >>for distributing security automation content (content repository) >>- A Standards Track document describing protocols and data formats for >>securely sharing dynamic network state information among security systems >>- A Standards Track document specifying asset description format >>- A Standards Track document specifying asset identification >>- A Standards Track document specifying platform naming >>- A Standards Track document specifying platform matching >>- A Standards Track document specifying platform applicability >> >>Phase Two >>- A Standards Track document specifying a control framework representatio= n >>format. >>- A Standards Track document specifying benchmark configuration >>representation >>- An Informational document stating guidelines / requirements for specify= ing >>checking languages >>- Standards Track documents specifying device state checking languages >>- A Standards Track document specifying an interrogative checking languag= e >>- A Standards Track document specifying asset reporting information >>- Standards Track document describing how to use the languages and other >>content defined in this group with the NEA protocols >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Tue Sep 25 19:27:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB121F8505 for ; Tue, 25 Sep 2012 19:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 7aRxn+dF9trf for ; Tue, 25 Sep 2012 19:27:46 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7321F847F for ; Tue, 25 Sep 2012 19:27:45 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8Q2RiQV001312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 22:27:44 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 25 Sep 2012 22:27:33 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8Q2RWDb012519; Tue, 25 Sep 2012 22:27:33 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Tue, 25 Sep 2012 22:27:18 -0400 From: "Moriarty, Kathleen" To: "Baker, Jon" Date: Tue, 25 Sep 2012 22:27:13 -0400 Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2bjnLOHS1tOOb7QWatiXgrh9wsRA== Message-ID: References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov> <6C1C15D8B5510B4B8FF132B10D3865130225EEB0@IMCMBX03.MITRE.ORG> <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 02:27:47 -0000 Thanks for the explanation. I would like to hear from more folks to ensure= we work to developing consensus on the approach. The main focus should be= on the charter to ensure we are able to achieve the charter objectives and= associated milestones to fulfill the agreed upon use cases. I will help w= ith gathering the consensus on the charter discussions. For those new to a list like SACM, a "+1" is enough to show support for a r= esponse/approach or providing alternate opinions and approaches are also we= lcome. My responses will be a little delayed over the next few days. Thank you! Kathleen =20 Sent from my iPhone On Sep 25, 2012, at 10:07 PM, "Baker, Jon" wrote: > In your message below, you say "select either CPE or SWID". I really have= not looked at it as a one or the other decision. >=20 > I believe that there remains a need for both efforts. SWIDs are well suit= ed for identifying specific instances of installed software all the way dow= n to the patch level. However, SWIDS are not currently designed to support = what we have referred to as abstract names like "Windows 7". Security guida= nce is generally written to target these sorts of abstractions. Vulnerabili= ty information is often reported and shared using these sorts of abstractio= ns. For example, "Flash 1.2.3 has a zero day vulnerability that is actively= being exploited." Enterprise reporting also tends to leverage this abstrac= tion capability. To make this work you end up needing a way to determine if= one name matches another (CPE Matching Spec) and a way to state that somet= hing (benchmark/vulnerability/etc) applies to a given platform (CPE Applica= bility). >=20 > I think there is a near and medium term need for both efforts. There has = also been a lot of recent work to harmonize the efforts. >=20 > Jon >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org >=20 >=20 >> -----Original Message----- >> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >> Sent: Sunday, September 23, 2012 11:15 AM >> To: Baker, Jon; Waltermire, David A.; sacm@ietf.org >> Subject: RE: SACM BoF Request >>=20 >> Hi Jon, >>=20 >> With the recent approval of CPE specifications by the ITU-T, these are n= ow >> formal recommendations and I believe the full content was included in th= ese >> Recommendations (5 total Recommendations), is that correct? If the grou= p >> were to select either CPE or SWID, it would need to be by reference now, >> correct? >>=20 >> Best regards, >> Kathleen >>=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Baker, Jon >> Sent: Sunday, September 23, 2012 5:59 AM >> To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM BoF Request >>=20 >> Also, I noticed the following: >>=20 >>> - A Standards Track document specifying platform naming >>> - A Standards Track document specifying platform matching >>> - A Standards Track document specifying platform applicability >>=20 >> Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicabi= lity >> Language. Has the group considered the SWID specification (ISO/IEC 19770= -2). >> The following page and its referenced document may be of help in >> considering how cpe and swids fit together: >>=20 >> http://tagvault.org/Automating_CPE_name_creation >>=20 >>=20 >> Jon >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Jonathan O. Baker >> G022 - IA Industry Collaboration >> The MITRE Corporation >> Email: bakerj@mitre.org >>=20 >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Moriarty, Kathleen >>> Sent: Friday, September 21, 2012 4:32 PM >>> To: Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] SACM BoF Request >>>=20 >>> Hello, >>>=20 >>> I am including an updated version of the SACM Charter that includes mor= e of >>> an emphasis on the protocols to share and exchange data within and >> between >>> enterprises/organizations. Please feel free to provide feedback to the= list! >>>=20 >>> Thanks & have a good weekend! >>> Kathleen >>>=20 >>>=20 >>>=20 >>> BOF full name: Security Automation and Continuous Monitoring [SACM] >>> AREA: Security >>> BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>> David Waltermire (david.waltermire@nist.gov) >>> Agenda: >>>=20 >>> * Review the draft charter >>> * Review draft-waltermire-sacm-use-cases-02 >>> * Review drafts submitted in support of the charter >>> - draft-waltermire-content-repository-00 >>> - More expected before -00 deadline >>>=20 >>> Full Description of BOF: The SACM BoF is intended to progress the work = from >>> the SACM mailing list to solidify discussions on a proposed charter, us= e cases >>> and milestones in support of moving to an IETF working group. >>>=20 >>> CONFLICTS to avoid: SAAG, MILE >>> Expected Attendance: 40, not sure what the previous attendance was? >>> Special Requests: Meetecho support >>> Number of sessions: 1 >>> Length of session: 2 hours >>>=20 >>> Draft Charter: >>>=20 >>> Proposed Working Group Charter >>>=20 >>> Chairs: >>> TBD >>> TBD >>>=20 >>> Security Area Directors: >>> Stephen Farrell >>> Sean Turner >>>=20 >>> Security Area Advisor: >>> Sean Turner >>>=20 >>> Mailing Lists: >>> General Discussion: sacm@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>> Archive: http://www.ietf.org/mail-archive/web/sacm >>>=20 >>> Description of Working Group >>>=20 >>> Securing information and the systems that store, process, and transmit = that >>> information has become a challenging task for organizations of all size= s, and >>> we find that security practitioners spend most of their time on manual >>> processes relegating them to ineffectiveness. Security automation to ve= rify >>> system configurations with the ability to prioritize risk based on incr= eased >>> situational awareness from shared intelligence is the key to escaping t= his rut. >>> This working group will develop security automation protocols and data >>> format standards in support of information security processes and pract= ices >>> where practical. These standards will help security practitioners to be= better >>> utilized within their organizations by automating routine tasks related= to >>> endpoint and server security so that practitioners can focus on more >>> advanced tasks. The initial focus of this work is to address enterprise= use >>> cases. >>>=20 >>> The working group will achieve this by enabling the exchange of shared >>> intelligence and continuing the security automation work already perfor= med >>> by various organizations around the world. The initial work has been f= ruitful, >>> and the data formats previously published are ready for expansion on th= e >>> international stage. Of particular interest to this working group are t= he >>> security automation specifications supporting asset, change, configurat= ion, >>> and vulnerability management. Of additional interest to this working gr= oup >>> are the emerging security automation interfaces and data formats relati= ng to >>> event management and continuous assessment. The continuous >> assessment >>> capabilities enable organizational situational awareness through freque= nt >>> snapshots of the operating state of their environment, with risk priori= tized >>> based on consumed information provided by shared intelligence >>> (vulnerabilities, threats, etc.). >>>=20 >>> By undertaking this work, we recognize that there are multiple categori= es of >>> problems in the security automation domain: enabling interoperable data >>> exchanges through standardized protocols, defining expressions for >> particular >>> domain concepts (i.e. data formats), establishing a standards-based >>> foundation supporting the curation and exchange of security automation >>> content collections in content repositories, and enabling interoperabil= ity >>> through the development and use of standard interfaces and >> communications >>> protocols. Content based on rich data standards and protocols will prov= ide >> the >>> authoritative instructions needed by data-driven tools to enable the >>> automated collection and exchange of configuration and vulnerability da= ta >>> pertaining to enterprise assets. Information produced by these tools wi= ll >>> provide accurate and timely situational awareness in support of >> organizational >>> decision making. >>>=20 >>> The data exchange protocols will need to meet several exchange types >>> including those between and within organizations for sharing intelligen= ce >> data >>> to increase situational awareness, report exchanges both internal and >>> external to an enterprise, and those between enterprise servers and end >>> points for assessments >>>=20 >>> This working group will provide solutions to these categories of proble= ms >> and >>> the main areas of focus for this working group are described as follows= : >>>=20 >>> 1. Define, either by normative reference, adoption, or creation, a set = of >>> standards to enable the exchange of data to increase situational awaren= ess >> or >>> gain access to shared content to improve the security posture of an >>> enterprise. This area of focus provides for the integration of interop= erable >>> protocols to access shared data repositories between organizations to >>> increase situational awareness and reduce risks to an enterprise. In s= upport >>> of accessing shared intelligence for expected system state and related = risks, >>> define, either by normative reference, adoption, or creation, a set of >>> standards that can be used for the purpose of assessing and aggregating >>> device states and comparing these device states against expected values= , >> and >>> reporting on those results in a predefined or ad hoc manner. This area= of >>> focus provides for necessary language and data format specifications. >>>=20 >>> 3. Define, either by normative reference, adoption, or creation, a set = of >>> standards that can be used to continuously assess and report on the sta= te of >>> systems, composed of many different types of devices and networks, >>> operated by varying personnel, to ensure security process effectiveness= in a >>> pre-defined or ad-hoc manner. This area of focus provides for integrat= ion >>> protocols supporting plug and play continuous assessment and security >>> automation networking within an enterprise. >>>=20 >>> This working group will achieve the following milestones in two phases: >>>=20 >>> Phase One >>> - A standards track document to define a protocol for interacting with >> content >>> repositories >>> - Standards Track document specifying security automation/continuous >>> assessment interfaces >>> - A Standards Track document specifying communication protocols used fo= r >>> security automation and continuous assessment >>> - A Standards Track document describing the messages and network >> protocols >>> for distributing security automation content (content repository) >>> - A Standards Track document describing protocols and data formats for >>> securely sharing dynamic network state information among security syste= ms >>> - A Standards Track document specifying asset description format >>> - A Standards Track document specifying asset identification >>> - A Standards Track document specifying platform naming >>> - A Standards Track document specifying platform matching >>> - A Standards Track document specifying platform applicability >>>=20 >>> Phase Two >>> - A Standards Track document specifying a control framework representat= ion >>> format. >>> - A Standards Track document specifying benchmark configuration >>> representation >>> - An Informational document stating guidelines / requirements for speci= fying >>> checking languages >>> - Standards Track documents specifying device state checking languages >>> - A Standards Track document specifying an interrogative checking langu= age >>> - A Standards Track document specifying asset reporting information >>> - Standards Track document describing how to use the languages and othe= r >>> content defined in this group with the NEA protocols >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From amontville@tripwire.com Tue Sep 25 20:36:48 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68421F861C for ; Tue, 25 Sep 2012 20:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8ynnJlbo+fqV for ; Tue, 25 Sep 2012 20:36:47 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1D221F8618 for ; Tue, 25 Sep 2012 20:36:46 -0700 (PDT) Received: from mail60-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 03:36:46 +0000 Received: from mail60-co1 (localhost [127.0.0.1]) by mail60-co1-R.bigfish.com (Postfix) with ESMTP id 31AAE84008F for ; Wed, 26 Sep 2012 03:36:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zzbb2dI98dI9371I1454I542M1432Ic25dL62a3Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh177df4hz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail60-co1 (localhost.localdomain [127.0.0.1]) by mail60-co1 (MessageSwitch) id 1348630604828821_1140; Wed, 26 Sep 2012 03:36:44 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.231]) by mail60-co1.bigfish.com (Postfix) with ESMTP id C6654700048 for ; Wed, 26 Sep 2012 03:36:44 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 03:36:44 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 3634C2321235 for ; Tue, 25 Sep 2012 20:31:39 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 824BE232121E; Tue, 25 Sep 2012 20:31:38 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 25 Sep 2012 20:39:52 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Tue, 25 Sep 2012 20:36:42 -0700 From: Adam Montville To: "Baker, Jon" , "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEgAHsIJlAAA4gjAA== Date: Wed, 26 Sep 2012 03:36:42 +0000 Message-ID: In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> 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: [172.16.97.85] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <4686A7931B381E44A88F8A4ABD18DFDA@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 83a516f2-cc9b-4257-9e68-f58ec9ad3cca X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 03:36:48 -0000 On 9/25/12 7:06 PM, "Baker, Jon" wrote: >In your message below, you say "select either CPE or SWID". I really have >not looked at it as a one or the other decision. > >I believe that there remains a need for both efforts. SWIDs are well >suited for identifying specific instances of installed software all the >way down to the patch level. However, SWIDS are not currently designed to >support what we have referred to as abstract names like "Windows 7". >Security guidance is generally written to target these sorts of >abstractions. Vulnerability information is often reported and shared >using these sorts of abstractions. For example, "Flash 1.2.3 has a zero >day vulnerability that is actively being exploited." Enterprise reporting >also tends to leverage this abstraction capability. To make this work you >end up needing a way to determine if one name matches another (CPE >Matching Spec) and a way to state that something >(benchmark/vulnerability/etc) applies to a given platform (CPE >Applicability).=20 > >I think there is a near and medium term need for both efforts. There has >also been a lot of recent work to harmonize the efforts. >From your description, it seems that SWIDs are more specific than CPEs, and you have made a clear case in favor of leveraging CPE. How would we leverage SWIDs? I ask because I am more familiar with CPEs than I am with SWIDs, and I think I see an overlap, but not sure why both would be needed (not saying they couldn't be - just asking what your full perspective is). >=20 > >Jon > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Jonathan O. Baker >G022 - IA Industry Collaboration >The MITRE Corporation >Email: bakerj@mitre.org > > >>-----Original Message----- >>From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>Sent: Sunday, September 23, 2012 11:15 AM >>To: Baker, Jon; Waltermire, David A.; sacm@ietf.org >>Subject: RE: SACM BoF Request >> >>Hi Jon, >> >>With the recent approval of CPE specifications by the ITU-T, these are >>now >>formal recommendations and I believe the full content was included in >>these >>Recommendations (5 total Recommendations), is that correct? If the group >>were to select either CPE or SWID, it would need to be by reference now, >>correct? >> >>Best regards, >>Kathleen >> >>-----Original Message----- >>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>Baker, Jon >>Sent: Sunday, September 23, 2012 5:59 AM >>To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >>Subject: Re: [sacm] SACM BoF Request >> >>Also, I noticed the following: >> >>>- A Standards Track document specifying platform naming >>>- A Standards Track document specifying platform matching >>>- A Standards Track document specifying platform applicability >> >>Those seem to roughly align with CPE Naming, CPE Matching, CPE >>Applicability >>Language. Has the group considered the SWID specification (ISO/IEC >>19770-2). >>The following page and its referenced document may be of help in >>considering how cpe and swids fit together: >> >>http://tagvault.org/Automating_CPE_name_creation >> >> >>Jon >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Jonathan O. Baker >>G022 - IA Industry Collaboration >>The MITRE Corporation >>Email: bakerj@mitre.org >> >> >>>-----Original Message----- >>>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>>Moriarty, Kathleen >>>Sent: Friday, September 21, 2012 4:32 PM >>>To: Waltermire, David A.; sacm@ietf.org >>>Subject: Re: [sacm] SACM BoF Request >>> >>>Hello, >>> >>>I am including an updated version of the SACM Charter that includes >>>more of >>>an emphasis on the protocols to share and exchange data within and >>between >>>enterprises/organizations. Please feel free to provide feedback to the >>>list! >>> >>>Thanks & have a good weekend! >>>Kathleen >>> >>> >>> >>>BOF full name: Security Automation and Continuous Monitoring [SACM] >>>AREA: Security >>>BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>> David Waltermire (david.waltermire@nist.gov) >>>Agenda: >>> >>>* Review the draft charter >>>* Review draft-waltermire-sacm-use-cases-02 >>>* Review drafts submitted in support of the charter >>> - draft-waltermire-content-repository-00 >>> - More expected before -00 deadline >>> >>>Full Description of BOF: The SACM BoF is intended to progress the work >>>from >>>the SACM mailing list to solidify discussions on a proposed charter, >>>use cases >>>and milestones in support of moving to an IETF working group. >>> >>>CONFLICTS to avoid: SAAG, MILE >>>Expected Attendance: 40, not sure what the previous attendance was? >>>Special Requests: Meetecho support >>>Number of sessions: 1 >>>Length of session: 2 hours >>> >>>Draft Charter: >>> >>>Proposed Working Group Charter >>> >>>Chairs: >>>TBD >>>TBD >>> >>>Security Area Directors: >>> Stephen Farrell >>> Sean Turner >>> >>>Security Area Advisor: >>> Sean Turner >>> >>>Mailing Lists: >>> General Discussion: sacm@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>> Archive: http://www.ietf.org/mail-archive/web/sacm >>> >>>Description of Working Group >>> >>>Securing information and the systems that store, process, and transmit >>>that >>>information has become a challenging task for organizations of all >>>sizes, and >>>we find that security practitioners spend most of their time on manual >>>processes relegating them to ineffectiveness. Security automation to >>>verify >>>system configurations with the ability to prioritize risk based on >>>increased >>>situational awareness from shared intelligence is the key to escaping >>>this rut. >>>This working group will develop security automation protocols and data >>>format standards in support of information security processes and >>>practices >>>where practical. These standards will help security practitioners to be >>>better >>>utilized within their organizations by automating routine tasks related >>>to >>>endpoint and server security so that practitioners can focus on more >>>advanced tasks. The initial focus of this work is to address enterprise >>>use >>>cases. >>> >>>The working group will achieve this by enabling the exchange of shared >>>intelligence and continuing the security automation work already >>>performed >>>by various organizations around the world. The initial work has been >>>fruitful, >>>and the data formats previously published are ready for expansion on the >>>international stage. Of particular interest to this working group are >>>the >>>security automation specifications supporting asset, change, >>>configuration, >>>and vulnerability management. Of additional interest to this working >>>group >>>are the emerging security automation interfaces and data formats >>>relating to >>>event management and continuous assessment. The continuous >>assessment >>>capabilities enable organizational situational awareness through >>>frequent >>>snapshots of the operating state of their environment, with risk >>>prioritized >>>based on consumed information provided by shared intelligence >>>(vulnerabilities, threats, etc.). >>> >>>By undertaking this work, we recognize that there are multiple >>>categories of >>>problems in the security automation domain: enabling interoperable data >>>exchanges through standardized protocols, defining expressions for >>particular >>>domain concepts (i.e. data formats), establishing a standards-based >>>foundation supporting the curation and exchange of security automation >>>content collections in content repositories, and enabling >>>interoperability >>>through the development and use of standard interfaces and >>communications >>>protocols. Content based on rich data standards and protocols will >>>provide >>the >>>authoritative instructions needed by data-driven tools to enable the >>>automated collection and exchange of configuration and vulnerability >>>data >>>pertaining to enterprise assets. Information produced by these tools >>>will >>>provide accurate and timely situational awareness in support of >>organizational >>>decision making. >>> >>>The data exchange protocols will need to meet several exchange types >>>including those between and within organizations for sharing >>>intelligence >>data >>>to increase situational awareness, report exchanges both internal and >>>external to an enterprise, and those between enterprise servers and end >>>points for assessments >>> >>>This working group will provide solutions to these categories of >>>problems >>and >>>the main areas of focus for this working group are described as follows: >>> >>>1. Define, either by normative reference, adoption, or creation, a set >>>of >>>standards to enable the exchange of data to increase situational >>>awareness >>or >>>gain access to shared content to improve the security posture of an >>>enterprise. This area of focus provides for the integration of >>>interoperable >>>protocols to access shared data repositories between organizations to >>>increase situational awareness and reduce risks to an enterprise. In >>>support >>>of accessing shared intelligence for expected system state and related >>>risks, >>>define, either by normative reference, adoption, or creation, a set of >>>standards that can be used for the purpose of assessing and aggregating >>>device states and comparing these device states against expected values, >>and >>>reporting on those results in a predefined or ad hoc manner. This area >>>of >>>focus provides for necessary language and data format specifications. >>> >>>3. Define, either by normative reference, adoption, or creation, a set >>>of >>>standards that can be used to continuously assess and report on the >>>state of >>>systems, composed of many different types of devices and networks, >>>operated by varying personnel, to ensure security process effectiveness >>>in a >>>pre-defined or ad-hoc manner. This area of focus provides for >>>integration >>>protocols supporting plug and play continuous assessment and security >>>automation networking within an enterprise. >>> >>>This working group will achieve the following milestones in two phases: >>> >>>Phase One >>>- A standards track document to define a protocol for interacting with >>content >>>repositories >>>- Standards Track document specifying security automation/continuous >>>assessment interfaces >>>- A Standards Track document specifying communication protocols used for >>>security automation and continuous assessment >>>- A Standards Track document describing the messages and network >>protocols >>>for distributing security automation content (content repository) >>>- A Standards Track document describing protocols and data formats for >>>securely sharing dynamic network state information among security >>>systems >>>- A Standards Track document specifying asset description format >>>- A Standards Track document specifying asset identification >>>- A Standards Track document specifying platform naming >>>- A Standards Track document specifying platform matching >>>- A Standards Track document specifying platform applicability >>> >>>Phase Two >>>- A Standards Track document specifying a control framework >>>representation >>>format. >>>- A Standards Track document specifying benchmark configuration >>>representation >>>- An Informational document stating guidelines / requirements for >>>specifying >>>checking languages >>>- Standards Track documents specifying device state checking languages >>>- A Standards Track document specifying an interrogative checking >>>language >>>- A Standards Track document specifying asset reporting information >>>- Standards Track document describing how to use the languages and other >>>content defined in this group with the NEA protocols >>>_______________________________________________ >>>sacm mailing list >>>sacm@ietf.org >>>https://www.ietf.org/mailman/listinfo/sacm >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > > From bakerj@mitre.org Wed Sep 26 03:00:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF2221F8820 for ; Wed, 26 Sep 2012 03:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 81pMLYjZX+vP for ; Wed, 26 Sep 2012 03:00:37 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id D733E21F880B for ; Wed, 26 Sep 2012 03:00:36 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 333A249F0023; Wed, 26 Sep 2012 06:00:36 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtptsrv1.mitre.org (Postfix) with ESMTP id 10E1749F0033; Wed, 26 Sep 2012 06:00:35 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.178]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 06:00:35 -0400 From: "Baker, Jon" To: Adam Montville , "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEgAHsIJlAAA4gjAAAM+nnA Date: Wed, 26 Sep 2012 10:00:35 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D3865130227FE36@IMCMBX03.MITRE.ORG> References: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 10:00:38 -0000 I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID.=20 SWIDs are essentially an xml file created when a package is installed that = can contain detailed information about that package and some of the configu= ration options that were selected at install time. They are tied to a speci= fic package and can be updated when patches are installed. The SWID may con= tain the name version and publisher of the software as well as installation= files and their hashes, registry keys created, etc. This then can give you= a fairly detailed description of the installed software on a system to sup= port a number of use cases.=20 The tagvault website has a paper that talks about the connection between sw= ids and cpe: http://tagvault.org/Automating_CPE_name_creation Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: Adam Montville [mailto:amontville@tripwire.com] >Sent: Tuesday, September 25, 2012 11:37 PM >To: Baker, Jon; Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >Subject: Re: [sacm] SACM BoF Request > >On 9/25/12 7:06 PM, "Baker, Jon" wrote: > >>In your message below, you say "select either CPE or SWID". I really have >>not looked at it as a one or the other decision. >> >>I believe that there remains a need for both efforts. SWIDs are well >>suited for identifying specific instances of installed software all the >>way down to the patch level. However, SWIDS are not currently designed to >>support what we have referred to as abstract names like "Windows 7". >>Security guidance is generally written to target these sorts of >>abstractions. Vulnerability information is often reported and shared >>using these sorts of abstractions. For example, "Flash 1.2.3 has a zero >>day vulnerability that is actively being exploited." Enterprise reporting >>also tends to leverage this abstraction capability. To make this work you >>end up needing a way to determine if one name matches another (CPE >>Matching Spec) and a way to state that something >>(benchmark/vulnerability/etc) applies to a given platform (CPE >>Applicability). >> >>I think there is a near and medium term need for both efforts. There has >>also been a lot of recent work to harmonize the efforts. > >From your description, it seems that SWIDs are more specific than CPEs, >and you have made a clear case in favor of leveraging CPE. How would we >leverage SWIDs? I ask because I am more familiar with CPEs than I am with >SWIDs, and I think I see an overlap, but not sure why both would be needed >(not saying they couldn't be - just asking what your full perspective is). > > >> >> >>Jon >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Jonathan O. Baker >>G022 - IA Industry Collaboration >>The MITRE Corporation >>Email: bakerj@mitre.org >> >> >>>-----Original Message----- >>>From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>Sent: Sunday, September 23, 2012 11:15 AM >>>To: Baker, Jon; Waltermire, David A.; sacm@ietf.org >>>Subject: RE: SACM BoF Request >>> >>>Hi Jon, >>> >>>With the recent approval of CPE specifications by the ITU-T, these are >>>now >>>formal recommendations and I believe the full content was included in >>>these >>>Recommendations (5 total Recommendations), is that correct? If the grou= p >>>were to select either CPE or SWID, it would need to be by reference now, >>>correct? >>> >>>Best regards, >>>Kathleen >>> >>>-----Original Message----- >>>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >Of >>>Baker, Jon >>>Sent: Sunday, September 23, 2012 5:59 AM >>>To: Moriarty, Kathleen; Waltermire, David A.; sacm@ietf.org >>>Subject: Re: [sacm] SACM BoF Request >>> >>>Also, I noticed the following: >>> >>>>- A Standards Track document specifying platform naming >>>>- A Standards Track document specifying platform matching >>>>- A Standards Track document specifying platform applicability >>> >>>Those seem to roughly align with CPE Naming, CPE Matching, CPE >>>Applicability >>>Language. Has the group considered the SWID specification (ISO/IEC >>>19770-2). >>>The following page and its referenced document may be of help in >>>considering how cpe and swids fit together: >>> >>>http://tagvault.org/Automating_CPE_name_creation >>> >>> >>>Jon >>> >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>Jonathan O. Baker >>>G022 - IA Industry Collaboration >>>The MITRE Corporation >>>Email: bakerj@mitre.org >>> >>> >>>>-----Original Message----- >>>>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >Of >>>>Moriarty, Kathleen >>>>Sent: Friday, September 21, 2012 4:32 PM >>>>To: Waltermire, David A.; sacm@ietf.org >>>>Subject: Re: [sacm] SACM BoF Request >>>> >>>>Hello, >>>> >>>>I am including an updated version of the SACM Charter that includes >>>>more of >>>>an emphasis on the protocols to share and exchange data within and >>>between >>>>enterprises/organizations. Please feel free to provide feedback to the >>>>list! >>>> >>>>Thanks & have a good weekend! >>>>Kathleen >>>> >>>> >>>> >>>>BOF full name: Security Automation and Continuous Monitoring [SACM] >>>>AREA: Security >>>>BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com) >>>> David Waltermire (david.waltermire@nist.gov) >>>>Agenda: >>>> >>>>* Review the draft charter >>>>* Review draft-waltermire-sacm-use-cases-02 >>>>* Review drafts submitted in support of the charter >>>> - draft-waltermire-content-repository-00 >>>> - More expected before -00 deadline >>>> >>>>Full Description of BOF: The SACM BoF is intended to progress the work >>>>from >>>>the SACM mailing list to solidify discussions on a proposed charter, >>>>use cases >>>>and milestones in support of moving to an IETF working group. >>>> >>>>CONFLICTS to avoid: SAAG, MILE >>>>Expected Attendance: 40, not sure what the previous attendance was? >>>>Special Requests: Meetecho support >>>>Number of sessions: 1 >>>>Length of session: 2 hours >>>> >>>>Draft Charter: >>>> >>>>Proposed Working Group Charter >>>> >>>>Chairs: >>>>TBD >>>>TBD >>>> >>>>Security Area Directors: >>>> Stephen Farrell >>>> Sean Turner >>>> >>>>Security Area Advisor: >>>> Sean Turner >>>> >>>>Mailing Lists: >>>> General Discussion: sacm@ietf.org >>>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>>> Archive: http://www.ietf.org/mail-archive/web/sacm >>>> >>>>Description of Working Group >>>> >>>>Securing information and the systems that store, process, and transmit >>>>that >>>>information has become a challenging task for organizations of all >>>>sizes, and >>>>we find that security practitioners spend most of their time on manual >>>>processes relegating them to ineffectiveness. Security automation to >>>>verify >>>>system configurations with the ability to prioritize risk based on >>>>increased >>>>situational awareness from shared intelligence is the key to escaping >>>>this rut. >>>>This working group will develop security automation protocols and data >>>>format standards in support of information security processes and >>>>practices >>>>where practical. These standards will help security practitioners to be >>>>better >>>>utilized within their organizations by automating routine tasks related >>>>to >>>>endpoint and server security so that practitioners can focus on more >>>>advanced tasks. The initial focus of this work is to address enterprise >>>>use >>>>cases. >>>> >>>>The working group will achieve this by enabling the exchange of shared >>>>intelligence and continuing the security automation work already >>>>performed >>>>by various organizations around the world. The initial work has been >>>>fruitful, >>>>and the data formats previously published are ready for expansion on th= e >>>>international stage. Of particular interest to this working group are >>>>the >>>>security automation specifications supporting asset, change, >>>>configuration, >>>>and vulnerability management. Of additional interest to this working >>>>group >>>>are the emerging security automation interfaces and data formats >>>>relating to >>>>event management and continuous assessment. The continuous >>>assessment >>>>capabilities enable organizational situational awareness through >>>>frequent >>>>snapshots of the operating state of their environment, with risk >>>>prioritized >>>>based on consumed information provided by shared intelligence >>>>(vulnerabilities, threats, etc.). >>>> >>>>By undertaking this work, we recognize that there are multiple >>>>categories of >>>>problems in the security automation domain: enabling interoperable data >>>>exchanges through standardized protocols, defining expressions for >>>particular >>>>domain concepts (i.e. data formats), establishing a standards-based >>>>foundation supporting the curation and exchange of security automation >>>>content collections in content repositories, and enabling >>>>interoperability >>>>through the development and use of standard interfaces and >>>communications >>>>protocols. Content based on rich data standards and protocols will >>>>provide >>>the >>>>authoritative instructions needed by data-driven tools to enable the >>>>automated collection and exchange of configuration and vulnerability >>>>data >>>>pertaining to enterprise assets. Information produced by these tools >>>>will >>>>provide accurate and timely situational awareness in support of >>>organizational >>>>decision making. >>>> >>>>The data exchange protocols will need to meet several exchange types >>>>including those between and within organizations for sharing >>>>intelligence >>>data >>>>to increase situational awareness, report exchanges both internal and >>>>external to an enterprise, and those between enterprise servers and end >>>>points for assessments >>>> >>>>This working group will provide solutions to these categories of >>>>problems >>>and >>>>the main areas of focus for this working group are described as follows= : >>>> >>>>1. Define, either by normative reference, adoption, or creation, a set >>>>of >>>>standards to enable the exchange of data to increase situational >>>>awareness >>>or >>>>gain access to shared content to improve the security posture of an >>>>enterprise. This area of focus provides for the integration of >>>>interoperable >>>>protocols to access shared data repositories between organizations to >>>>increase situational awareness and reduce risks to an enterprise. In >>>>support >>>>of accessing shared intelligence for expected system state and related >>>>risks, >>>>define, either by normative reference, adoption, or creation, a set of >>>>standards that can be used for the purpose of assessing and aggregating >>>>device states and comparing these device states against expected values= , >>>and >>>>reporting on those results in a predefined or ad hoc manner. This area >>>>of >>>>focus provides for necessary language and data format specifications. >>>> >>>>3. Define, either by normative reference, adoption, or creation, a set >>>>of >>>>standards that can be used to continuously assess and report on the >>>>state of >>>>systems, composed of many different types of devices and networks, >>>>operated by varying personnel, to ensure security process effectiveness >>>>in a >>>>pre-defined or ad-hoc manner. This area of focus provides for >>>>integration >>>>protocols supporting plug and play continuous assessment and security >>>>automation networking within an enterprise. >>>> >>>>This working group will achieve the following milestones in two phases: >>>> >>>>Phase One >>>>- A standards track document to define a protocol for interacting with >>>content >>>>repositories >>>>- Standards Track document specifying security automation/continuous >>>>assessment interfaces >>>>- A Standards Track document specifying communication protocols used >for >>>>security automation and continuous assessment >>>>- A Standards Track document describing the messages and network >>>protocols >>>>for distributing security automation content (content repository) >>>>- A Standards Track document describing protocols and data formats for >>>>securely sharing dynamic network state information among security >>>>systems >>>>- A Standards Track document specifying asset description format >>>>- A Standards Track document specifying asset identification >>>>- A Standards Track document specifying platform naming >>>>- A Standards Track document specifying platform matching >>>>- A Standards Track document specifying platform applicability >>>> >>>>Phase Two >>>>- A Standards Track document specifying a control framework >>>>representation >>>>format. >>>>- A Standards Track document specifying benchmark configuration >>>>representation >>>>- An Informational document stating guidelines / requirements for >>>>specifying >>>>checking languages >>>>- Standards Track documents specifying device state checking languages >>>>- A Standards Track document specifying an interrogative checking >>>>language >>>>- A Standards Track document specifying asset reporting information >>>>- Standards Track document describing how to use the languages and >other >>>>content defined in this group with the NEA protocols >>>>_______________________________________________ >>>>sacm mailing list >>>>sacm@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sacm >>>_______________________________________________ >>>sacm mailing list >>>sacm@ietf.org >>>https://www.ietf.org/mailman/listinfo/sacm >> >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >> >> > > > From jan-oliver.wagner@greenbone.net Wed Sep 26 03:28:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C021F8645 for ; Wed, 26 Sep 2012 03:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] 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 2Xl2rVWeCacD for ; Wed, 26 Sep 2012 03:28:40 -0700 (PDT) Received: from kolab.intevation.de (aktaia.intevation.org [212.95.126.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF5421F8445 for ; Wed, 26 Sep 2012 03:28:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 4D85994D177 for ; Wed, 26 Sep 2012 12:28:38 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 64F1494D17D for ; Wed, 26 Sep 2012 12:28:37 +0200 (CEST) Received: from euarne.hq.intevation.de (euarne.hq.intevation.de [192.168.11.56]) (Authenticated sender: jan-oliver.wagner@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 464B594D174; Wed, 26 Sep 2012 12:28:37 +0200 (CEST) From: "Jan-Oliver Wagner" Organization: Greenbone Networks GmbH To: sacm@ietf.org Date: Wed, 26 Sep 2012 12:28:34 +0200 User-Agent: KMail/1.9.10 (enterprise35 20120810.d2e3d25) References: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> <6C1C15D8B5510B4B8FF132B10D3865130227FE36@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130227FE36@IMCMBX03.MITRE.ORG> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> Cc: "Moriarty, Kathleen" , "Waltermire, David A." , "Baker, Jon" , Adam Montville Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 10:28:41 -0000 On Mittwoch, 26. September 2012, Baker, Jon wrote: > I am a big fan of SWIDs and believe that we would really benefit from wid= espread SWID adoption. In my previous message, I was attempting to state th= at we need capabilities offer by both CPE and SWID.=20 I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) =2D-=20 Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From kathleen.moriarty@emc.com Wed Sep 26 04:54:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075F521F87E1 for ; Wed, 26 Sep 2012 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Ah9nPj3ZEbjH for ; Wed, 26 Sep 2012 04:54:44 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 42A5121F87ED for ; Wed, 26 Sep 2012 04:54:43 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8QBrxN5021728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 07:54:05 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 26 Sep 2012 07:53:45 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8QBrj33031085; Wed, 26 Sep 2012 07:53:45 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 26 Sep 2012 07:53:44 -0400 From: "Moriarty, Kathleen" To: Jan-Oliver Wagner Date: Wed, 26 Sep 2012 07:53:40 -0400 Thread-Topic: [sacm] SACM BoF Request Thread-Index: Ac2b3ZO4z+w5HzkwTjCElR1NjKS1Nw== Message-ID: References: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> <6C1C15D8B5510B4B8FF132B10D3865130227FE36@IMCMBX03.MITRE.ORG> <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> In-Reply-To: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> 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: "Waltermire, David A." , "sacm@ietf.org" , "Baker, Jon" , Adam Montville Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:54:45 -0000 UGxlYXNlIERPIGp1bXAgaW50byBhbnkgb2YgdGhlIElFVEYgbGlzdHMgd2hlcmUgeW91IHdhbnQg dG8gdm9pY2UgYW4gb3BpbmlvbiBvciBzdXBwb3J0ISAgVGhhbmsgeW91IQ0KDQpXZSBhcmUgd29y a2luZyB0byBkZXZlbG9wIHRoZSBjaGFydGVyIGZvciB0aGlzIGxpc3QgdG8gYmVjb21lIGEgd29y a2luZyBncm91cCBhbmQgaXQgaXMgaW1wb3J0YW50IHRvIHJlYWNoIHJvdWdoIGNvbnNlbnN1cyBm cm9tIHRoZSBwYXJ0aWNpcGFudHMgd2hvIHdpbGwgZHJpdmUgYW5kIHVzZSB0aGUgcmVzdWx0cy4N Cg0KSXMgdGhlcmUgbW9yZSBzdXBwb3J0IGZvciBib3RoIG9yIG90aGVyIG9waW5pb25zPw0KDQpU aGFua3MsDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIFNlcCAyNiwgMjAx MiwgYXQgNjoyOSBBTSwgIkphbi1PbGl2ZXIgV2FnbmVyIiA8SmFuLU9saXZlci5XYWduZXJAZ3Jl ZW5ib25lLm5ldD4gd3JvdGU6DQoNCj4gT24gTWl0dHdvY2gsIDI2LiBTZXB0ZW1iZXIgMjAxMiwg QmFrZXIsIEpvbiB3cm90ZToNCj4+IEkgYW0gYSBiaWcgZmFuIG9mIFNXSURzIGFuZCBiZWxpZXZl IHRoYXQgd2Ugd291bGQgcmVhbGx5IGJlbmVmaXQgZnJvbSB3aWRlc3ByZWFkIFNXSUQgYWRvcHRp b24uIEluIG15IHByZXZpb3VzIG1lc3NhZ2UsIEkgd2FzIGF0dGVtcHRpbmcgdG8gc3RhdGUgdGhh dCB3ZSBuZWVkIGNhcGFiaWxpdGllcyBvZmZlciBieSBib3RoIENQRSBhbmQgU1dJRC4gDQo+IA0K PiBJIGFtIGEgYmlnIGZhbiBvZiBDUEUgYW5kIGJlbGlldmUgaXQgaXMgZnVsbHkgY29tcGF0aWJs ZSB3aXRoIE9wZW4gU291cmNlIHJlZmVyZW5jZQ0KPiBpbXBsZW1lbnRhdGlvbiBhbmQgd2lkZXNw cmVhZCB1c2UvYWRvcHRpb24gaW4gT3BlbiBTb3VyY2UgdG9vbHMsIGVzcGVjaWFsbHkgYWxzbw0K PiBpbiBjb21tZXJjaWFsIGVudmlyb25tZW50cy4NCj4gDQo+IE5lZ2xlY3RpbmcgQ1BFIGluIGZh dm91ciBvZiBTV0lEIHdvdWxkIElNSE8gYmUgYSBkcmF3YmFjayBmb3Igd2lkZXNwcmVhZCBzZWN1 cml0eQ0KPiBhdXRvbWF0aW9uIGJlY2F1c2UsIGFzIHRvIG15IHVuZGVyc3RhbmRpbmcsIFNXSUQg aXMgbm90IGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB0aGUgdmVuZG9yLWluZGVwZW5kZW50DQo+IGFw cHJvYWNoZXMuIENvbnZpbmNlIG1lIEkgYW0gd3JvbmcgYW5kIEknZCBiZSBoYXBweSA7LSkNCj4g DQo+IA0KPiAoU29ycnkgZm9yIGp1bXBpbmcgaW4gaGVyZSwgaXQgd2FzIGp1c3Qgc29tZXRoaW5n IEkgYW0gd29ycmllZCBhYm91dCBzaW5jZSBzb21lIHRpbWUgYWxyZWFkeQ0KPiBzbyBJIHNwb250 YW5lb3VzbHkgcmVhY3RlZCBvbiB0aGUga2V5d29yZHMgOi0pDQo+IA0KPiANCj4gLS0gDQo+IERy LiBKYW4tT2xpdmVyIFdhZ25lciB8ICArKzQ5LTU0MS0zMzUwODQtMCAgfCAgaHR0cDovL3d3dy5n cmVlbmJvbmUubmV0Lw0KPiBHcmVlbmJvbmUgTmV0d29ya3MgR21iSCwgTmV1ZXIgR3JhYmVuIDE3 LCA0OTA3NCBPc25hYnLDvGNrIHwgQUcgT3NuYWJyw7xjaywgSFIgQiAyMDI0NjANCj4gR2VzY2jD pGZ0c2bDvGhyZXI6IEx1a2FzIEdydW53YWxkLCBEci4gSmFuLU9saXZlciBXYWduZXINCj4gDQo= From mdavidson@mitre.org Wed Sep 26 04:56:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6421F880D for ; Wed, 26 Sep 2012 04:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-1.398, 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 51QUJOG0s7jM for ; Wed, 26 Sep 2012 04:56:44 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB87121F87FB for ; Wed, 26 Sep 2012 04:56:44 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1DEE149F0086 for ; Wed, 26 Sep 2012 07:56:44 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtptsrv1.mitre.org (Postfix) with ESMTP id F1D0F49F00A2 for ; Wed, 26 Sep 2012 07:56:43 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.34]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 07:56:43 -0400 From: "Davidson II, Mark S" To: "sacm@ietf.org" Thread-Topic: New Version Notification for draft-davidson-sacm-asr-00.txt Thread-Index: AQHNm90AhbTPehxCUkKQxLFxGSpmYZecgmLA Date: Wed, 26 Sep 2012 11:56:42 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BD22A44@IMCMBX02.MITRE.ORG> References: <20120926114934.26885.90831.idtracker@ietfa.amsl.com> In-Reply-To: <20120926114934.26885.90831.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: New Version Notification for draft-davidson-sacm-asr-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:56:45 -0000 QWxsLA0KDQpJIGhhdmUgcG9zdGVkIGEgZHJhZnQgb2YgdGhlIEFTUiBJLUQuDQoNClRoZXJlIGFy ZSBzb21lIFRPRE8gbGFiZWxzIGluIHRoZSBkb2N1bWVudCBmb3IgYXJlYXMgdGhhdCwgcGVuZGlu ZyBncm91cCBmZWVkYmFjaywgSSB3aWxsIGNvbXBsZXRlLiANCg0KT25lIHN1Y2ggJ1RPRE8nIGFy ZWEgaXMgdGhlIHNldCBvZiB0YWJsZXMgZm9yIHRoZSBBU1IgZGF0YSBtb2RlbHMuIFRoZSB0YWJs ZXMgbG9vayBnb29kIGluIHRoZSBOSVNUIElSLCBidXQgY29tZSBhY3Jvc3MgbGVzcyBnb29kIGlu IGEgdGV4dCBkb2N1bWVudCBvZiBmaXhlZCB3aWR0aC4gSSAocGFpbnN0YWtpbmdseSwgSSBtaWdo dCBhZGQpIGNyZWF0ZWQgYSBzaW5nbGUgdGFibGUgc28gdGhhdCB0aGUgZ3JvdXAgY291bGQgZ2V0 IGEgc2Vuc2Ugb2Ygd2hhdCBhbGwgdGFibGVzIHdvdWxkIGxvb2sgbGlrZS4gSWYgdGhlIHRhYmxl cyBhcmUgYWNjZXB0YWJsZSwgSSB3aWxsIGRvIGFsbCB0YWJsZXMgaW4gdGhhdCBtYW5uZXIuIE90 aGVyd2lzZSwgSSB3aWxsIG1vZGlmeSB0aGUgYXBwcm9hY2ggcGVuZGluZyBmZWVkYmFjay4NCg0K VGhhbmsgeW91Lg0KLU1hcmsgRGF2aWRzb24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxMiA3OjUwIEFNDQpU bzogRGF2aWRzb24gSUksIE1hcmsgUw0KQ2M6IGRhdmlkLm9saXZhQHZlcml6b24ubmV0DQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRhdmlkc29uLXNhY20tYXNy LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kYXZpZHNvbi1zYWNtLWFz ci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyayBEYXZpZHNv biBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LWRhdmlkc29uLXNhY20tYXNyDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBBc3NldCBTdW1tYXJ5 IFJlcG9ydGluZw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDktMjQNCldHIElEOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAzMA0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kYXZpZHNvbi1zYWNtLWFzci0w MC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1kYXZpZHNvbi1zYWNtLWFzcg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1kYXZpZHNvbi1zYWNtLWFzci0wMA0KDQoNCkFic3RyYWN0Og0KICAg VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIEFzc2V0IFN1bW1hcnkgUmVwb3J0aW5nIChB U1IpLCBhIGRhdGENCiAgIG1vZGVsIGZvciBleHByZXNzaW5nIHRoZSBkYXRhIGV4Y2hhbmdlIGZv cm1hdCBvZiBzdW1tYXJ5IGluZm9ybWF0aW9uDQogICByZWxhdGl2ZSB0byBvbmUgb3IgbW9yZSBt ZXRyaWNzLiBBU1IgcmVkdWNlcyB0aGUgYmFuZHdpZHRoDQogICByZXF1aXJlbWVudCB0byByZXBv cnQgaW5mb3JtYXRpb24gYWJvdXQgYXNzZXRzIGluIHRoZSBhZ2dyZWdhdGUgc2luY2UNCiAgIGl0 IGFsbG93cyBmb3IgcmVwb3J0aW5nIGFnZ3JlZ2F0ZXMgcmVsYXRpdmUgdG8gbWV0cmljcywgYXMg b3Bwb3NlZCB0bw0KICAgcmVwb3J0aW5nIGRhdGEgYWJvdXQgZWFjaCBpbmRpdmlkdWFsIGFzc2V0 LCB3aGljaCBjYW4gbGVhZCB0byBhDQogICBibG9hdGVkIGRhdGEgZXhjaGFuZ2UuIEFTUiBpcyB2 ZW5kb3IgbmV1dHJhbCBhbmQgbGV2ZXJhZ2VzIHdpZGVseQ0KICAgYWRvcHRlZCwgb3BlbiBzcGVj aWZpY2F0aW9uczsgaXQgaXMgZmxleGlibGUsIGFuZCBzdWl0ZWQgZm9yIGEgd2lkZQ0KICAgdmFy aWV0eSBvZiByZXBvcnRpbmcgYXBwbGljYXRpb25zLg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From amontville@tripwire.com Wed Sep 26 05:15:19 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBF721F885E for ; Wed, 26 Sep 2012 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EpUyCcwAoQVX for ; Wed, 26 Sep 2012 05:15:19 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id B136A21F885C for ; Wed, 26 Sep 2012 05:15:18 -0700 (PDT) Received: from mail136-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 12:15:17 +0000 Received: from mail136-va3 (localhost [127.0.0.1]) by mail136-va3-R.bigfish.com (Postfix) with ESMTP id 288ED4A018D for ; Wed, 26 Sep 2012 12:15:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz98dI9371I936eI542M1432I4015Id6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3 (MessageSwitch) id 1348661714885619_481; Wed, 26 Sep 2012 12:15:14 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.235]) by mail136-va3.bigfish.com (Postfix) with ESMTP id C1D943A0057 for ; Wed, 26 Sep 2012 12:15:14 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 12:15:12 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 5CDEC2321249 for ; Wed, 26 Sep 2012 05:10:04 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id B9CEE2321222; Wed, 26 Sep 2012 05:10:03 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 26 Sep 2012 05:18:19 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 05:15:10 -0700 From: Adam Montville To: "Davidson II, Mark S" Thread-Topic: [sacm] FW: New Version Notification for draft-davidson-sacm-asr-00.txt Thread-Index: AQHNm90AhbTPehxCUkKQxLFxGSpmYZecgmLAgAAHCbg= Date: Wed, 26 Sep 2012 12:15:09 +0000 Message-ID: <3E5B1491-1AC2-4AF2-8322-EC1FD8702462@tripwire.com> References: <20120926114934.26885.90831.idtracker@ietfa.amsl.com>, <69F1FC52EB080B4983863BD1602520D80BD22A44@IMCMBX02.MITRE.ORG> In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD22A44@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: aeac08d9-22f7-4618-95ae-d500cae7ff91 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-davidson-sacm-asr-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:15:19 -0000 Thanks, Mark! Regards, Adam On Sep 26, 2012, at 4:56 AM, "Davidson II, Mark S" wr= ote: > All, >=20 > I have posted a draft of the ASR I-D. >=20 > There are some TODO labels in the document for areas that, pending group = feedback, I will complete.=20 >=20 > One such 'TODO' area is the set of tables for the ASR data models. The ta= bles look good in the NIST IR, but come across less good in a text document= of fixed width. I (painstakingly, I might add) created a single table so t= hat the group could get a sense of what all tables would look like. If the = tables are acceptable, I will do all tables in that manner. Otherwise, I wi= ll modify the approach pending feedback. >=20 > Thank you. > -Mark Davidson >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 26, 2012 7:50 AM > To: Davidson II, Mark S > Cc: david.oliva@verizon.net > Subject: New Version Notification for draft-davidson-sacm-asr-00.txt >=20 >=20 > A new version of I-D, draft-davidson-sacm-asr-00.txt > has been successfully submitted by Mark Davidson and posted to the > IETF repository. >=20 > Filename: draft-davidson-sacm-asr > Revision: 00 > Title: Asset Summary Reporting > Creation date: 2012-09-24 > WG ID: Individual Submission > Number of pages: 30 > URL: http://www.ietf.org/internet-drafts/draft-davidson-sacm-= asr-00.txt > Status: http://datatracker.ietf.org/doc/draft-davidson-sacm-asr > Htmlized: http://tools.ietf.org/html/draft-davidson-sacm-asr-00 >=20 >=20 > Abstract: > This specification defines the Asset Summary Reporting (ASR), a data > model for expressing the data exchange format of summary information > relative to one or more metrics. ASR reduces the bandwidth > requirement to report information about assets in the aggregate since > it allows for reporting aggregates relative to metrics, as opposed to > reporting data about each individual asset, which can lead to a > bloated data exchange. ASR is vendor neutral and leverages widely > adopted, open specifications; it is flexible, and suited for a wide > variety of reporting applications. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From adam@stoicsecurity.com Wed Sep 26 05:16:56 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1360E21F8860 for ; Wed, 26 Sep 2012 05:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 eL2cxGRr1rfz for ; Wed, 26 Sep 2012 05:16:55 -0700 (PDT) Received: from m1plsmtpa01-05.prod.mesa1.secureserver.net (m1plsmtpa01-05.prod.mesa1.secureserver.net [64.202.165.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3589021F885E for ; Wed, 26 Sep 2012 05:16:55 -0700 (PDT) Received: from [192.168.1.12] ([50.137.24.91]) by m1plsmtpa01-05.prod.mesa1.secureserver.net with id 3oGs1k00C1xvdQ201oGtym; Wed, 26 Sep 2012 05:16:53 -0700 References: <6C1C15D8B5510B4B8FF132B10D3865130227FCAA@IMCMBX03.MITRE.ORG> <6C1C15D8B5510B4B8FF132B10D3865130227FE36@IMCMBX03.MITRE.ORG> <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: "Adam W. Montville" Date: Wed, 26 Sep 2012 05:16:55 -0700 To: "Moriarty, Kathleen" Cc: Adam Montville , Jan-Oliver Wagner , "Waltermire, David A." , "Baker, Jon" , "sacm@ietf.org" Subject: Re: [sacm] SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:16:56 -0000 On Sep 26, 2012, at 4:53 AM, "Moriarty, Kathleen" wrote: > Please DO jump into any of the IETF lists where you want to voice an opini= on or support! Thank you! +1 >=20 > We are working to develop the charter for this list to become a working gr= oup and it is important to reach rough consensus from the participants who w= ill drive and use the results. >=20 > Is there more support for both or other opinions? >=20 > Thanks, > Kathleen >=20 > Sent from my iPhone >=20 > On Sep 26, 2012, at 6:29 AM, "Jan-Oliver Wagner" wrote: >=20 >> On Mittwoch, 26. September 2012, Baker, Jon wrote: >>> I am a big fan of SWIDs and believe that we would really benefit from wi= despread SWID adoption. In my previous message, I was attempting to state th= at we need capabilities offer by both CPE and SWID. >>=20 >> I am a big fan of CPE and believe it is fully compatible with Open Source= reference >> implementation and widespread use/adoption in Open Source tools, especial= ly also >> in commercial environments. >>=20 >> Neglecting CPE in favour of SWID would IMHO be a drawback for widespread s= ecurity >> automation because, as to my understanding, SWID is not fully compatible w= ith the vendor-independent >> approaches. Convince me I am wrong and I'd be happy ;-) >>=20 >>=20 >> (Sorry for jumping in here, it was just something I am worried about sinc= e some time already >> so I spontaneously reacted on the keywords :-) >>=20 >>=20 >> --=20 >> Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ >> Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=C3=BCck | AG Osnab= r=C3=BCck, HR B 202460 >> Gesch=C3=A4ftsf=C3=BChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Sep 26 06:23:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF821F8489 for ; Wed, 26 Sep 2012 06:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.773 X-Spam-Level: X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, 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 u9-FIFsHAQYI for ; Wed, 26 Sep 2012 06:23:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 097D121F844F for ; Wed, 26 Sep 2012 06:23:23 -0700 (PDT) Received: from mail141-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 13:23:23 +0000 Received: from mail141-tx2 (localhost [127.0.0.1]) by mail141-tx2-R.bigfish.com (Postfix) with ESMTP id 222222E011F for ; Wed, 26 Sep 2012 13:23:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bhc85ehfafJd6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah30d1K8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ahbe3k1155h) Received: from mail141-tx2 (localhost.localdomain [127.0.0.1]) by mail141-tx2 (MessageSwitch) id 1348665801115283_22806; Wed, 26 Sep 2012 13:23:21 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.235]) by mail141-tx2.bigfish.com (Postfix) with ESMTP id 14F4F400073 for ; Wed, 26 Sep 2012 13:23:21 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 13:23:18 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 69FD9232124B for ; Wed, 26 Sep 2012 06:18:10 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id A09162321249; Wed, 26 Sep 2012 06:18:09 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 26 Sep 2012 06:26:25 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 06:23:16 -0700 From: Adam Montville To: Jan-Oliver Wagner , "sacm@ietf.org" Thread-Topic: SWID and CPE: WAS - Re: [sacm] SACM BoF Request Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4ATkiD4AALKfEgAHsIJlAAA4gjAAAM+nnAABAS/gD//7twgA== Date: Wed, 26 Sep 2012 13:23:15 +0000 Message-ID: In-Reply-To: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> 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: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC8845A3117D4amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 98163fee-c8a2-4d34-bd87-6c738c58deca X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "Moriarty, Kathleen" , "Waltermire, David A." , "Baker, Jon" Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:23:25 -0000 --_000_CC8845A3117D4amontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions =96 that w= ould be the domain of Asset Identification (we could use CPE or SWID to spe= cify classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road =96 when an operational compo= nent is implicitly or explicitly required for a standard to work as intende= d at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_CC8845A3117D4amontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9BE18A19BF78B24FBE5DD10C0C7F418D@tripwire.com> Content-Transfer-Encoding: quoted-printable
This seems like an important discussion.  Asset management is, ar= guably, the most important foundational piece of an effective information s= ecurity program, as our use case document [1] recognizes (asset management = is the first recognized capability in support of Use Case 1).  Clearly, there are pros and cons to leveragi= ng CPE and/or SWID, and after quickly reading through some of the informati= on available at TagVault [2], it seems clear that SWIDs are roughly equival= ent to CPE for operating systems and applications.

Before looking at the differences between CPE and SWID, it's probably = a good idea to understand exactly what we need from a software asset classi= fication scheme not only within our use cases, but also from a couple of co= ntrol frameworks our use cases support (I prefer to look at the Critical Audit Guidelines (CAG) published by SANS= and ISO 27002).

Both the CAG and 27002 make reference to managing assets, but only in = terms of keeping an inventory.  The CAG goes further by explicitly sta= ting (in Critical Control 2) that we need to have an inventory of all autho= rized and unauthorized software.  I don't believe either really mentions anything about corrective actions, except i= mplicitly in sections related to incident response.  

So, we have a clear need to look at an instance of software, classify = it, and build or contribute to an identity profile for it for continued ref= erence.  Can CPE handle this classification for for us?  Yes. &nb= sp;Can SWID handle this classification for us?  It seems so.  Note that we should not rely on either of these m= ethods to identify software for targeted actions =96 that would be the doma= in of Asset Identification (we could use CPE or SWID to specify classes of = targets for actions).

Distribution and operational identification seems important to conside= r as well.  CPEs aren't installed with the software and require some a= ssessment action to derive.  SWIDs, on the other hand, appear to be di= stributed by the software publisher [3].  Moreover, SWIDs are certified and signed by TagVault.  I'm unsure of the detail= s about how SWIDs become available on a given system (they still need to be= actively collected from a target system at some point).

At this point, the difference between the two is really volume of avai= lable "tags" (we can reasonably call a CPE name a "tag"= in this context), and this is where I see the rubber meeting the road =96 = when an operational component is implicitly or explicitly required for a standard to work as intended at scale.  

There seems to be very little information about SWID volumes available= (at least in the limited time I've had to search around), so it's difficul= t to judge how well they've penetrated the market.  The last press rel= ease from TagVault is from 2010, which may suggest a dropping off of the effort or a satisfaction that they've do= ne enough.  Information about CPE volume seems most readily available = from NVD [5].

Can anyone on this list provide additional details about SWID?

I think it may be useful, from a  community perspective, to be ab= le to handle both software identification types, provided both are operatio= nally feasible and foreseeably sustainable.  For example, the ai:software element defined by the Asset Identification draft [4] ha= s an optional CPE attribute that could just as easily be complemented by an= optional SWID attribute.


[1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 =
[2] http://www.tagvault.org



On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbone.net> = wrote:

On Mittwoch, 26. September 2012, Baker, Jon wrote:
I am a big fan of SWIDs and believe that we would really benefit from = widespread SWID adoption. In my previous message, I was attempting to state= that we need capabilities offer by both CPE and SWID.

I am a big fan of CPE and believe it is fully compatible with Open Sou= rce reference
implementation and widespread use/adoption in Open Source tools, espec= ially also
in commercial environments.

Neglecting CPE in favour of SWID would IMHO be a drawback for widespre= ad security
automation because, as to my understanding, SWID is not fully compatib= le with the vendor-independent
approaches. Convince me I am wrong and I'd be happy ;-)


(Sorry for jumping in here, it was just something I am worried about s= ince some time already
so I spontaneously reacted on the keywords :-)


--
Dr. Jan-Oliver Wagner |  ++49-541-335084-0 &nbs= p;|  http://www.greenbone.n= et/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnab= r=FCck, HR B 202460
Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner




--_000_CC8845A3117D4amontvilletripwirecom_-- From amontville@tripwire.com Wed Sep 26 06:38:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA8B21F848B for ; Wed, 26 Sep 2012 06:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1OWpvSDwynKs for ; Wed, 26 Sep 2012 06:38:39 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 577C921F8469 for ; Wed, 26 Sep 2012 06:38:39 -0700 (PDT) Received: from mail8-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 13:38:38 +0000 Received: from mail8-va3 (localhost [127.0.0.1]) by mail8-va3-R.bigfish.com (Postfix) with ESMTP id A6B4526013F for ; Wed, 26 Sep 2012 13:38:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI98dI9371Ic89bhc85ehfafJ4015I328cMd6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah30d1K8275bh8275dh186M172c6chz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ahbe3k1155h) Received: from mail8-va3 (localhost.localdomain [127.0.0.1]) by mail8-va3 (MessageSwitch) id 1348666715307800_20422; Wed, 26 Sep 2012 13:38:35 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.236]) by mail8-va3.bigfish.com (Postfix) with ESMTP id 39BF3140058 for ; Wed, 26 Sep 2012 13:38:35 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 13:38:31 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id B5E31232124E for ; Wed, 26 Sep 2012 06:33:22 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 57EBC23211F8; Wed, 26 Sep 2012 06:33:21 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 26 Sep 2012 06:41:36 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 06:38:27 -0700 From: Adam Montville To: "Struse, Richard" , Jan-Oliver Wagner , "sacm@ietf.org" Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+tdyopvuPzxfkW1umHuq2WmRJecoI0A Date: Wed, 26 Sep 2012 13:38:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC88524F1183Aamontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 3cad4a36-6097-4fc2-a7f3-d9f628aeaa27 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "Moriarty, Kathleen" , "Waltermire, David A." , "Baker, Jon" Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:38:42 -0000 --_000_CC88524F1183Aamontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, Rich! I have some additional comments/questions inline. From: , Richard > Date: Wednesday, September 26, 2012 6:32 AM To: Adam Montville = >, Jan-Oliver Wagner >, "sacm@ietf.org" > Cc: "kathleen.moriarty@emc.com" >, "Waltermire, David A.= " >, Jon Baker = > Subject: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request I think Jon Baker has already said some of this but I wanted to highlight t= he following: 1. SWID=92s and CPE=92s have some overlap but are largely complementa= ry specifications 2. The SWID standard specifies tags that would allow automated verifi= cation of package integrity (through manifests of file hashes), an importan= t capability that CPE does not provide >From this perspective, our assessment capabilities would want to assess SWI= Ds when a test is created to ensure that installed software is valid (or so= me language like that). 3. SWID=92s have been carefully designed to accommodate suites (e.g. = Office), patches and other complicating factors Is the implication that CPE has not been proven to handle these things? 4. The CPE language can represent patterns that map to multiple assets= , SWID=92s are a one-to-one sort of thing OK. I guess I was looking at this differently, as the SWID is certified an= d signed before installation. In that way, a SWID for Microsoft's latest r= elease of Windows 8 could reasonably serve as a classification mechanism co= uld it not? (Again, I'm not into the actual SWID standard yet =96 just wha= t's available publicly). 5. Microsoft announced their support for SWID tags earlier this year = (http://www.microsoft.com/sam/en/us/softwareid.aspx) Good to know. Jon also mentioned efforts to harmonize CPE and SWID =96it would be interes= ting to learn more about those efforts also. Hope this helps=85 Rich From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions =96 that w= ould be the domain of Asset Identification (we could use CPE or SWID to spe= cify classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road =96 when an operational compo= nent is implicitly or explicitly required for a standard to work as intende= d at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_CC88524F1183Aamontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <382C5706A6421F4695AA900549B869C4@tripwire.com> Content-Transfer-Encoding: quoted-printable
Thanks, Rich!  I have some additional comments/questions inline.<= /div>

From: <Struse>, Richard <<= a href=3D"mailto:Richard.Struse@HQ.DHS.GOV">Richard.Struse@HQ.DHS.GOV&g= t;
Date: Wednesday, September 26, 2012= 6:32 AM
To: Adam Montville <amontville@tripwire.com>, Jan-Oliver = Wagner <Jan-Oliver.Wa= gner@greenbone.net>, "sacm@iet= f.org" <sacm@ietf.org>
Cc: "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>, "Walt= ermire, David A." <dav= id.waltermire@nist.gov>, Jon Baker <bakerj@MITRE.ORG>=
Subject: RE: [sacm] SWID and CPE: W= AS - Re: SACM BoF Request

I think Jon Baker has already said= some of this but I wanted to highlight the following:

1.       SWID=92s and CPE=92s h= ave some overlap but are largely complementary specifications

2.       The SWID standard spec= ifies tags that would allow automated verification of package integrity (th= rough manifests of file hashes), an important capability that CPE does not provide

From this perspective, our assessment capabilities would want to asses= s SWIDs when a test is created to ensure that installed software is valid (= or some language like that).

3.       SWID=92s have been car= efully designed to accommodate suites (e.g. Office), patches and other comp= licating factors

Is the implication that CPE has not been proven to handle these things= ?

4.      The CPE language can represent patterns that map to multiple assets, SWID=92s = are a one-to-one sort of thing

OK.  I guess I was looking at this differently, as the SWID is ce= rtified and signed before installation.  In that way, a SWID for Micro= soft's latest release of Windows 8 could reasonably serve as a classificati= on mechanism could it not?  (Again, I'm not into the actual SWID standard yet =96 just what's available publicly).

5.       Microsoft announced th= eir support for SWID tags earlier this year (http://www.microsoft.com/sam/en/us/softwar= eid.aspx)

Good to know.

Jon also mentioned efforts to harmonize CPE and SWID =96it would be in= teresting to learn more about those efforts also.

 

Hope this helps=85

 

Rich

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.or= g
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request<= /span>

 

This seems like an important discussion. &n= bsp;Asset management is, arguably, the most important foundational piece of= an effective information security program, as our use case document [1] recognizes (asset management is the first rec= ognized capability in support of Use Case 1).  Clearly, there are pros= and cons to leveraging CPE and/or SWID, and after quickly reading through = some of the information available at TagVault [2], it seems clear that SWIDs are roughly equivalent to CPE for = operating systems and applications.

 

Before looking at the differences between C= PE and SWID, it's probably a good idea to understand exactly what we need f= rom a software asset classification scheme not only within our use cases, but also from a couple of control fr= ameworks our use cases support (I prefer to look at the Critical Audit Guid= elines (CAG) published by SANS and ISO 27002).

 

Both the CAG and 27002 make reference to ma= naging assets, but only in terms of keeping an inventory.  The CAG goe= s further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized and unautho= rized software.  I don't believe either really mentions anything about= corrective actions, except implicitly in sections related to incident resp= onse.  

 

So, we have a clear need to look at an inst= ance of software, classify it, and build or contribute to an identity profi= le for it for continued reference.  Can CPE handle this classification for for us?  Yes.  Can SWID handl= e this classification for us?  It seems so.  Note that we should = not rely on either of these methods to identify software for targeted actio= ns =96 that would be the domain of Asset Identification (we could use CPE or SWID to specify classes of targets for actions).=

 

Distribution and operational identification= seems important to consider as well.  CPEs aren't installed with the = software and require some assessment action to derive.  SWIDs, on the other hand, appear to be distributed by the= software publisher [3].  Moreover, SWIDs are certified and signed by = TagVault.  I'm unsure of the details about how SWIDs become available = on a given system (they still need to be actively collected from a target system at some point).

 

At this point, the difference between the t= wo is really volume of available "tags" (we can reasonably call a= CPE name a "tag" in this context), and this is where I see the rubber meeting the road =96 when an operational component = is implicitly or explicitly required for a standard to work as intended at = scale.  

 

There seems to be very little information a= bout SWID volumes available (at least in the limited time I've had to searc= h around), so it's difficult to judge how well they've penetrated the market.  The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough.  Information about CPE volume s= eems most readily available from NVD [5].

 

Can anyone on this list provide additional = details about SWID?

 

I think it may be useful, from a  comm= unity perspective, to be able to handle both software identification types,= provided both are operationally feasible and foreseeably sustainable.  For example, the ai:software ele= ment defined by the Asset Identification draft [4] has an optional CPE attr= ibute that could just as easily be complemented by an optional SWID attribu= te.

 

 

 

 

 

On 9/26/12 3:28 AM, "Jan-Oliver Wagner= " <Jan-Oliver.Wa= gner@greenbone.net> wrote:

 

On Mittwoch, 26. September 2012, Baker, Jon= wrote:

I am a big fan of SWIDs and believe that we= would really benefit from widespread SWID adoption. In my previous message= , I was attempting to state that we need capabilities offer by both CPE and SWID.

 

I am a big fan of CPE and believe it is ful= ly compatible with Open Source reference

implementation and widespread use/adoption = in Open Source tools, especially also

in commercial environments.

 

Neglecting CPE in favour of SWID would IMHO= be a drawback for widespread security

automation because, as to my understanding,= SWID is not fully compatible with the vendor-independent=

approaches. Convince me I am wrong and I'd = be happy ;-)

 

 

(Sorry for jumping in here, it was just som= ething I am worried about since some time already

so I spontaneously reacted on the keywords = :-)

 

 

--

Dr. Jan-Oliver Wagner |  += 3;49-541-335084-0  |  http://www.greenbone.net/

Greenbone Networks GmbH, Neuer Graben 17, 4= 9074 Osnabr=FCck | AG Osnabr=FCck, HR B 202460

Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Ja= n-Oliver Wagner

 

 

 

 


--_000_CC88524F1183Aamontvilletripwirecom_-- From kathleen.moriarty@emc.com Wed Sep 26 06:45:56 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882121F8792 for ; Wed, 26 Sep 2012 06:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=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 394T+5DbbiTl for ; Wed, 26 Sep 2012 06:45:52 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C505521F8871 for ; Wed, 26 Sep 2012 06:45:51 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8QDirwA008252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 09:44:54 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 26 Sep 2012 09:44:42 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8QDieAn017240; Wed, 26 Sep 2012 09:44:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Wed, 26 Sep 2012 09:44:39 -0400 From: "Moriarty, Kathleen" To: Adam Montville , "Struse, Richard" , Jan-Oliver Wagner , "sacm@ietf.org" Date: Wed, 26 Sep 2012 09:44:38 -0400 Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+tdyopvuPzxfkW1umHuq2WmRJecoI0AgAABIEA= 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_F5063677821E3B4F81ACFB7905573F2409420CC8MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Waltermire, David A." , "Baker, Jon" Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:45:56 -0000 --_000_F5063677821E3B4F81ACFB7905573F2409420CC8MX15Acorpemccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you to all for the additional information! As Adam pointed out earlier, how do we fulfill the use cases? What is need= ed in a high-level charter description without naming a way to accomplish i= t. Then how do either CPE and/or SWID fit into that need? Thank you! Kathleen From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, September 26, 2012 9:38 AM To: Struse, Richard; Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thanks, Rich! I have some additional comments/questions inline. From: , Richard > Date: Wednesday, September 26, 2012 6:32 AM To: Adam Montville = >, Jan-Oliver Wagner >, "sacm@ietf.org" > Cc: "kathleen.moriarty@emc.com" >, "Waltermire, David A.= " >, Jon Baker = > Subject: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request I think Jon Baker has already said some of this but I wanted to highlight t= he following: 1. SWID's and CPE's have some overlap but are largely complementary sp= ecifications 2. The SWID standard specifies tags that would allow automated verific= ation of package integrity (through manifests of file hashes), an important= capability that CPE does not provide >From this perspective, our assessment capabilities would want to assess SWI= Ds when a test is created to ensure that installed software is valid (or so= me language like that). 3. SWID's have been carefully designed to accommodate suites (e.g. Off= ice), patches and other complicating factors Is the implication that CPE has not been proven to handle these things? 4. The CPE language can represent patterns that map to multiple assets= , SWID's are a one-to-one sort of thing OK. I guess I was looking at this differently, as the SWID is certified an= d signed before installation. In that way, a SWID for Microsoft's latest r= elease of Windows 8 could reasonably serve as a classification mechanism co= uld it not? (Again, I'm not into the actual SWID standard yet - just what'= s available publicly). 5. Microsoft announced their support for SWID tags earlier this year (= http://www.microsoft.com/sam/en/us/softwareid.aspx) Good to know. Jon also mentioned efforts to harmonize CPE and SWID -it would be interesti= ng to learn more about those efforts also. Hope this helps... Rich From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions - that wou= ld be the domain of Asset Identification (we could use CPE or SWID to speci= fy classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road - when an operational compone= nt is implicitly or explicitly required for a standard to work as intended = at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_F5063677821E3B4F81ACFB7905573F2409420CC8MX15Acorpemccom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you to all for the additional information!

 

As Adam pointed out earlier, how do we fulfill the use cases= ?=A0 What is needed in a high-level charter description without naming a wa= y to accomplish it.=A0 Then how do either CPE and/or SWID fit into that nee= d?

 

Thank you!
Kathleen

 

<= p class=3DMsoNormal>From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, September 26, 2012 9:38 AM
To: Struse, R= ichard; Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; = Waltermire, David A.; Baker, Jon
Subject: Re: [sacm] SWID and CPE= : WAS - Re: SACM BoF Request

 

Thanks, Rich! &= nbsp;I have some additional comments/questions inline.

 

From: <Struse>, Ri= chard <Richard.Struse@HQ.DH= S.GOV>
Date: Wednesday, September 26, 2012 6:32 AM
T= o: Adam Montville <amontv= ille@tripwire.com>, Jan-Oliver Wagner <Jan-Oliver.Wagner@greenbone.net>, "sacm@ietf.org" <sacm@ietf.org>
Cc: "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>, &q= uot;Waltermire, David A." <david.waltermire@nist.gov>, Jon Baker <bakerj@MITRE.ORG>
Subject: RE: [sacm] SWID = and CPE: WAS - Re: SACM BoF Request

 

I think Jon Baker has already said some= of this but I wanted to highlight the following:

1.      SWID’s and CPE’s have some overlap = but are largely complementary specifications

2.      The SWID standard specifies tags that would allow aut= omated verification of package integrity (through manifests of file hashes)= , an important capability that CPE does not provide

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>From this perspective, our assessment capabilities would want to assess= SWIDs when a test is created to ensure that installed software is valid (o= r some language like that).

 

=

3.SWID= ’s have been carefully designed to accommodate suites (e.g. Office), = patches and other complicating factors

 

Is the im= plication that CPE has not been proven to handle these things?

 

<= /div>

4.      = The CPE language can represent patterns that= map to multiple assets, SWID’s are a one-to-one sort of thing=

=

 

OK.  I guess I was looking at this differently, a= s the SWID is certified and signed before installation.  In that way, = a SWID for Microsoft's latest release of Windows 8 could reasonably serve a= s a classification mechanism could it not?  (Again, I'm not into the a= ctual SWID standard yet – just what's available publicly).=

 

5.      Microsoft announced their support for SWID= tags earlier this year (http://www.microsoft.com/sam/en/us/softwareid.aspx)=

=

 

Good to know.

 

Jon also mentioned efforts to harmonize CPE and SWID –it woul= d be interesting to learn more about those efforts also.<= /p>

 

<= blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in= 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRI= BUTION_BLOCKQUOTE">

 

Ho= pe this helps…

 

Rich

F= rom: sacm-bounces@i= etf.org [mailto:sacm-bounces@i= etf.org] On Behalf Of Adam Montville
Sent: Wednesday, = September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Walte= rmire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - R= e: SACM BoF Request

 

This seems like an important = discussion.  Asset management is, arguably, the most important foundat= ional piece of an effective information security program, as our use case d= ocument [1] recognizes (asset management is the first recognized capability= in support of Use Case 1).  Clearly, there are pros and cons to lever= aging CPE and/or SWID, and after quickly reading through some of the inform= ation available at TagVault [2], it seems clear that SWIDs are roughly equi= valent to CPE for operating systems and applications.

&nb= sp;

Before looking at the differences between CPE and SWI= D, it's probably a good idea to understand exactly what we need from a soft= ware asset classification scheme not only within our use cases, but also fr= om a couple of control frameworks our use cases support (I prefer to look a= t the Critical Audit Guidelines (CAG) published by SANS and ISO 27002).

 <= /p>

Both the CAG and 27002 make referen= ce to managing assets, but only in terms of keeping an inventory.  The= CAG goes further by explicitly stating (in Critical Control 2) that we nee= d to have an inventory of all authorized and unauthorized software.  I= don't believe either really mentions anything about corrective actions, ex= cept implicitly in sections related to incident response.  

 

So, we have a clear need to look at an ins= tance of software, classify it, and build or contribute to an identity prof= ile for it for continued reference.  Can CPE handle this classificatio= n for for us?  Yes.  Can SWID handle this classification for us? =  It seems so.  Note that we should not rely on either of these me= thods to identify software for targeted actions – that would be the d= omain of Asset Identification (we could use CPE or SWID to specify classes = of targets for actions).

 

Distri= bution and operational identification seems important to consider as well. =  CPEs aren't installed with the software and require some assessment a= ction to derive.  SWIDs, on the other hand, appear to be distributed b= y the software publisher [3].  Moreover, SWIDs are certified and signe= d by TagVault.  I'm unsure of the details about how SWIDs become avail= able on a given system (they still need to be actively collected from a tar= get system at some point).

 

At th= is point, the difference between the two is really volume of available &quo= t;tags" (we can reasonably call a CPE name a "tag" in this c= ontext), and this is where I see the rubber meeting the road – when a= n operational component is implicitly or explicitly required for a standard= to work as intended at scale.  

 

There seems to be very little information about SWID volumes availabl= e (at least in the limited time I've had to search around), so it's difficu= lt to judge how well they've penetrated the market.  The last press re= lease from TagVault is from 2010, which may suggest a dropping off of the e= ffort or a satisfaction that they've done enough.  Information about C= PE volume seems most readily available from NVD [5].

&nbs= p;

Can anyone on this list provide additional details abo= ut SWID?

 

I think it may be usefu= l, from a  community perspective, to be able to handle both software i= dentification types, provided both are operationally feasible and foreseeab= ly sustainable.  For example, the ai:software element defined b= y the Asset Identification draft [4] has an optional CPE attribute that cou= ld just as easily be complemented by an optional SWID attribute.

 

 <= o:p>

[2] <= a href=3D"http://www.tagvault.org">http://www.tagvault.org

 =

 

=

 

On 9/26/12 3:= 28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbone.net> wrote:

 

On Mittwoch, 26. September 2012, Baker, Jon wrote:

I am a big= fan of SWIDs and believe that we would really benefit from widespread SWID= adoption. In my previous message, I was attempting to state that we need c= apabilities offer by both CPE and SWID. =

&nb= sp;

I am a big fan of CPE and believe it is fully compati= ble with Open Source reference

implementation and widespr= ead use/adoption in Open Source tools, especially also

in= commercial environments.

 

Neglec= ting CPE in favour of SWID would IMHO be a drawback for widespread security=

automation because, as to my understanding, SWID is not = fully compatible with the vendor-independent

approaches. = Convince me I am wrong and I'd be happy ;-)

 =

 

=

(Sorry for jumping in here, it was jus= t something I am worried about since some time already

so= I spontaneously reacted on the keywords :-)

 

 

--

Dr. Jan-Oliver = Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/

Gr= eenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck,= HR B 202460

=

Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan= -Oliver Wagner

 <= o:p>

 

 

 

 

 

= --_000_F5063677821E3B4F81ACFB7905573F2409420CC8MX15Acorpemccom_-- From amontville@tripwire.com Wed Sep 26 06:54:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF221F8699 for ; Wed, 26 Sep 2012 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1] 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 UlnxQT+F0MN7 for ; Wed, 26 Sep 2012 06:54:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A821F8681 for ; Wed, 26 Sep 2012 06:54:04 -0700 (PDT) Received: from mail257-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 13:54:03 +0000 Received: from mail257-ch1 (localhost [127.0.0.1]) by mail257-ch1-R.bigfish.com (Postfix) with ESMTP id 7019A88010B for ; Wed, 26 Sep 2012 13:54:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI98dI9371Ic89bhc85ehfafJ4015I328cMd6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah30d1K8275bh8275dh186M172c6chz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ahbe3k1155h) Received: from mail257-ch1 (localhost.localdomain [127.0.0.1]) by mail257-ch1 (MessageSwitch) id 1348667640118338_23466; Wed, 26 Sep 2012 13:54:00 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail257-ch1.bigfish.com (Postfix) with ESMTP id 196851500019 for ; Wed, 26 Sep 2012 13:54:00 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 13:53:58 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 5DADF232124C for ; Wed, 26 Sep 2012 06:48:50 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 287A023211F8; Wed, 26 Sep 2012 06:48:49 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 26 Sep 2012 06:57:04 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 06:53:55 -0700 From: Adam Montville To: "Moriarty, Kathleen" Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+tdyopvuPzxfkW1umHuq2WmRJecoI0AgAABIECAAAM4SA== Date: Wed, 26 Sep 2012 13:53:54 +0000 Message-ID: <7DE387DB-FAD1-4A84-AA20-5533A1002AB3@tripwire.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_7DE387DBFAD14A84AA205533A1002AB3tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 1a5a0b2b-8ec9-4092-ae87-e4b1c761b97b X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "Baker, Jon" , Jan-Oliver Wagner , "sacm@ietf.org" , "Struse, Richard" , "Waltermire, David A." Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:54:09 -0000 --_000_7DE387DBFAD14A84AA205533A1002AB3tripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Sep 26, 2012, at 6:46 AM, "Moriarty, Kathleen" > wrote: Thank you to all for the additional information! As Adam pointed out earlier, how do we fulfill the use cases? What is need= ed in a high-level charter description without naming a way to accomplish i= t. I'm reading this as a call for more detailed discussion on the use case dra= ft (I agree that we should do this). As written, the use cases are just described with some required capabilitie= s included. We would benefit from diving deeper to enumerate all of the fu= nctionality (including data exchange formats and protocols/interfaces) we n= eed to accomplish our goals. Then how do either CPE and/or SWID fit into that need? Thank you! Kathleen From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, September 26, 2012 9:38 AM To: Struse, Richard; Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thanks, Rich! I have some additional comments/questions inline. From: , Richard > Date: Wednesday, September 26, 2012 6:32 AM To: Adam Montville = >, Jan-Oliver Wagner >, "sacm@ietf.org" > Cc: "kathleen.moriarty@emc.com" >, "Waltermire, David A.= " >, Jon Baker = > Subject: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request I think Jon Baker has already said some of this but I wanted to highlight t= he following: 1. SWID=92s and CPE=92s have some overlap but are largely complementar= y specifications 2. The SWID standard specifies tags that would allow automated verific= ation of package integrity (through manifests of file hashes), an important= capability that CPE does not provide >From this perspective, our assessment capabilities would want to assess SWI= Ds when a test is created to ensure that installed software is valid (or so= me language like that). 3. SWID=92s have been carefully designed to accommodate suites (e.g. O= ffice), patches and other complicating factors Is the implication that CPE has not been proven to handle these things? 4. The CPE language can represent patterns that map to multiple assets= , SWID=92s are a one-to-one sort of thing OK. I guess I was looking at this differently, as the SWID is certified an= d signed before installation. In that way, a SWID for Microsoft's latest r= elease of Windows 8 could reasonably serve as a classification mechanism co= uld it not? (Again, I'm not into the actual SWID standard yet =96 just wha= t's available publicly). 5. Microsoft announced their support for SWID tags earlier this year (= http://www.microsoft.com/sam/en/us/softwareid.aspx) Good to know. Jon also mentioned efforts to harmonize CPE and SWID =96it would be interes= ting to learn more about those efforts also. Hope this helps=85 Rich From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions =96 that w= ould be the domain of Asset Identification (we could use CPE or SWID to spe= cify classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road =96 when an operational compo= nent is implicitly or explicitly required for a standard to work as intende= d at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_7DE387DBFAD14A84AA205533A1002AB3tripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPhone

On Sep 26, 2012, at 6:46 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com> wrote:<= br>

Thank you to all for the = additional information!

 <= /p>

As Adam pointed out earli= er, how do we fulfill the use cases?  What is needed in a high-level c= harter description without naming a way to accomplish it. 


I'm reading this as a call for more detailed discussion on the use cas= e draft (I agree that we should do this).

As written, the use cases are just described with some required capabi= lities included.  We would benefit from diving deeper to enumerate all= of the functionality (including data exchange formats and protocols/interf= aces) we need to accomplish our goals.




Then how do either CPE an= d/or SWID fit into that need?

 <= /p>

Thank you!
Kathleen

 <= /p>

From: Adam Mon= tville [mailto:amontville@tripwi= re.com]
Sent: Wednesday, September 26, 2012 9:38 AM
To: Struse, Richard; Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

Thanks, Rich!  I have = some additional comments/questions inline.

 

From: <Struse>, Richard <Richard.Struse@HQ.DHS.GOV>
Date: Wednesday, September 26, 2012 6:32 AM
To: Adam Montville <am= ontville@tripwire.com>, Jan-Oliver Wagner <Jan-Oliver.Wagner@greenbone.net>, "= ;sacm@ietf.org" <sacm@ietf.org>
Cc: "kathleen.mori= arty@emc.com" <kat= hleen.moriarty@emc.com>, "Waltermire, David A." <david.waltermire@nist.gov>, Jon Baker <bakerj@MITRE.ORG>=
Subject: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

I think Jon Baker has alr= eady said some of this but I wanted to highlight the following:

1. &n= bsp;    SWID=92s and = CPE=92s have some overlap but are largely complementary specifications

2. &n= bsp;    The SWID stan= dard specifies tags that would allow automated verification of package inte= grity (through manifests of file hashes), an important capability that CPE does not provide

 

From this perspective, our = assessment capabilities would want to assess SWIDs when a test is created t= o ensure that installed software is valid (or some language like that).

 

3. &n= bsp;    SWID=92s have= been carefully designed to accommodate suites (e.g. Office), patches and o= ther complicating factors

 

Is the implication that CPE= has not been proven to handle these things?

 

4. &n= bsp;    The CPE langu= age can represent patterns that map to multiple assets, SWID=92s are a one-= to-one sort of thing

 

OK.  I guess I was loo= king at this differently, as the SWID is certified and signed before instal= lation.  In that way, a SWID for Microsoft's latest release of Windows 8 could reasonably serve as a classification mechanism could it no= t?  (Again, I'm not into the actual SWID standard yet =96 just what's = available publicly).

 

5. &n= bsp;    Microsoft ann= ounced their support for SWID tags earlier this year (http://www.microsoft.com/sam/en/u= s/softwareid.aspx)=

 

Good to know.

 

Jon also mentioned efforts = to harmonize CPE and SWID =96it would be interesting to learn more about th= ose efforts also.

 

 

Hope this helps=85=

 

Rich

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.or= g
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 =

This seems like an importan= t discussion.  Asset management is, arguably, the most important found= ational piece of an effective information security program, as our use case document [1] recognizes (asset management is the first recogn= ized capability in support of Use Case 1).  Clearly, there are pros an= d cons to leveraging CPE and/or SWID, and after quickly reading through som= e of the information available at TagVault [2], it seems clear that SWIDs are roughly equivalent to CPE for operating= systems and applications.

 

Before looking at the diffe= rences between CPE and SWID, it's probably a good idea to understand exactl= y what we need from a software asset classification scheme not only within our use cases, but also from a couple of control framework= s our use cases support (I prefer to look at the Critical Audit Guidelines = (CAG) published by SANS and ISO 27002).<= o:p>

 

Both the CAG and 27002 make= reference to managing assets, but only in terms of keeping an inventory. &= nbsp;The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized and unautho= rized software.  I don't believe either really mentions anything about= corrective actions, except implicitly in sections related to incident resp= onse.  

 

So, we have a clear need to= look at an instance of software, classify it, and build or contribute to a= n identity profile for it for continued reference.  Can CPE handle this classification for for us?  Yes.  Can SWID handl= e this classification for us?  It seems so.  Note that we should = not rely on either of these methods to identify software for targeted actio= ns =96 that would be the domain of Asset Identification (we could use CPE or SWID to specify classes of targets for actions).

 

Distribution and operationa= l identification seems important to consider as well.  CPEs aren't ins= talled with the software and require some assessment action to derive.  SWIDs, on the other hand, appear to be distributed by the so= ftware publisher [3].  Moreover, SWIDs are certified and signed by Tag= Vault.  I'm unsure of the details about how SWIDs become available on = a given system (they still need to be actively collected from a target system at some point).

 

At this point, the differen= ce between the two is really volume of available "tags" (we can r= easonably call a CPE name a "tag" in this context), and this is w= here I see the rubber meeting the road =96 when an operational component is imp= licitly or explicitly required for a standard to work as intended at scale.=  

 

There seems to be very litt= le information about SWID volumes available (at least in the limited time I= 've had to search around), so it's difficult to judge how well they've penetrated the market.  The last press release from TagV= ault is from 2010, which may suggest a dropping off of the effort or a sati= sfaction that they've done enough.  Information about CPE volume seems= most readily available from NVD [5].

 

Can anyone on this list pro= vide additional details about SWID?=

 

I think it may be useful, f= rom a  community perspective, to be able to handle both software ident= ification types, provided both are operationally feasible and foreseeably sustainable.  For example, the ai:software element= defined by the Asset Identification draft [4] has an optional CPE attribut= e that could just as easily be complemented by an optional SWID attribute.<= /span>

 

 

 

 

 

On 9/26/12 3:28 AM, "J= an-Oliver Wagner" <Jan-Oliver.Wagner@greenbone.net> wrote:

 

On Mittwoch, 26. September = 2012, Baker, Jon wrote:

I am a big fan of SWIDs and= believe that we would really benefit from widespread SWID adoption. In my = previous message, I was attempting to state that we need capabilities offer by both CPE and SWID.

 

I am a big fan of CPE and b= elieve it is fully compatible with Open Source reference

implementation and widespre= ad use/adoption in Open Source tools, especially also

in commercial environments.=

 

Neglecting CPE in favour of= SWID would IMHO be a drawback for widespread security

automation because, as to m= y understanding, SWID is not fully compatible with the vendor-independent

approaches. Convince me I a= m wrong and I'd be happy ;-)<= /span>

 

 

(Sorry for jumping in here,= it was just something I am worried about since some time already

so I spontaneously reacted = on the keywords :-)

 

 

--

Dr. Jan-Oliver Wagner |&nbs= p; ++49-541-335084-0  |  http://www.greenbone.net/

Greenbone Networks GmbH, Ne= uer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B 202460

Gesch=E4ftsf=FChrer: Lukas = Grunwald, Dr. Jan-Oliver Wagner

 

 

 

 

 

 

--_000_7DE387DBFAD14A84AA205533A1002AB3tripwirecom_-- From david.waltermire@nist.gov Wed Sep 26 08:51:48 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3421F8539 for ; Wed, 26 Sep 2012 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.403 X-Spam-Level: X-Spam-Status: No, score=-5.403 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, 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 68WC5wCmyLl4 for ; Wed, 26 Sep 2012 08:51:40 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA521F844D for ; Wed, 26 Sep 2012 08:51:36 -0700 (PDT) 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.1.379.0; Wed, 26 Sep 2012 11:50:58 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 26 Sep 2012 11:49:26 -0400 From: "Waltermire, David A." To: Adam Montville , "Struse, Richard" , Jan-Oliver Wagner , "sacm@ietf.org" Date: Wed, 26 Sep 2012 11:51:13 -0400 Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+tdyopvuPzxfkW1umHuq2WmRJecoI0AgAAP6/A= 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_D7A0423E5E193F40BE6E94126930C4930BA8B3C3A1MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "Moriarty, Kathleen" , "Baker, Jon" Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:51:48 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C3A1MBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my mind, we need to work through the software identification, inventory,= applicability, and querying use cases considering what CPE and SWID provid= e to make sure we have a complete, acceptable solution. Both CPE and SWID = do some things well, but both also fall short in specific areas. We need t= o insure that the body of software/asset management specifications fully ad= dress these use cases, while providing a needed level of backwards compatib= ility to current CPE use. SWIDs are complementary with CPE. It is possible to map between them in pa= rt using the current revision of SWID (ISO/IEC 19770-2:2009). The mapping = is partial since currently SWID does not have all of the fields we need. T= his is being addressed in the next revision of 19770-2. Early work for thi= s can be found here: http://tagvault.org/Automating_CPE_name_creation. Thi= s approach lays a foundation to enable automated creation of CPEs using SWI= D metadata. In my personal opinion, this also enables the beginning of a longer-term tr= ansition to using SWID for software asset management in the security automa= tion space. To fully enable a transition, we will need additional specific= ations to fill in use case gaps. The following specifications would addres= s some of these gaps: =B7 A document describing how to map from SWID to CPE to provide bac= kwards compatibility. The TagVault document referenced above is a good sta= rt for this. =B7 An update to the CPE Applicability Language 2.3 specification th= at describes how to use SWID metadata for applicability statements. This w= ould need to address requirements similar to what is described in the CPE M= atching 2.3 specification. Additional comments inline. Sincerely, Dave From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, September 26, 2012 9:38 AM To: Struse, Richard; Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thanks, Rich! I have some additional comments/questions inline. From: , Richard > Date: Wednesday, September 26, 2012 6:32 AM To: Adam Montville = >, Jan-Oliver Wagner >, "sacm@ietf.org" > Cc: "kathleen.moriarty@emc.com" >, "Waltermire, David A.= " >, Jon Baker = > Subject: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request I think Jon Baker has already said some of this but I wanted to highlight t= he following: 1. SWID's and CPE's have some overlap but are largely complementary spe= cifications 2. The SWID standard specifies tags that would allow automated verifica= tion of package integrity (through manifests of file hashes), an important = capability that CPE does not provide >From this perspective, our assessment capabilities would want to assess SWI= Ds when a test is created to ensure that installed software is valid (or so= me language like that). [DAW: Yes. SWID is based around this use case. One possible point of conc= ern might be around how tags are managed on the device to insure that if po= rtions of the software remain (e.g. DLLs, executables), that the assessment= mechanism will report that the software is still installed. This is espec= ially important if a security flaw exists in the residual software componen= t. This has been an ongoing challenge for the vulnerability use case and h= as not exactly been handled by CPE per se.] 3. SWID's have been carefully designed to accommodate suites (e.g. Offi= ce), patches and other complicating factors Is the implication that CPE has not been proven to handle these things? [DAW: Yes. This has been a challenge for CPE.] 4. The CPE language can represent patterns that map to multiple assets,= SWID's are a one-to-one sort of thing OK. I guess I was looking at this differently, as the SWID is certified an= d signed before installation. In that way, a SWID for Microsoft's latest r= elease of Windows 8 could reasonably serve as a classification mechanism co= uld it not? (Again, I'm not into the actual SWID standard yet - just what'= s available publicly). [DAW: Yes. A SWID tag contains both identifiers and metadata. The CPE App= licability Language can be thought of as a mechanism to query against the s= et of metadata described in a CPE. While SWIDs are generally more specific= relative to a released product than a CPE, the SWID contains the same meta= data. This means that with additional specification, that the CPE Language= can be adjusted to allow searching against the SWID metadata as well.] 5. Microsoft announced their support for SWID tags earlier this year (h= ttp://www.microsoft.com/sam/en/us/softwareid.aspx) Good to know. Jon also mentioned efforts to harmonize CPE and SWID -it would be interesti= ng to learn more about those efforts also. [DAW: See link above.] Hope this helps... Rich From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions - that wou= ld be the domain of Asset Identification (we could use CPE or SWID to speci= fy classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road - when an operational compone= nt is implicitly or explicitly required for a standard to work as intended = at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C3A1MBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

&nbs= p;

In my mind, we need to work = through the software identification, inventory, applicability, and querying= use cases considering what CPE and SWID provide to make sure we have a com= plete, acceptable solution.=A0 Both CPE and SWID do some things well, but b= oth also fall short in specific areas.=A0 We need to insure that the body o= f software/asset management specifications fully address these use cases, w= hile providing a needed level of backwards compatibility to current CPE use= .

 =

SWIDs are complementary with CPE.=A0 It is = possible to map between them in part using the current revision of SWID (IS= O/IEC 19770-2:2009).=A0 The mapping is partial since currently SWID does no= t have all of the fields we need. =A0This is being addressed in the next re= vision of 19770-2.=A0 Early work for this can be found here: http://tagvault.org/Automati= ng_CPE_name_creation.=A0 This approach lays a foundation = to enable automated creation of CPEs using SWID metadata.=

 

In my personal opinion, this also enables the beginning of a l= onger-term transition to using SWID for software asset management in the se= curity automation space.=A0 To fully enable a transition, we will need addi= tional specifications to fill in use case gaps.=A0 The following specificat= ions would address some of these gaps:

 

=B7 &nbs= p;      A do= cument describing how to map from SWID to CPE to provide backwards compatib= ility.=A0 The TagVault document referenced above is a good start for this.<= o:p>

=B7<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;  An update to the CPE Appl= icability Language 2.3 specification that describes how to use SWID metadat= a for applicability statements.=A0 This would need to address requirements = similar to what is described in the CPE Matching 2.3 specification.

 

Additional comments inline.

 

Sincerely,

Dave=

 

From: Adam Montville [mailto:amon= tville@tripwire.com]
Sent: Wednesday, September 26, 2012 9:38 AM=
To: Struse, Richard; Jan-Oliver Wagner; sacm@ietf.org
Cc:<= /b> Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject:= Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

<= /div>

 

Thanks, Rich!  I have some additional comments/questions inli= ne.

 

From: <Struse>, Richard <Richard.Struse@HQ.DHS.GOV>
Date: Wednesday, September = 26, 2012 6:32 AM
To: Adam Montville <amontville@tripwire.com>, Jan-Oliver Wagner <Jan-Oliver.Wagner@greenbon= e.net>, "sacm@ietf.org&quo= t; <sacm@ietf.org>
Cc: "kathleen.moriarty@emc.c= om" <kathleen.mori= arty@emc.com>, "Waltermire, David A." <david.waltermire@nist.gov>, Jon Baker &= lt;bakerj@MITRE.ORG>
Subje= ct: RE: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

I think Jon Bak= er has already said some of this but I wanted to highlight the following:

1.   =   SWID’s and CPE’s h= ave some overlap but are largely complementary specifications

2.=      The SWID standard specifies tags that woul= d allow automated verification of package integrity (through manifests of f= ile hashes), an important capability that CPE does not provide

<= p class=3DMsoNormal> 

From this perspective, our assessment capabilities would wan= t to assess SWIDs when a test is created to ensure that installed software = is valid (or some language like that).

 

[DAW= : Yes.=A0 SWID is based around this use case.=A0 One possible point of conc= ern might be around how tags are managed on the device to insure that if po= rtions of the software remain (e.g. DLLs, executables), that the assessment= mechanism will report that the software is still installed.=A0 This is esp= ecially important if a security flaw exists in the residual software compon= ent.=A0 This has been an ongoing challenge for the vulnerability use case a= nd has not exactly been handled by CPE per se.]

=

 

3.     SWID’s have been carefully designed to accommodate suites (= e.g. Office), patches and other complicating factors

 

= Is the implication that CPE has not been proven to handle these things= ?

 

[DAW: Yes.=A0 This has been a ch= allenge for CPE.]

&nb= sp;

4.   = ;  The CPE language can represen= t patterns that map to multiple assets, SWID’s are a one-to-one sort = of thing

 

<= /div>

OK.  I guess I was looking at this= differently, as the SWID is certified and signed before installation. &nbs= p;In that way, a SWID for Microsoft's latest release of Windows 8 could rea= sonably serve as a classification mechanism could it not?  (Again, I'm= not into the actual SWID standard yet – just what's available public= ly).

 = ;

[DAW: Yes.=A0 A SWID tag cont= ains both identifiers and metadata.=A0 The CPE Applicability Language can b= e thought of as a mechanism to query against the set of metadata described = in a CPE.=A0 While SWIDs are generally more specific relative to a released= product than a CPE, the SWID contains the same metadata.=A0 This means tha= t with additional specification, that the CPE Language can be adjusted to a= llow searching against the SWID metadata as well.]

 

5.     Microsoft announced their support for SWID tags earlier this year (http://www.micro= soft.com/sam/en/us/softwareid.aspx)<= o:p>

 

Good t= o know.

&nbs= p;

Jon also mentioned = efforts to harmonize CPE and SWID –it would be interesting to learn m= ore about those efforts also.

 

[DAW: See link = above.]

&nbs= p;

 

Hope this helps…

 

Ric= h

<= p class=3DMsoNormal>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville=
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Ol= iver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: = [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

This seems like an important discussion.  Asset management is, arguab= ly, the most important foundational piece of an effective information secur= ity program, as our use case document [1] recognizes (asset management is t= he first recognized capability in support of Use Case 1).  Clearly, th= ere are pros and cons to leveraging CPE and/or SWID, and after quickly read= ing through some of the information available at TagVault [2], it seems cle= ar that SWIDs are roughly equivalent to CPE for operating systems and appli= cations.

 

Before looking at the d= ifferences between CPE and SWID, it's probably a good idea to understand ex= actly what we need from a software asset classification scheme not only wit= hin our use cases, but also from a couple of control frameworks our use cas= es support (I prefer to look at the Critical Audit Guidelines (CAG) publish= ed by SANS and ISO 27002).

 

Both = the CAG and 27002 make reference to managing assets, but only in terms of k= eeping an inventory.  The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software.  I don't believe either really mentions anythin= g about corrective actions, except implicitly in sections related to incide= nt response.  

 

So, we have = a clear need to look at an instance of software, classify it, and build or = contribute to an identity profile for it for continued reference.  Can= CPE handle this classification for for us?  Yes.  Can SWID handl= e this classification for us?  It seems so.  Note that we should = not rely on either of these methods to identify software for targeted actio= ns – that would be the domain of Asset Identification (we could use C= PE or SWID to specify classes of targets for actions).

&n= bsp;

Distribution and operational identification seems im= portant to consider as well.  CPEs aren't installed with the software = and require some assessment action to derive.  SWIDs, on the other han= d, appear to be distributed by the software publisher [3].  Moreover, = SWIDs are certified and signed by TagVault.  I'm unsure of the details= about how SWIDs become available on a given system (they still need to be = actively collected from a target system at some point).

 

=

At this point, the difference between the two is = really volume of available "tags" (we can reasonably call a CPE n= ame a "tag" in this context), and this is where I see the rubber = meeting the road – when an operational component is implicitly or exp= licitly required for a standard to work as intended at scale.  =

 

=

There seems to be very little informat= ion about SWID volumes available (at least in the limited time I've had to = search around), so it's difficult to judge how well they've penetrated the = market.  The last press release from TagVault is from 2010, which may = suggest a dropping off of the effort or a satisfaction that they've done en= ough.  Information about CPE volume seems most readily available from = NVD [5].

 

Can anyone on this list= provide additional details about SWID?<= o:p>

 

I think it may be useful, from a  community perspective, to be= able to handle both software identification types, provided both are opera= tionally feasible and foreseeably sustainable.  For example, the ai= :software element defined by the Asset Identification draft [4] has an = optional CPE attribute that could just as easily be complemented by an opti= onal SWID attribute.

 

 

<= p class=3DMsoNormal>[2] http://www= .tagvault.org

<= /div>

[5]&nb= sp;http://nvd.nist.gov/cpe.cfm<= /span>

 

 

 =

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbon= e.net> wrote:

 

On Mittwoch, 26. September 20= 12, Baker, Jon wrote:<= /p>

I am a big fan of SWIDs and believe that we would rea= lly benefit from widespread SWID adoption. In my previous message, I was at= tempting to state that we need capabilities offer by both CPE and SWID.

 =

I am a big fan of CPE= and believe it is fully compatible with Open Source reference

implementation and widespread use/adoption in Open Source tools, espe= cially also

<= div>

in commercial environments.

 

=

Neglecting CPE in favour of SWID would IMHO be a = drawback for widespread security

automation because, as t= o my understanding, SWID is not fully compatible with the vendor-independen= t

approaches. Convince me I am wrong and I'd be happy ;-)=

 

 

(Sorry= for jumping in here, it was just something I am worried about since some t= ime already

<= div>

so I spontaneously reacted on the keywords :-= )

 

 

--

Dr. Jan-Oliver Wagner |  ++49-541-335084-0 = ; |  http://www.greenb= one.net/

=

Greenbone Networks GmbH, Neuer Graben 17, 49= 074 Osnabr=FCck | AG Osnabr=FCck, HR B 202460

Gesch=E4fts= f=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

 

 

 

 

=

 

 

<= /div>
= --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C3A1MBCLUSTERxcha_-- From turners@ieca.com Wed Sep 26 12:29:01 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B47021F8549 for ; Wed, 26 Sep 2012 12:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 5D3Tq+o9Uq9a for ; Wed, 26 Sep 2012 12:29:01 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.36.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3333521F84A7 for ; Wed, 26 Sep 2012 12:29:01 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 9B8362AC21409; Wed, 26 Sep 2012 14:29:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 90A2F2AC213DE for ; Wed, 26 Sep 2012 14:29:01 -0500 (CDT) Received: from [108.18.174.220] (port=60215 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGxI4-0002Ek-Nh for sacm@ietf.org; Wed, 26 Sep 2012 14:29:00 -0500 Message-ID: <5063577C.3050401@ieca.com> Date: Wed, 26 Sep 2012 15:29:00 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:60215 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] BOF Status X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:29:01 -0000 The BOF was approved. Chairs are Kathleen Moriarty and TBD. No slight to Dave Waltermire, but I'd rather have him in the audience because his name is on a lot of the drafts. The other co-chair will likely be well versed in IETF process, but might not be well versed in sacm/scap (it's normal to have one process BOF chair). Scheduling of the actual meeting slot occurs later in the process. spt From amontville@tripwire.com Wed Sep 26 12:30:11 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1F21F84A7 for ; Wed, 26 Sep 2012 12:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bPhEqWDXPW4z for ; Wed, 26 Sep 2012 12:30:10 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id B3B1521F849D for ; Wed, 26 Sep 2012 12:30:10 -0700 (PDT) Received: from mail188-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 19:30:08 +0000 Received: from mail188-ch1 (localhost [127.0.0.1]) by mail188-ch1-R.bigfish.com (Postfix) with ESMTP id CA3F11201DA for ; Wed, 26 Sep 2012 19:30:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432I1447Id6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail188-ch1 (localhost.localdomain [127.0.0.1]) by mail188-ch1 (MessageSwitch) id 1348687807146864_10316; Wed, 26 Sep 2012 19:30:07 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail188-ch1.bigfish.com (Postfix) with ESMTP id 21580320058 for ; Wed, 26 Sep 2012 19:30:07 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 19:30:04 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id C0096232124A for ; Wed, 26 Sep 2012 12:24:55 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 2D58223211F8; Wed, 26 Sep 2012 12:24:55 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 26 Sep 2012 12:33:11 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 12:30:03 -0700 From: Adam Montville To: Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] BOF Status Thread-Index: AQHNnB0zMdHkqsukukG1tizjJHGGgZedAmEA Date: Wed, 26 Sep 2012 19:30:02 +0000 Message-ID: In-Reply-To: <5063577C.3050401@ieca.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: [172.16.97.98] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <0CC4D4C9E29E3F46834F1B241D3C0ADA@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 46d5330c-5e47-441e-a562-ea82777f66ce X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] BOF Status X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:30:11 -0000 Thanks for the update, Sean. This is good news! On 9/26/12 12:29 PM, "Sean Turner" wrote: >The BOF was approved. Chairs are Kathleen Moriarty and TBD. No slight >to Dave Waltermire, but I'd rather have him in the audience because his >name is on a lot of the drafts. The other co-chair will likely be well >versed in IETF process, but might not be well versed in sacm/scap (it's >normal to have one process BOF chair). > >Scheduling of the actual meeting slot occurs later in the process. > >spt >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > > From david.waltermire@nist.gov Wed Sep 26 12:32:22 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7721F8555 for ; Wed, 26 Sep 2012 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 4unBvo03eh3n for ; Wed, 26 Sep 2012 12:32:21 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1921F849D for ; Wed, 26 Sep 2012 12:32:21 -0700 (PDT) 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.1.379.0; Wed, 26 Sep 2012 15:31:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 26 Sep 2012 15:30:27 -0400 From: "Waltermire, David A." To: Sean Turner , "sacm@ietf.org" Date: Wed, 26 Sep 2012 15:32:14 -0400 Thread-Topic: [sacm] BOF Status Thread-Index: Ac2cHPCYeyL+bUsBSUS20AqzSR+7mQAAFRkQ Message-ID: References: <5063577C.3050401@ieca.com> In-Reply-To: <5063577C.3050401@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] BOF Status X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:32:22 -0000 Sean, Thanks for setting this up! No worries about the chairs. I am happy to help as you see fit. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Wednesday, September 26, 2012 3:29 PM To: sacm@ietf.org Subject: [sacm] BOF Status The BOF was approved. Chairs are Kathleen Moriarty and TBD. No slight to Dave Waltermire, but I'd rather have him in the audience because his name is on a lot of the drafts. The other co-chair will likely be well versed in IETF process, but might not be well versed in sacm/scap (it's normal to have one process BOF chair). Scheduling of the actual meeting slot occurs later in the process. spt _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Thu Sep 27 04:10:14 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0366D21F869D for ; Thu, 27 Sep 2012 04:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.075 X-Spam-Level: X-Spam-Status: No, score=-5.075 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 bm2zwQuYhnTz for ; Thu, 27 Sep 2012 04:10:13 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CB76121F869C for ; Thu, 27 Sep 2012 04:10:12 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 27 Sep 2012 07:09:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 27 Sep 2012 07:10:11 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Thu, 27 Sep 2012 07:10:08 -0400 Thread-Topic: Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2afm7Z7K4Rsa/6QIqh6G/YPMl5VACIhGRQ 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/mixed; boundary="_004_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] FW: Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 11:10:14 -0000 --_004_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_ Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_" --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" It looks like there is going to be a meetup at the IT Security Automation Conference. See below. Sincerely, Dave From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, John Sent: Monday, September 24, 2012 2:02 PM To: sacm@ietf.org; mile@ietf.org Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards. The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts. Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend. Participants are encouraged to share their use cases and requirements for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the room number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVO LVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SXQgbG9va3MgbGlrZSB0aGVyZSBp cyBnb2luZyB0byBiZSBhIG1lZXR1cCBhdCB0aGUgSVQgU2VjdXJpdHkgQXV0b21hdGlvbiBDb25m ZXJlbmNlLiZuYnNwOyBTZWUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVs eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG1pbGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1p bGUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5CYW5naGFydCwgSm9objxi cj48Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTIgMjowMiBQTTxicj48Yj5U bzo8L2I+IHNhY21AaWV0Zi5vcmc7IG1pbGVAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtt aWxlXSBVcGNvbWluZyBCb0YgYXQgdGhlIElUIFNlY3VyaXR5IEF1dG9tYXRpb24gQ29uZmVyZW5j ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5IZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5UaGVyZSB3aWxsIGJlIGEgYmlyZHMtb2YtYS1mZWF0aGVyIChCb0YpIHNlc3Npb24gYXQgdGhl IHVwY29taW5nIElUIFNlY3VyaXR5IEF1dG9tYXRpb24gQ29uZmVyZW5jZSAoSVRTQUMpIGluIEJh bHRpbW9yZSBvbiBXZWRuZXNkYXksIE9jdG9iZXIgNHRoLCBmcm9tIDU6MzBwbSB0byA2OjMwcG0s IGZvY3VzaW5nIG9uIGludGVybmF0aW9uYWwgZWZmb3J0cyB0byBkZXZlbG9wIHNlY3VyaXR5IGF1 dG9tYXRpb24gc3RhbmRhcmRzLiAmbmJzcDtUaGUgQm9GIHdpbGwgZm9jdXMgb24gcmV2aWV3aW5n IGN1cnJlbnQgZWZmb3J0cyB0byBzdGFuZGFyZGl6ZSBzZWN1cml0eSBhdXRvbWF0aW9uIGNhcGFi aWxpdGllcyBhbmQgaG93IHRvIGVuZ2FnZSBpbiB0aGVzZSBlZmZvcnRzLiAmbmJzcDtBbnlvbmUg YWN0aXZlbHkgb3IgaW50ZXJlc3RlZCBpbiBwYXJ0aWNpcGF0aW5nIGluIG9yIHVzaW5nIHN0YW5k YXJkcyBkZXZlbG9wZWQgYnkgaW50ZXJuYXRpb25hbCBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQgb3Jn YW5pemF0aW9ucyAoU0RPcykgc2hvdWxkIGF0dGVuZC4gJm5ic3A7UGFydGljaXBhbnRzIGFyZSBl bmNvdXJhZ2VkIHRvIHNoYXJlIHRoZWlyIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBz ZWN1cml0eSBhdXRvbWF0aW9uIHN0YW5kYXJkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBJVFNBQywgcGxlYXNlIHZpc2l0 OiA8YSBocmVmPSJodHRwczovL2l0c2FjLmcycGxhbmV0LmNvbS9pdHNhYzIwMTIiPmh0dHBzOi8v aXRzYWMuZzJwbGFuZXQuY29tL2l0c2FjMjAxMjwvYT4uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+UGxlYXNlIG5vdGUgdGhhdCByZW1vdGUgYWNjZXNzIGNhcGFi aWxpdGllcyB3aWxsIG5vdCBiZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPklmIHRoZXJlIGlzIHN1ZmZpY2llbnQgaW50ZXJlc3QsIEkgd2lsbCBw cm92aWRlIGFkZGl0aW9uYWwgZGV0YWlscyBvbiB0aGUgcm9vbSBudW1iZXIgYW5kIG90aGVyIGxv Z2lzdGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlRoYW5rIHlvdS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPi1Kb2huPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Sm9obiBC YW5naGFydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Qcm9ncmFtIEFuYWx5c3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+UHJv Z3JhbSBDb29yZGluYXRpb24gT2ZmaWNlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPk9mZmljZSBvZiB0aGUgVW5k ZXIgU2VjcmV0YXJ5IG9mIENvbW1lcmNlIGZvciBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9n eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+KDMwMSkgOTc1LTgwODU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+PGEgaHJlZj0ibWFpbHRvOkpvaG4uYmFuZ2hhcnRAbmlzdC5nb3YiPkpvaG4u YmFuZ2hhcnRAbmlzdC5nb3Y8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_-- --_004_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_ Content-Type: text/plain; name="ATT00001..c" Content-Description: ATT00001..c Content-Disposition: attachment; filename="ATT00001..c"; size=127; creation-date="Mon, 24 Sep 2012 14:00:22 GMT"; modification-date="Mon, 24 Sep 2012 14:00:22 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pbGUgbWFp bGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCg== --_004_D7A0423E5E193F40BE6E94126930C4930BA8B3C754MBCLUSTERxcha_-- From david.waltermire@nist.gov Thu Sep 27 04:11:40 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C4521F86DA for ; Thu, 27 Sep 2012 04:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Vc50zT-wXqcB for ; Thu, 27 Sep 2012 04:11:40 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3421F86D5 for ; Thu, 27 Sep 2012 04:11:39 -0700 (PDT) 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.1.379.0; Thu, 27 Sep 2012 07:10:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 27 Sep 2012 07:09:26 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Thu, 27 Sep 2012 07:11:16 -0400 Thread-Topic: Upcoming BoF at the IT Security Automation Conference Thread-Index: Ac2afm7Z7K4Rsa/6QIqh6G/YPMl5VACIhGRQAAAPG9A= 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_D7A0423E5E193F40BE6E94126930C4930BA8B3C755MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Upcoming BoF at the IT Security Automation Conference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 11:11:40 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C755MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" It looks like this is Wednesday the 3rd, not the 4th. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, September 27, 2012 7:10 AM To: sacm@ietf.org Subject: [sacm] FW: Upcoming BoF at the IT Security Automation Conference It looks like there is going to be a meetup at the IT Security Automation Conference. See below. Sincerely, Dave From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, John Sent: Monday, September 24, 2012 2:02 PM To: sacm@ietf.org; mile@ietf.org Subject: [mile] Upcoming BoF at the IT Security Automation Conference Hello all, There will be a birds-of-a-feather (BoF) session at the upcoming IT Security Automation Conference (ITSAC) in Baltimore on Wednesday, October 4th, from 5:30pm to 6:30pm, focusing on international efforts to develop security automation standards. The BoF will focus on reviewing current efforts to standardize security automation capabilities and how to engage in these efforts. Anyone actively or interested in participating in or using standards developed by international standards development organizations (SDOs) should attend. Participants are encouraged to share their use cases and requirements for security automation standards. For more information on the ITSAC, please visit: https://itsac.g2planet.com/itsac2012. Please note that remote access capabilities will not be possible. If there is sufficient interest, I will provide additional details on the room number and other logistics. Thank you. -John -- John Banghart Program Analyst Program Coordination Office Office of the Under Secretary of Commerce for Standards and Technology National Institute of Standards and Technology (301) 975-8085 John.banghart@nist.gov --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C755MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SXQgbG9va3MgbGlr ZSB0aGlzIGlzIFdlZG5lc2RheSB0aGUgMzxzdXA+cmQ8L3N1cD4sIG5vdCB0aGUgNDxzdXA+dGg8 L3N1cD4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGF2ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5XYWx0ZXJtaXJlLCBEYXZpZCBBLjxicj48Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIFNlcHRlbWJlciAyNywgMjAxMiA3OjEwIEFNPGJyPjxiPlRvOjwvYj4gc2Fj bUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW3NhY21dIEZXOiBVcGNvbWluZyBCb0YgYXQg dGhlIElUIFNlY3VyaXR5IEF1dG9tYXRpb24gQ29uZmVyZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SXQgbG9va3MgbGlrZSB0aGVy ZSBpcyBnb2luZyB0byBiZSBhIG1lZXR1cCBhdCB0aGUgSVQgU2VjdXJpdHkgQXV0b21hdGlvbiBD b25mZXJlbmNlLiZuYnNwOyBTZWUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNl cmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzptaWxlLWJvdW5jZXNA aWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWls dG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSI+W21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmdd PC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPkJhbmdoYXJ0LCBKb2huPGJyPjxiPlNlbnQ6PC9iPiBN b25kYXksIFNlcHRlbWJlciAyNCwgMjAxMiAyOjAyIFBNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFttaWxl XSBVcGNvbWluZyBCb0YgYXQgdGhlIElUIFNlY3VyaXR5IEF1dG9tYXRpb24gQ29uZmVyZW5jZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrJz5IZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5U aGVyZSB3aWxsIGJlIGEgYmlyZHMtb2YtYS1mZWF0aGVyIChCb0YpIHNlc3Npb24gYXQgdGhlIHVw Y29taW5nIElUIFNlY3VyaXR5IEF1dG9tYXRpb24gQ29uZmVyZW5jZSAoSVRTQUMpIGluIEJhbHRp bW9yZSBvbiBXZWRuZXNkYXksIE9jdG9iZXIgNHRoLCBmcm9tIDU6MzBwbSB0byA2OjMwcG0sIGZv Y3VzaW5nIG9uIGludGVybmF0aW9uYWwgZWZmb3J0cyB0byBkZXZlbG9wIHNlY3VyaXR5IGF1dG9t YXRpb24gc3RhbmRhcmRzLiAmbmJzcDtUaGUgQm9GIHdpbGwgZm9jdXMgb24gcmV2aWV3aW5nIGN1 cnJlbnQgZWZmb3J0cyB0byBzdGFuZGFyZGl6ZSBzZWN1cml0eSBhdXRvbWF0aW9uIGNhcGFiaWxp dGllcyBhbmQgaG93IHRvIGVuZ2FnZSBpbiB0aGVzZSBlZmZvcnRzLiAmbmJzcDtBbnlvbmUgYWN0 aXZlbHkgb3IgaW50ZXJlc3RlZCBpbiBwYXJ0aWNpcGF0aW5nIGluIG9yIHVzaW5nIHN0YW5kYXJk cyBkZXZlbG9wZWQgYnkgaW50ZXJuYXRpb25hbCBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQgb3JnYW5p emF0aW9ucyAoU0RPcykgc2hvdWxkIGF0dGVuZC4gJm5ic3A7UGFydGljaXBhbnRzIGFyZSBlbmNv dXJhZ2VkIHRvIHNoYXJlIHRoZWlyIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBzZWN1 cml0eSBhdXRvbWF0aW9uIHN0YW5kYXJkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBJVFNBQywgcGxlYXNlIHZpc2l0OiA8 YSBocmVmPSJodHRwczovL2l0c2FjLmcycGxhbmV0LmNvbS9pdHNhYzIwMTIiPmh0dHBzOi8vaXRz YWMuZzJwbGFuZXQuY29tL2l0c2FjMjAxMjwvYT4uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+UGxlYXNlIG5vdGUgdGhhdCByZW1vdGUgYWNjZXNzIGNhcGFiaWxp dGllcyB3aWxsIG5vdCBiZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPklmIHRoZXJlIGlzIHN1ZmZpY2llbnQgaW50ZXJlc3QsIEkgd2lsbCBwcm92 aWRlIGFkZGl0aW9uYWwgZGV0YWlscyBvbiB0aGUgcm9vbSBudW1iZXIgYW5kIG90aGVyIGxvZ2lz dGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlRoYW5rIHlvdS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPi1Kb2huPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Sm9obiBCYW5n aGFydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5Qcm9ncmFtIEFuYWx5c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+UHJvZ3Jh bSBDb29yZGluYXRpb24gT2ZmaWNlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPk9mZmljZSBvZiB0aGUgVW5kZXIg U2VjcmV0YXJ5IG9mIENvbW1lcmNlIGZvciBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+KDMwMSkgOTc1LTgwODU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PGEgaHJlZj0ibWFpbHRvOkpvaG4uYmFuZ2hhcnRAbmlzdC5nb3YiPkpvaG4uYmFu Z2hhcnRAbmlzdC5nb3Y8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930BA8B3C755MBCLUSTERxcha_--